Comments on: Calling Devs: New, Free Cocoa Framework for OpenSoundControl, MIDI

By: JC Reus

JC Reus — Mon, 21 Dec 2009 14:43:17 +0000

I’ve been mucking around with VVOSC and am curious.. does anybody know if an implementation of the Blob datatype is in the works?

For the project I’m working on we absolutely must have blobs. I’d use oscpack (or possibly liblo, but I haven’t read up enough on that library yet) … the only “problem” is that I really love the zero-conf networking neatures of VVOSC.

Couldn’t find Ray Cutler’s email anywhere in the library or on Google Code. Any clues comrades?

By: JC Reus

JC Reus — Tue, 08 Dec 2009 01:53:27 +0000

There’s also the excellent cross-platform C++ library OSCPack.

Found here:
http://www.audiomulch.com/~rossb/code/oscpack/

By: davebv

davebv — Sat, 27 Dec 2008 16:21:30 +0000

this framework is amazin, I am currently including it in my MusicController wiimote app:
http://code.google.com/p/musiccontroller (Still in the SVN, the code is not finished yet)

By: samBiotic

samBiotic — Sat, 01 Nov 2008 03:40:39 +0000

By: samBiotic

samBiotic — Sat, 01 Nov 2008 03:40:14 +0000

@peter kim hopefuly you’ll never find out my dark past!

By: Peter Kirn

Peter Kirn — Sat, 01 Nov 2008 02:04:24 +0000

@Andrew: ah, that’s great. Yeah, I was confused about that … I thought based on that readme that the preprocessor would get confused if you tried to include some of that syntax in a library…. so, great. Time to go practice my varargs chops.

@samBiotic: cool, will check that out! I’m proud of my embarrassing code, myself. ;)

By: Andrew Turley

Andrew Turley — Sat, 01 Nov 2008 00:32:05 +0000

For the record, I was wrong about Processing’s relationship to Java 1.5. It looks like it should play nice with external libraries written in Java 1.5, you just can’t use Java 1.5 syntax in Processing code. So I think libraries can use varargs. I just wanted to clear that up.

By: samBiotic

samBiotic — Fri, 31 Oct 2008 23:45:18 +0000

i made this ages ago with processing.
this thread has inspired me to upload it.

http://bioticaudio.com/roseosc/

a kind of 3d didital flower that responds to 7 variables.

i’ve omitted the source as it’s kind of embarrasing being a bodged effort way back in 2003 before the oscP5 implementation was released. Really it was just osc wrapped around an example sketch.

even so, i could still see the some potential as a vis/ui platform back then.

new pd test patch to go with though.

By: Peter Kirn

Peter Kirn — Fri, 31 Oct 2008 21:33:21 +0000

Yeah, I see what you mean … and that’s an excellent illustration of why varargs might be nice. (may give this a go for my non-Processing OSC projects)

Here’s the current status as near as I can tell:

“# Starting in release 0136, Java 1.5 is required to run the Processing Development Environment and projects created with Processing.
# It is not yet possible to use any of the new syntax introduced in Java 1.5 within Processing, even if you have 1.5 installed (the preprocessor and compiler used by Processing don’t understand the 1.5 syntax). This includes the enhanced “for” loop, templates, generics, enums, varargs, and lots of other crap that Sun added because they felt that the older syntax was too simple and usable. A couple of these features are very useful (the for loop, some aspects of generics) so if you would like to help get things running with 1.5 syntax, please help us fix things. More information cane be found here. ”

Bug report here:
http://dev.processing.org/bugs/show_bug.cgi?id=598

And here’s what they say about it:
“The grammar is called pde.g, and is an extension of the java.g grammar
found in app/antlr/java. Anyone who has the chops to update the java.g
grammar from 1.3 to 1.5 would be greatly appreciated. In addition then, the
grammar for pde.g needs to be updated to make sure it still works.

This is a time consuming/mind-bending process, and has been put off since
the new Java syntax features are not a priority, and using
ArrayList is way slower than just dealing with an int array… and
speed is important for interactive graphics.”

– actually, I was unaware of that; ArrayList is slower than arrays? (And what are they talking about, exactly, given that you can use ArrayLists in Processing and it isn’t a syntax issue in the same way?)

Anyway, yes … varargs. Sounds like a good idea.

I agree about libraries, but I think something like adding those bunch o’ methods to a QuickOSC class wouldn’t be a bad idea. At least it saves trouble in future; that was exactly what I was proposing.

And maybe at this point, Andrew, you and I should continue offline. :)

By: Andrew Turley

Andrew Turley — Fri, 31 Oct 2008 21:07:14 +0000

@Peter Kirn: Well, you could always do something like this:
class QuickOSC { static void send(String addr, String inetAddr, int port) { ... } static void send(String addr, Object msg1, String inetAddr, int port) { ... } static void send(String addr, Object msg1, Object msg2, String inetAddr, int port) { ... } static void send(String addr, Object msg1, Object msg2, Object msg3, String inetAddr, int port) { ... } static void send(String addr, Object msg1, Object msg2, Object msg3, Object msg4, String inetAddr, int port) { ... } static void send(String addr, Object[] msg, String inetAddr, int port) { ... } static void send(String addr, List msg, String inetAddr, int port) { ... } }
That way you have an API for messages with 0-4 parts, along with interfaces for arbitrary numbers of parts. In Java 1.5 you could just use varargs like this:
class QuickOSC { static void send(String addr, String inetAddr, int port, Object... arguments) { ... } }
But Processing and Java 1.5 still aren’t friends.

True enough, people could build their own libraries. But I read an article a while back talking about how sometimes it’s best to provide people with something that handles simple cases well right out of the box. You want someone to have an idea and be able to run with it pretty quickly using your library or language or whatever. I think that’s especially true for people who may not be “serious” programmers and just want to be able to throw in a line or two of code to get something to work.