automated dial to control another dial, slow, laggy
Hi,
I am controlling many dials by one dial. However, when I automate the one dial, live becomes laggy, so much so that it locks up and I have to restart. Then I cannot reopen the liveset (live gives me an error like "action, delete.do")
Is there something fundamentally wrong with controlling dials with other dials? Is there some specific way of doing it that will result in the desired outcome? ie When the one dial is changed, all dials update, but each controlled dial can be edited on it's own.
Cheers
Are you controlling dials that are part of Live devices, or are they all contained inside of your patch?
I have one max dial, that controls eight other max dials, that each control a live.remote of a parameter on a livedevice. Is this the wrong way to do it? Is there a smart way to do this?
Are you sending control rate or signal rate signals? I had a similar issue where I was automating 8 sends on 8 different tracks (64 dials) this would get laggy. I would recommend making all of the data signal rate (using sig~), then downsampling that data with downsample~. That should help with the performance issues. Let me know if this helps!
-E
I agree with Evan about using audio rate. It's better because it's not sending commands to the scheduler, where it can get hung up. I work with big sets, with lots of data rate and audio rate objects. One thing about the data rate objects (objects without a "~") is they may be working correctly, but the graphics may not be updating in time. So dials may visually appear to lag, but are not. I've gotten used to seeing things not always update in real time, like presets. But if you need accurate visual feedback then the audio rate route may be the way to go.
In this case, does it make sense to switch to audio rate, just before the live.remote e.g. by using downsamp~?
[Data signal]
[downsamp~]
[live.remote]
Ive seen a couple of other patches doing this.
Also, does signal rate vs data rate differ in CPU when using live.remotes?
You'll want to throw a [sig~] between the data and the [downsample]. I think...Not sure if it's it's completely necessary, jsut something that I always do.
I haven't done any extensive testing on CPU load differences between data and audio rate, but from my experience, I tend to always use audio rate downsampled, unless it is necessary to use data and a live.object (for recording automation for instance, you can't record automation on a parameter that is controlled by a remote).
Moving dials and any other dynamic GUI element increase CPU usage. It's good to avoid them, if possible. I was surprised to see how much that matters in Live.