Hey Guys, I'm working on a Sound Installation and received the controller for it today.

It's a Lemur Controller and I Use it to send OSC to MAX 6.

The Patch is about Sound generation on a strict rhyhtm. When Changing the Parameters via mouse inside the Patch everything is working to 100% correctly.

When send OSC to the Parameters the Sounds are Produced, but the whole rhythm isn't straight anymore. It sounds like Max can't keep up with Calculating but CPU is at 40% and no DSP failures either.

I tried to put a speedlim object infront of the UDPreceive, still no change.

Does anyone have an Idea what could be the cause of that problem?

It's a Lemur Controller and I Use it to send OSC to MAX 6.
The Patch is about Sound generation on a strict rhyhtm. When Changing the Parameters via mouse inside the Patch everything is working to 100% correctly.

extremely-urgent-osc-slowing-whole-patch-down

Does processing any OSC messages re-trigger you rhythmic events or timing?

It's all controlled with float objects and the OSC messages only go into those. When chaning the float objects via mouse everything is ok. When changing them with OSC everything goes crazy.

It has happened to me when I was monitoring the OSC datas via the Max window with print. Probably too much datas in a short time ?

How is the rhythm controlled? Is it MIDI based? If so, do you have Overdrive enabled?

I am using the LEMUR app on an iPad and I have a very fast MIDI loop running in Max (I'm working on replicating On The Run (Pink Floyd)) and I send in OSC commands from the iPad to adjust various synth parameters in real time (filter cutoff, LFO depth and rate and so forth, volume) and I have not noticed any impact on the rhythm at all.

The Rhythm is created generatively in Max. I'm going through the whole patch and try to put some speedlims where it's possible to control the data flow. Maybe it's gonna help.

But why it's not enough to put speedlims after the UDP receive?

seems to work.
But why it's not enough to put speedlims after the UDP receive?
Really confusing for me.


Throwing in arbitrary speedlims without actually understand what's going on is really not a good idea.

I ask again, do you have Overdrive enabled?

no overdrive isn't enabled,
my signal and io vector size is 256


i put the speedlims mainly in front of many scale objects, from which I only grab the float every 200ms or so

people will be able to help you much quicker if you post a patch...

Thanks guys I think I figured it out. Enabled Overdrive and in Audio Interrupt and used some Speedlims.

Thanks guys I think I figured it out. Enabled Overdrive and in Audio Interrupt and used some Speedlims.
Works alright again!


if you now lower the vector size to 32 you can actually start using it as a sequencer application for audio :)

You might want to try deferlow, rather than speedlim, after udpreceive. I think these packets come in on a high priority thread, and it sounds like you don't want that.

You might want to try deferlow, rather than speedlim, after udpreceive.  I think these packets come in on a high priority thread, and it sounds like you don't want that.


Extremely Urgent! OSC slowing whole Patch down?