ATelichan

I am bringing data into a Max patch from 15 different streams (3 axes from 5 accelerometers). The data is coming through python, where it is formatted and sent over OSC in a series (so, sends streams 1-15 in sequential order), and then to the OSC-route object.

In a test with a simple patch, everything was working fine. However, with a computationally more heavy patch, I cannot seem to run the system without immediately getting a stack overflow error. This happens even when I significantly slow down the time between the incoming discrete data points, when I reduce the number of data streams coming in (going from the 15 original, to 5, to 3), or when I do both.

I recognize that I might just be pushing my patch too hard, but I was wondering if anyone else had encountered a similar issue and had any high-level suggestions. Are there known issues concerning OSC-route? Does anyone have an alternative suggestion as to how I might bring my data into Max?

I am happy to share any further details, should they help clarify the issue.

I am bringing data into a Max patch from 15 different streams (3 axes from 5 accelerometers).  The data is coming through python, where it is formatted and sent over OSC in a series (so, sends streams 1-15 in sequential order), and then to the OSC-route object.

In a test with a simple patch, everything was working fine.  However, with a computationally more heavy patch, I cannot seem to run the system without immediately getting a stack overflow error.  This happens even when I significantly slow down the time between the incoming discrete data points, when I reduce the number of data streams coming in (going from the 15 original, to 5, to 3), or when I do both.

I recognize that I might just be pushing my patch too hard, but I was wondering if anyone else had encountered a similar issue and had any high-level suggestions. Are there known issues concerning OSC-route?  Does anyone have an alternative suggestion as to how I might bring my data into Max?  

stack-overflow-error-with-arduinoosc-route

I've had some issues with the whole OSC package from cnmat. You can easily do without using [udpreceive] and [regexp] and such. E.g. here's a little something that receives accelerometer data from OSC Piano (iOS app):

Thanks for the patch. Will have a look at it.

Fortunately, I traced the problem to a single "wiring" error within a tertiary-level subpatch. The scale value that was being used to scale the incoming serial data was accidentally feeding back on itself. Strangely enough, the patch was running fine when I was automating data changes using metro objects at comparable rate. As soon as the Arduino was hooked up, it broke down. So, I was a little surprised and just assumed it was something to do with OSC... but it was just my own careless mistake.

Thanks for the patch.  Will have a look at it.

Fortunately, I traced the problem to a single "wiring" error within a tertiary-level subpatch.  The scale value that was being used to scale the incoming serial data was accidentally feeding back on itself.  Strangely enough, the patch was running fine when I was automating data changes using metro objects at comparable rate.  As soon as the Arduino was hooked up, it broke down.  So, I was a little surprised and just assumed it was something to do with OSC... but it was just my own careless mistake.

Stack Overflow error with Arduino/OSC-route