Forums > MaxMSP

Efficient OSC routing

November 21, 2009 | 6:57 pm

Hi all,

Well after a solid week of experimenting, learning, reading, experimenting, grinning, noting, swearing and then grinning again I have got to the point where I’m feeling pretty comfortable working with Max in a general sense. A sure sign I’m progressing is an increasing awareness of how little I know so far!

I’m working on an application which will be making heavy use of OSC and MIDI. For clarity in my patch I’ve created subpatches for the following:

- Sending OSC
- Receiving OSC
- Sending MIDI
- Receiving MIDI
- Several ’1 inlet, multiple outlet’ subpatches that encapsulate related blocks of ‘route’ objects to filter by OSC input parameters
- Several ’1 outlet, multiple inlet’ subpatches that encapsulate related blocks of ‘prepend’ objects to insert various slider/knob values into outgoing OSC messages
- As above, but using message boxes to form MIDI SysEx strings (which are lists of integers – ‘strings’ is the MIDI terminology not a datatype in this context)

So far it’s actually looking pretty nice to me, and it’s working wonderfully.

Given that the scope of this project is actually fairly large, and I anticipate that I will end up with a patch (containing a lot of subpatches) that will be dealing with hundreds, if not thousands, of OSC messages I was wondering two things:

1) Is the use of multiple ‘route’ objects the best way to handle an OSC input stream (coming in over updreceive) or is there a more advanced database/internal data structure method that I can use for some kind of lookup table, and should be studying in order to make use of it before I get too far?

2) After various internal processing, the patch needs to spit out MIDI SysEx strings with custom values embedded in them. A SysEx string is essentially a list of integers, typically 10-12 items long. 90% of the time, the SysEx strings consist of a fixed set of integers and I only have to vary 2 or 3 values in that list depending on the source of the value I’m inserting into it. Currently I’m using lots of message boxes with $1, $2 etc. placeholders to do this. Related to the first question above I guess – is there a better way to do this that you can point me in the direction of?

To put that second question another way, if I had 500 sliders and when I move any given slider I wanted to generate an integer list of the form: (n, n, n, number_of_slider, n, value_of_slider, n, n) where ‘n’ is a fixed integer, is there a better way than to insert a message box after each individual slider with the fixed values and $ variables supplied to it for the ‘value’ and ‘number’ members of the list?

The reference to paranoia in my message title is to do with a concern that performance/throughput may drop if I end up putting hundreds of ‘prepend’ ‘ route’ and ‘message’ boxes across all the data routes.

I’m not after anyone doing the work for me, I’m pretty self-sufficient generally. I would just appreciate the benefit of your experience and a pointer or two to a relevant documentation section if you’ve come across this kind of application before!

Many thanks,

Eddy

The below is a simple example of one of the subpatches I’m talking about in my second question. The inlets would all be fed by individual sliders, each outputting a value from 0-127 in this example.

– Pasted Max Patch, click to expand. –

November 21, 2009 | 7:30 pm
Eddy wrote on Sat, 21 November 2009 10:57
Hi all,
1) Is the use of multiple ‘route’ objects the best way to handle an OSC input stream (coming in over updreceive) or is there a more advanced database/internal data structure method that I can use for some kind of lookup table, and should be studying in order to make use of it before I get too far?

You might want to look at the OSC-route object at http://cnmat.berkeley.edu/downloads

mz


November 21, 2009 | 7:31 pm

after only one week, many people do not even know what a "patch" is.

re: lookup database

that could be done with [coll], which stores lists or symbols
which can be called by an index.

if i am not wrong, route is far more CPU efficient, but as you
noticed, [route] starts to suck when you need 100 different filters.

if you think you can handle those already be informed that
there there are tons of third party externals, one of which
connects max to a SQL database.

many here would probably also tell you to do it with java …


November 21, 2009 | 7:48 pm

Thank you both.

*Ideally* I’d do it using existing Max internal default objects, as this leads to fewer potential issues with cross-platform building and distribution of standalone apps to a userbase. I had wondered about coll – thank you for reinforcing that curiosity! I will learn how to use it by building a test patch using it to compare the performance against a lot of route objects. Seems like a worthwhile endeavor…

I could use Java, – I’m not a great Java fan but it is a good way of building something custom quickly. The main issue I have with Java is the autonomous nature of its garbage collection which can cause problems when you are doing anything related to audio and/or realtime or pseudo-realtime applications (mine falls loosely in the latter category.)

Fortunately I’m no newbie to code or computers, just to Max itself. My job is writing Deep Packet Inspection software for customers who are ISPs and Telcos etc., so I grok the Max paradigm, I guess I’m impatient to absorb the range of objects on offer as once I have that awareness I’ll be able to work very quickly using it, and I am a great believer in building things the right way from a very early stage in the development cycle.

Thanks again for the suggestions, all input is good for me at this point in my learning curve

Eddy


November 21, 2009 | 8:01 pm

Hi Eddy,

There are a lot of good docs in Max to get you started.

You may want to look at the lists "Max Objects by Function" and the Max tutorials (indexed by subject). Both are accessible from the Help>Max Help menu item.

You may take an extra look at the lists section especially the zl object.


Viewing 5 posts - 1 through 5 (of 5 total)