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

Basvlk's icon

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 live.observer -> the live.observer 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 live.observer while the TouchOSC controls a parameter.

your thoughts are much appreciated :-)

broc's icon

This can usually be solved with a 'set' message to prevent output on change.

Basvlk's icon

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) ->
live.observer picks up the updated values and sends it out to the TouchOSC fader

I suspect that but by the time the updated values from live.observer reach the TouchOSC fader, my hand has already moved up a a bit, so the new value from live.observer makes it jump back.

Seems like the best way for me is to cut off the live.observer 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.

broc's icon

In doubt I would use some 'print' objects at critical points to see what's actually happening.

Basvlk's icon

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 [live.observer]

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?

Max Patch
Copy patch and select New From Clipboard in Max.

Here's a snippet of the part that generates the signals to open and close the gate:

broc's icon
Max Patch
Copy patch and select New From Clipboard in Max.

Instead of using gates you could also ignore the values directly, like this.

carsol's icon

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?

Basvlk's icon

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!