|
|
Jun 19, 2012 at 6:37pm
Extremely Urgent! OSC slowing whole Patch down?
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
|
|
|
Jun 19, 2012 at 6:48pm
Does processing any OSC messages re-trigger you rhythmic events or timing?
|
|
|
Jun 19, 2012 at 6:54pm
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.
|
|
|
Jun 19, 2012 at 7:40pm
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 ?
|
|
|
Jun 19, 2012 at 7:49pm
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.
|
|
|
Jun 19, 2012 at 8:18pm
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.
|
|
|
Jun 19, 2012 at 8:24pm
seems to work.
But why it’s not enough to put speedlims after the UDP receive?
Really confusing for me.
|
|
|
Jun 19, 2012 at 8:33pm
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?
|
|
|
Jun 19, 2012 at 8:54pm
no overdrive isn’t enabled,
my signal and io vector size is 256
|
|
|
Jun 19, 2012 at 8:55pm
i put the speedlims mainly in front of many scale objects, from which I only grab the float every 200ms or so
|
|
|
Jun 19, 2012 at 9:10pm
people will be able to help you much quicker if you post a patch…
|
|
|
Jun 19, 2012 at 9:19pm
Thanks guys I think I figured it out. Enabled Overdrive and in Audio Interrupt and used some Speedlims.
Works alright again!
|
|
|
Jun 19, 2012 at 9:57pm
if you now lower the vector size to 32 you can actually start using it as a sequencer application for audio :)
|
|
|
Jun 19, 2012 at 11:37pm
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.
|
