live.object + live.observer for remote control: how to prevent a feedback loop?
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 :-)
This can usually be solved with a ‘set’ message to prevent output on change.
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.
In doubt I would use some ‘print’ objects at critical points to see what’s actually happening.
Update on this – I have it working but I’d love to find a more elegant way, especially one that scales better.
* 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?
Here’s a snippet of the part that generates the signals to open and close the gate:
----------begin_max5_patcher---------- 1116.3oc4ZFsaaaCEF9Z6mBBcsWhHoDoTw5ECq6h.LrMrTTLrhgAZKZa0JSY HQmk1h9tWIJqjrNFKxjzyB.uHxPGIQ8yO9enNTJeZ9rnk0WKaiPu.8VzrYeZ 9rYlP8Alcb+YQ6DWupRzZNsnU061IU5nECGSKuVah2VtQIpZQ5sBMZUsR2TW gxtFsQnksnRU2Ajn0RYwRwp2i1KzaQqap2g94xqjHcs4vWrWTbFBM11UkJ4p 5CJyMfdLn5vtRUkTaTC9Xv0c2u1xOJMwHmEe64VePOdxiQW2rYoY+aNuN0rZ aoZye2HWoGfAKo6nHZBt+GbNq+mD9Ywn+530TVX510Ke22QitiLThcFYD8CM khpn9C744y62r3QR3u+kuDcgp6ncJEMhaCCGY2Bzud4OhVW2rSn0xBqbj7+A GSRMXL0fQJ0NFIOsXbPwisYmrFn3k5lNE11SIzqqOrZaGxdA57KkUutoyYd9 u2s42DMhcmewu7pe5OPWIpNHWfpDKkUKPBUA5MW7mlqdYsd61w1WnT0ZgtrV 8s7tXcPy9nikwBZ7fm1LXPtYqUKc13sbzM9snW8.FUMceq3vtYcDRCgzeXub fEQQ2zsuWR4BnRrBpGROSI+mtF7+j0qQ3nGcJ68RASVwI.AefDD5.DLIyjX6 n.Gm7zlA+rjHLuHBN.HRpWDIN.HRhGDIOO..B0GfjE..g3CPXA.Pv9.jzPHk wCdPAgGqOnTxt0zYEJYOIPopr0IpvM+vw4mBKYvfkltdgzZQvXqQIViRsFMw ZzTqQYVixsFMy8kFl6y.a98Vs8hI9a5A8by1rgw76aMj4DPFyKjUhOzY7hsl KPdRxEVJTabIW.adEEL5oREnPUG5RT7ieNSxIQxBWm6DmQL9lzSVPZZ3XXvd 3XXrfxwf8vxv3gikg3ikIKnrLDerL4Azik7vxviCqmK4gkgiCGKShOVFRPYY R7wxPCGKSpOVljfxxj5ikIfJ+k4ikIrJ+k4ikIfJ+k6gkAyCJKC2GKiik+Zt Vy6j5q9WRwb+6i+u4Ua8glUiBeboYnakPgrUWpt4qx+1aWZ6cNoskEER0c+B xEkshkURi9isNx4rdXNnm9WmMT5I2E9jAmdxbgOvMd0Wz8j5oeQKPomXW3Cb iW8UXNMeHvoGhK7IGN8j5BeRfSOINnGy2jGJA4xDzb.S3YNAHLbBxkYnwbvz Cl6DffyRScYJ5bJb.xkTdJbFnuNa1tf5+1nnTfDD1UAw.RPItJHNbVHrK5AF KThSUkA2S4MU06DevvUEsS5g.WUqNoGJbUI5jdRfqpL7ymYD4N6mYvUyA94y 7g4tTUOFtUMazyT7gwgUOjozSNr5gNUQ8XX0SxT5gBqdRmRO.6mYSoGf8y7o zCf9Ypq0GBjdRcUOvT+SNyU8.S8O4YtpGXp+IO2U8.S8OYt3moOz2h3vKsWr e+Uxl1isoQJQ6DuqtoeW1BytkpgcMsXTi7pxwymOuu0977uvNaZWk -----------end_max5_patcher-----------
Instead of using gates you could also ignore the values directly, like this.
----------begin_max5_patcher---------- 375.3ocwTFsaBBCEF95xSQSulYZqfts61dMVLKEZmVCzRfZlNiu6id.1zEch ZBdCM8bNzye+3+v1.DIwtVUQvOieCiPaCPHHjO.pcOhjKVmlIpfxHlU4IpRR XSp5c1UtLkCRxai1DxsoP0bxDswQBwjDgYNAOqspOrFWk9KnFFcDsMbgvktP al+doJ0079rXdcZLOZheI1WKl83H5OGkVBZylr7g38jl1zoL1d8zHxgdRdoT KxvuZyjDe1cAA9Gg8EDpOq6WW2bp0fXIRUlXS88gRONiXmhQWMbnSAdLIxuL g8evI5nvgOXvwgSv5Kz6.bIrwCc8dGF6I+xX9n3SimwCl249MDMM57yP767L DbSungmq1b.iKbZ74MGrac1ANTRl172e3BByG+PRUYWUl1cAasm3eklTU4zF gSaM6USzA0rPKkJHcGDx0xBaMsZk.d1Q+p0WEE0CEwFTEw5ghhGTE4+pw5Ai XClh38fQiuAFUuYWv2frIztp -----------end_max5_patcher-----------
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…
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.