live.object + for remote control: how to prevent a feedback loop?

    Dec 30 2011 | 3:47 am
    Hi guys -
    for my TouchOSC remote controller I'm using live.object to remotely set parameters: I chose this over live.remote because I don't need a superfast response, and the lower overhead + the fact that you can still control the parameters with the mouse.
    I do want the TouchOSC to be updated when I change the parameter in Live with the mouse, so I have a potential feedback loop: TouchOSC changes a LIve parameter via live.object -> the change is picked up by -> the controls the same TouchOSC object etc.
    Now I don't get a real feedback loop: no crashes, but the performance is far from smooth: I can see the fader in Live as well as on the TouchOSC jump back and forth. I'm guessing someone has already solved this problem! (please?) My thinking currently is just to disable feedback from while the TouchOSC controls a parameter.
    your thoughts are much appreciated :-)

    • Dec 30 2011 | 11:03 am
      This can usually be solved with a 'set' message to prevent output on change.
    • Dec 30 2011 | 2:41 pm
      yes.. I saw that but didn't think further how it relates to my problem: I"m controlling from TouchOSC: I actually don't think that fader outputs data when it is updates.
      Doing a little thinking here, when I move a fader up on TouchOSC:
      TouchOSC fader sends a series of new values -:> Live parameter is updated through live.object (slow) -> picks up the updated values and sends it out to the TouchOSC fader
      I suspect that but by the time the updated values from reach the TouchOSC fader, my hand has already moved up a a bit, so the new value from makes it jump back.
      Seems like the best way for me is to cut off the updates going to the TouchOSC at any time that the TouchOSC fader is sending out updates.
      Think I'm understanding why live.remote works: it's so much simpler if you deny other devices to control a parameter: you don't need feedback at all :-) btw my Zero SL Mkii can still remote parameters that are 'hijacked' by live.remote - in which case the paramter value in Live and the value on the max slider that remotes it go out of sync.
    • Dec 30 2011 | 5:50 pm
      In doubt I would use some 'print' objects at critical points to see what's actually happening.
    • Nov 01 2012 | 3:28 pm
      Update on this - I have it working but I'd love to find a more elegant way, especially one that scales better.
      THE PROBLEM: * TouchOSC controls Live using [live.object] * Live sends back fader positions using a []
      because it takes a while for the feedback from LIVE to arrive at the Ipad, and by that time my finger has moved on, the feedback from Live makes the fader jump back so I get quite a jerky behaviour.
      MY (CLUMSY) SOLUTION: A [gate] to block the feedback values coming from LIVE while I'm operating the Ipad. it has a 200 ms delay, after which updates from Live are allowed through again. It's a bit clumsy and a lot of code: and I need both the stream from the Ipad to LIVE and the stream from Live to the Ipad, and I need the logic for every single parameter - I don't like it much.
      Any ideas for a more elegant way to prevent the jumping around of faders?
      Here's a snippet of the part that generates the signals to open and close the gate:
    • Nov 01 2012 | 8:57 pm
      Instead of using gates you could also ignore the values directly, like this.
    • Nov 02 2012 | 10:19 am
      perhaps this helps,, TouchOSC is able to send per object touch messages (Z messages in touchosc options) when you touch an object, z=1 then,, if z=1 close the gate to prevent update, if z=0 open the gate to update the parameter because you are not touching it... make sense?
    • Nov 02 2012 | 2:44 pm
      I hadn't thought of that - really nice idea. It would get rid of the need for a delay (the 200ms is a bit random)
      still the structure is a bit kludgy - will still need to listen for input from TouchOSC to gate message coming back.. but there may be no way around it..
      Will definitely implement your suggestion, and also continue puzzling for a more nimble solution.
      Thanks Carsol!