[OSC_dev] cnmat max objects for osc

[Andy W. Schmeder]

On Dec 21, 2008, at 9:17 AM, Nick Rothwell wrote:

> The CNMAT objects for MaxMSP have been pretty much dead since Max 4.6,
> and are certainly dead in Max 5, replaced by built-in UDP/OSC objects,
> so it's not very surprising that there's not much support effort for
> them. OSC-route still sees some use, but that's basically string
> manipulation and Max has many other ways to achieve that.

Its not that there isn't much effort to support them, but rather that  
the protocol format has been stable and unchanging for a long time so  
there isn't a need for new features (there are some needs, but thats  
another topic).  The only object that is actually obsolete is the old  
otudp object which is now replaced by the builtin udpreceive.

However, the "built-in" handling of OSC in MaxMSP is woefully  
incomplete.  It cannot handle any type other than i,f and s.  It does  
not deal with OSC bundles.  The CNMAT objects are currently the only  
way to create and parse bundles in that environment.  (use udpreceive  
with the "CNMAT" flag for this to work).

For our internal projects we use it extensively for this reason.  But,  
most of the rest of the world doesn't (yet) realize the value of time- 
semantics so they don't care about bundles.  Its a bit more complex  
than that, of course, since in theory most of the advantages of  
bundles should eventually be transparent to the user (e.g. transport  
jitter correction, or as an interface to languages with strong timing  
semantics).

Interestingly the OSC bundle has no equivalent construction in MIDI.

FWIW, OSC-route implements wildcard matching in a way that is much  
easier to understand than the fully-general regexp syntax...


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu