Extremely Urgent! OSC slowing whole Patch down?

    Jun 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

    • Jun 19 2012 | 6:48 pm
      Does processing any OSC messages re-trigger you rhythmic events or timing?
    • Jun 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.
    • Jun 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 ?
    • Jun 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.
    • Jun 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.
    • Jun 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.
    • Jun 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?
    • Jun 19 2012 | 8:54 pm
      no overdrive isn't enabled, my signal and io vector size is 256
    • Jun 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
    • Jun 19 2012 | 9:10 pm
      people will be able to help you much quicker if you post a patch...
    • Jun 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!
    • Jun 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 :)
    • Jun 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.