Forums > MaxMSP

Extremely Urgent! OSC slowing whole Patch down?


Sym
June 19, 2012 | 6:37 pm

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?

All the best,
Imbie


June 19, 2012 | 6:48 pm

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



Sym
June 19, 2012 | 6:54 pm

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.


June 19, 2012 | 7:40 pm

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 ?


June 19, 2012 | 7:49 pm

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.



Sym
June 19, 2012 | 8:18 pm

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.



Sym
June 19, 2012 | 8:24 pm

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


June 19, 2012 | 8:33 pm

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?



Sym
June 19, 2012 | 8:54 pm

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



Sym
June 19, 2012 | 8:55 pm

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



dtr
June 19, 2012 | 9:10 pm

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



Sym
June 19, 2012 | 9:19 pm

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


June 19, 2012 | 9:57 pm

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


June 19, 2012 | 11:37 pm

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.


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