gbravetti

I would like to know which is the best approach to have two knobs linked together so any change on one will affect the other, also I would like to have one of them automated by a Clip's envelope that could be overridden manually when needed.

link-two-knobs-on-ableton-live

Will mapping both of the knobs to the same macro suffice? You can then automate the macro...

The idea is to unify on a single rack different parameters from different devices located on different tracks, but without loosing capacity of being modulated by it's own clip's envelopes.

Then from Push I can see and control all those parameters from a single device, and if I want to give back the control to a particular clip's envelope I just need to relaunch that clip, I use the actual clip for that, relaunching it with legato/ON allows me to use some clips as a "parameter recall" button.

Because envelopes are used basically to recall fixed values now I'm using live.observer and set and seems to work fine, may be it is a better way?

Ok, no, not sure there is a better way. That's what I'd suggest to do...

Have a look at this, maps 8 parameters to one parameter, on any track - 

http://www.maxforlive.com/library/device/2109/multimap-observer

Have a look at this, maps 8 parameters to one parameter, on any track - http://www.maxforlive.com/library/device/2109/multimap-observer


By coincidence I did borrow the learn function from the multimap-observer to use it on my actual device :P

The problem with the "multimap-observer" device is that it uses live.remote that takes over completely the destination parameter, so the destination parameter can't be modulated by their own clip envelopes nor manually.

Thanks I will stick with this way for now, as I said I just need to recall static values from the envelopes so there is no need of the speed and safety of the live.remote.

LEE,
Thanks I will stick with this way for now, as I said I just need to recall static values from the envelopes so there is no need of the speed and safety of the live.remote.


In order to not take over the parameter completely you can use a live.object instead. The only difference is that in order to use a live.object you will need a message box (or something similar) going into the live.object with [set value $1]. To adapt the learn function you just need to swap the live.remote with a live.observer and put the msg box in front of the left inlet. This should allow you to retain your modulation by clip envelopes and also move the parameter manually. You might have to watch that the parameter doesnt become disabled if youre trying to control it by two things at the same time (clip envelope and live.object)

BTW, have you also looked into Clyphx? It does a lot of what youre saying and more...

I'm doing something like that, anyway is not that simple, messages produced by the live observer works fine with the live.remote but when I try to use them to set the property value directly using the live.object set property value, it doesn't work.

Value is sent correctly and it reaches the live.object properly formatted but it doesn't produce any effect in the parameter. I discovered that if I manually bang the message I use to set the value all works properly, so for now I solved it by using a Metro object to get those missed "bangs"

May be is some kind of fool proof parameter feedback avoidance, implemented by Cycling74's guys.

I didn't try Clyphx but I have it in my todo list already.

I'm doing something like that, anyway is not that simple, messages produced by the live observer works fine with the live.remote but when I try to use them to set the property value directly using the live.object set property value, it doesn't work. 

May be is some kind of fool proof parameter feedback avoidance, implemented by Cycling74's guys. 

ok, but it should work. It sounds like you might have the message going into the wrong inlet of the message box, it should go into the left inlet.

There are only 3 differences between live.remote and live.object

1) live.object takes the "set value $1" message, instead of the value going directly into the inlet

2) live.remote doesnt add anything to the undo history, whereas live.object does

3) live.remote disables the parameter in live

To be clear the message live.object takes is "set value 0.234" where 0.234 = the value.

1) live.object takes the "set value $1" message, instead of the value going directly into the inlet
2) live.remote doesnt add anything to the undo history, whereas live.object does
3) live.remote disables the parameter in live

To be clear the message live.object takes is "set value 0.234" where 0.234 = the value.


The value produced by the live.observer is considered a "notification".

Setting a new value to a property is considered a "change"

To avoid potencial errors on the Live API "changes" to a Live Set or its properties cannot be triggered by a "notification".

This is why you can't use just the value that comes from the live.observer to send a "set value" message. You need to bang it manually or with the help of a metro object.

The value produced by the live.observer is considered a "notification".
Setting a new value to a property is considered a "change"
To avoid potencial errors on the Live API "changes" to a Live Set or its properties cannot be triggered by a "notification".

This is why you can't use just the value that comes from the live.observer to send a "set value" message. You need to bang it manually or with the help of a metro object.


yes, this problem will always exist with bi-directional movement. While you cannot solve the problem entirely, it can be alleviated somewhat by the use of a gate:

Stephane is correct, this is exactly where the deferlow object should be used for processing notifications in M4L

Hi Stephane, where do you put the deferlow object? In the patch I posted I tested deferlow in front of and behind each object and none of them solved the feedback loop issue. If theres a way to do this Id love to know. If the gate is removed from the patch an endless feedback loop is created (the dials/parameters react in a very jumpy way and dont stop moving until a patch cord is removed)

I'm using the Change object to avoid feedback loops, I will try the Deferlow object.

NEWTFISH,
I'm using the Change object to avoid feedback loops, I will try the Deferlow object.

Deferlow makes data from live.observer usable, anyway for my particular situation doesn't works as expected, remember that param A controls B and at the same time B controls A and also A or B can be controlled by a Clip's envelope, so the best so far is to have a master clock (Metro) to control data flow. This way all is working fine so I'll go this way for now.

I tried your code and the Live.dial doesn't move, actually I think you can't move a live.dial with data produced by a live.observer, I tried to do the same from scratch and the dial moves till you save your patch, then it get stuck.

If you close the patch, you will need to set up the observer/object with the IDs again (these are not saved in your patch). Why not attach a loadbang to them?

The patch works perfectly for me. Bidirectional control, using the gate (which switches on/off depending on whether the observed param is being moved).

Try testing it with an "audio effect rack" as device 0 on track 0 (worthwhile paying attention to the fact that the scale of the live.dial is the same as the 1st param of the rack ie 0-127 as opposed to 0-1).

Deferlow does not work in this situation (you still get a huge feedback loop).

Using a metro is another way, but it seems less efficient to have metros counting vs using a gate to shut off the loop when its not needed.

The main issue I think youre going to run into is that there is no way of detecting when a parameter is being automated by a clip envelope, vs being moved by M4L. With live.object you will be able to move the parameter at the same time as the clip envelope. However, your parameter will become disabled (by clip envelope movement). One way to overcome this is to use M4L to turn off the "return_to_automation" button, or you could use "clip modulation" instead of automation, but im not sure that's what youre after.

I made a slight change to the patch to ensure the gate is initially open

The patch works perfectly for me. Bidirectional control, using the gate (which switches on/off depending on whether the observed param is being moved). 

Try testing it with an "audio effect rack" as device 0 on track 0 (worthwhile paying attention to the fact that the scale of the live.dial is the same as the 1st param of the rack ie 0-127 as opposed to 0-1). 

Deferlow does not work in this situation (you still get a huge feedback loop). 

I made a slight change to the patch to ensure the gate is initially open


Adding a load bang to test it directly on Live was the first thing I did and it doesn't worked here, if you want do the corrections/additions to your code and share it here again I-ll be pleased to test it.

May be I wasn't clear so I will state again:

My approach is working perfectly, A controls B and B controls A, and A or B can be taken over by an envelope (not need to be a fixed value can be a ramp or whatever) and after that you can take over control again even moving knobs A or B, by mouse or Push controller.

No need to do corrections. The code works just fine.

Do you think I can replace the Live.Dial with a live.object and live.observer etc., in order to link Macro knobs 1 and 2 instead of Macro 1 and the live.dial?

Its a bit flakey (lots of notifications errors). Im sure there are more efficient ways of doing it, but technically it works. 

I see, it is like you said, it works but is a bit unstable, the envelope control doesn't last (it's own value make it loses control), and in some situations it went to a weird fast oscillating state, not good for the undo buffer :P

Now I'm a bit in a hurry so I will stick to the "Metro" approach that so far it is working pretty stable and light, next week I´ll take a deeper look to the code.

NEWTFISH,
I see, it is like you said, it works but is a bit unstable, the envelope control doesn't last (it's own value make it loses control), and in some situations it went to a weird fast oscillating state, not good for the undo buffer :P

Yes, im interested to see how this can work also. It should work, I think, if the delay times are right, they should not cross each others path.

I know this is an old thread, but I found the solution https://tomcosm.gumroad.com/l/vZYDi

link two knobs on Ableton Live