OSC Stream Processing in Max

Aug 31, 2012 at 5:43pm

OSC Stream Processing in Max

Hi everyone,

I’m happy to see all the recent interest in OSC on the Max list! In light of some of the recent discussions, I thought I would mention a library of objects that have been in development for some time at CNMAT that operate on OSC data directly (as opposed to OSC-route which operates on OSC-style Max messages). You can find the objects here: http://cnmat.berkeley.edu/downloads/odot (they’ll move to the main downloads page in a few weeks once I’m done reorganizing it).

There are two papers from 2011 here:

http://cnmat.berkeley.edu/publication/dynamic_instance_based_object_oriented_programming_oop_max_msp_us

http://cnmat.berkeley.edu/publication/composability_musical_gesture_signal_processing_using_new_osc_bas

Although the objects have changed (significantly, in some cases) since those papers were written, they still serve as a useful introduction to the basic concepts. We have a new paper that’s just been submitted for review that should make its way onto the website soon.

These objects are being used quite heavily in a number of projects and are stable and performing well. That said, if you run into bugs, have ideas about how they can be improved, or have any questions, feel free to email me directly while we set up an official issue tracking system.

JM

#64187
Sep 1, 2012 at 3:35am

Would you care to provide a quick overview as to why these are more appropriate/useful/better than the older stuff? Is there a reason to switch to them if the older OSC-route stuff works?

#231499
Sep 1, 2012 at 4:30am

I had a (quick) look through the papers and it looks like these are multifunctional objects, rather than OSC connectivity objects.

So they would replace a bunch of regular max objects (and then some) rather than let you do the same kind of things using max objects (and only using OSC on the input).

Probably a gross oversimplification.

I just want native OSC parsing….

#231500
Sep 1, 2012 at 4:01pm

That big difference with these objects is that they are passing around actual OSC bundles, rather than OSC-style max messages. If you stick some regular print objects in some of the help patches, you’ll see that o.objects are sending “Full Packet” messages. These are similar to jitter matrices or dictionaries. What it really is is a memory pointer that’s being passed around. If you put updreceive into compatibility mode, you’ll see the same kind of output.

If you have time, read John’s paper: http://john-maccallum.com/writings/odot_icmc_2011/odot_icmc_2011.pdf But briefly, it’s an introduction of a new, powerful data type into Max. OSC messages can be grouped into bundles that are treated atomically, and have high resolution time tags. Passing memory pointers is more efficient than passing messages made of symbols and arguments. These objects enable a different style of programming inside of Max. That probably won’t appeal to everyone, but there are some big ideas here.

#231501
Sep 1, 2012 at 4:47pm

I see, so it’s a new data type, period. That data type just happens to be OSC.

So it doesn’t really do anything for regular OSC parsing (do the o objects replace OSC-route too?).

#231502
Sep 1, 2012 at 5:12pm

The way I understand it is basically as a streaming data structure, where you can operate on the data inside arbitrarily. For instance with a xyz controller that is sending OSC bundles, you set your udpreceive to cnmat mode, and then you will get your /x /y /z parameters streaming together in one OSC bundle — which is really nice for mapping, also useful for higher order processes.

o.route works with the old max message style too.

One nice thing with o.route when you’re using bundles rather than individual messages, is that you can choose which direction the bundle routing happens. Useful for when you need things in a specific order, for example getting amplitude last in a poly~ voice.

#231503
Sep 1, 2012 at 5:59pm

I don’t have a problem changing to new ways of doing things (in fact, I think it’s very critical to be open to change otherwise one gets left behind) but it should be reasonably clear what will be the benefit of the change. I’ve downloaded the papers so I’m hoping there will be an explanation for the different style AND the benefits of switching to it over what already exists.

______________
These objects enable a different style of programming inside of Max.

#231504
Sep 1, 2012 at 8:34pm

jeez. that is an astonishing collection of externals. damn you cnmat.

it would be good for o.call and perhaps o.route to have internal mapping options before output, such as exponential etc, rather then max objects directly after taking up more time.

also, the o.grandstaff referred to in the article is not present in the download. why? i am interested in that option. although i can already imagine [o.2bach] or [llll2o.] and vice versa abstractions or so.

it is a worry the library is so big. not enough time to really go into it much now either. anyway, congratulations. some more quality third party stuff to try and ignore (!).

#231505
Sep 1, 2012 at 9:42pm

I’m still trying to understand the justification for it. I saw the comment about projects with large signal flows but it looks like this solution is an attempt to impose standard OO-style programming into Max and with the sequence of objects that you have to create to make things work, I don’t see how it’s any different than just writing lines of text that execute sequentially.

It’s not clear to me that trying to make an event-driven, almost dataflow-like programming model be a traditional OO language is a step forward.

What am I missing?

(Apologies if I sound like someone on a thesis committee :-) )

#231506
Sep 2, 2012 at 8:21am

@pid — check out o.expr you can do all your processing on the bundle before routing it into max types, it’s kind of addictive : ) I had that thought also about the bach library, it seems like o.2bach/bach.2o could be interesting.

@dhjdhjdhj — basically it’s just the OSC format ( http://opensoundcontrol.org/introduction-osc ), but now you can actually do your processing on the bundle inside max, which lends itself to a certain elegance in programming style. for example, no need to unpack adjust and repack a list with different scalars, you can access individual array indexes and use them as you like, etc.

#231507
Sep 2, 2012 at 8:50am

@rama, thanks!

@dhjdhkdlkdjhlkd, and also, + what rama said, this means all handling of streams / data is much much faster with less (and predictable) latency than doing everything with osc + max messages. it seems, i think.

@John MacCullum, where is [o.grandstaff] then?!

#231508
Sep 3, 2012 at 3:23am

I see, so it’s a new data type, period. That data type just happens to be OSC

____________________________________
Love life, stay healthy and enjoy every day
http://www.mmolive.com/

http://www.mmohome.com/

#231509

You must be logged in to reply to this topic.