many sliders to multislider with offset value

    Dec 02 2013 | 4:59 am
    I am using max midi patches with many sliders in live to send artnet information to another patch. When using a lot of channels and many universes the CPU goes crazy even when using only a few sliders with automation. Tried to change slider's latency to 20 but there are times that the information is so much that gets an 8-core macbook to its knees.
    So trying to redesign my patches I was wondering... Is there a better and lower cpu intensive way of doing this?
    Thank you in advance

    • Dec 02 2013 | 7:38 am
      Please post the other part of your patch that's on the receiving end of the [s toArtNet] - the problem is that every time you send even the smallest message you're outputting a whole universe of data - that's rather silly, you'll want to only transmit the data entry that's different from last time. So while what you have there is somewhat sound code, the rest of the patch very well isn't.
      I still think feeding into a large multislider is actually a cool way of handling things in a way, since it provides some neat pattrstorage properties, but in order to get that going properly you'd need some feedback from the multislider out to your live sliders. It's worth considering, even though it doesn't affect the efficiency of the patch.
    • Dec 02 2013 | 7:56 am
      Thank you for your kind feedback. Plz forget the rest of the patch. Even if i delete the sending patch the main CPU footprint comes from this (sliders, list and select patches). That is what I ask, if there is a better way of organising this mesh and if using jit or not will make any difference cpu wise :)
    • Dec 02 2013 | 1:25 pm
      woah. I'm inclined to think there's something wrong with your computer almost - you're saying that a few sliders and a single big multislider is enough to almost kill your pc?
      I can't currently throw anything at your patch to make my mbp struggle, or even get warm.
      Are you using the latest version of max and all that?
    • Dec 02 2013 | 1:38 pm
      Well, multiply it by 100 devices automate each like crazy and then tell me how is ableton running while playing all of these. It is a sensitive cpu question, if you can give any good hint please do.
    • Dec 02 2013 | 4:50 pm have a hundred of these going at once? So how do you know that it's not just Live struggling to keep up with automation?
      What's your ram situation when running that abomination? And you're saying that you have the problem even if you "only" run the slider patches and you close the actual artnet sender?
      So when you say: >When using a lot of channels and many universes the CPU goes crazy even when using only a few sliders with automation.
      you mean you're using hundreds of sliders?
    • Dec 02 2013 | 4:51 pm
      I'm wondering if it'd help to have fewer devices with more sliders instead.
    • Dec 02 2013 | 8:26 pm
      Use [change] or anything that would not put data through if you have no change.
      You may want to use [speedlim], [defer] and/or [deferlow]
      Try to use as less UI object as possible. (message is an UI object)
      If you need UI for visual feedback, you may want to have it refresh not really often, but have the data going to whatever that is doing.
      Have a look on the forum for slow interpolation, even on the Max forum. I used [pattrstorage] for interpolation of hundreds of UI objects and I got similar issues.
      Maybe you'd want to use your multislider directly, with [pattrstorage].
    • Dec 03 2013 | 2:05 am
      Thank you Musinou that really helped. You gave me the idea of using only one multislider than many sliders. I ll check to see how automation reacts with this. cheers
    • Dec 03 2013 | 2:12 am
      Do you think gen will do better, should I purchase it as to create an AU device and use it instead? any other recommendations would be really appreciated
    • Dec 03 2013 | 8:39 am
      I would try having only one device with many sliders instead.