Hi, how do i link 2 or more faders to refresh each other ?
i mean, i have midi feedback, and if i move a fader from pc all faders refreshes, while if i move a fader from lemur the other faders that are assigned to the same midi cc doesn't refresh.
i've tried enabling midi thru on reaktor knobs/faders but i get the faders moving very badly, as there's a midi feedback.
in TouchOsc i've workarounded it by using a macro in reaktor, that sends the value to the controller when it is idle for at least 1 second, the problem is that it is a bit buggy with lemur, so i would like to be able to link faders and button inside lemur.
i think maybe the main fader is linked by midi to reaktor, while the others will be linked to the main one, without midi assignments, so when i move the "slave" ones the main will move and send midi, and reversely when i move the main one the slave move accordingly, is that possible ?
Obviously when the main one receives midi cc the slaves moves aswell.
i need this because i have the same controls on multiple pages, another option would be to get the actual values in the current page and refresh to the new page when i change it but i guess is more complicated this way.
thanks
linking faders/button
Re: linking faders/button
There are two easy and fully reliable ways to deal with the issue.....
In essense, we have multiple objects in Lemur, all controlling the same midi CC, note, or any other message.
1st: IF we really just want a simple re-iteration so to speak of a given object - in other words if we want the exact same object in type, dimensions, color and other attributes then we create an alias for it
alias of an object - a feature not mentioned in the manual I think - while in editor (not the in app) right click on an object and "create alias".. The "alias" object can be moved anywhere in the template and will be totally "linked" to the "aliased" object in terms of attributes, expressionsdimensions and MIDI - OSC mappings. Its sort of a clone of the first object.
For big projects, I believe, its actually worth thinking about the taxonomy of things so that you are more likely to use aliases than secondary objects (case no2) as these do not eat up memory like duplicate objects would.
2nd. In the case that we for example want a fader in one inerface and a knob on another to be linked (sned the same midi message) I have found that for the reasons you noticed the best way is to map only one object to the actual midi parameter and then just link it with the other via scripting....
For example if wer have LeveFader and LevelKnob objects....And we have LevelFader sending on CC21....
We add script in LevelFader
on expression x, any
and in the LevelKnob we add script
on expression x, any
Ok? So now, whenever ANY of the two moves, the other one will follow - the "source" of movement, (being you touching one, or receiving feedback) is irrelivant.
So, I repeat, you map ONLY one of them to actual Midi or OSC which will obviously receive the feedback too - this way you are saved from all the erratic-feedback-surface-software-catching-up behaviors.
In essense, we have multiple objects in Lemur, all controlling the same midi CC, note, or any other message.
1st: IF we really just want a simple re-iteration so to speak of a given object - in other words if we want the exact same object in type, dimensions, color and other attributes then we create an alias for it
alias of an object - a feature not mentioned in the manual I think - while in editor (not the in app) right click on an object and "create alias".. The "alias" object can be moved anywhere in the template and will be totally "linked" to the "aliased" object in terms of attributes, expressionsdimensions and MIDI - OSC mappings. Its sort of a clone of the first object.
For big projects, I believe, its actually worth thinking about the taxonomy of things so that you are more likely to use aliases than secondary objects (case no2) as these do not eat up memory like duplicate objects would.
2nd. In the case that we for example want a fader in one inerface and a knob on another to be linked (sned the same midi message) I have found that for the reasons you noticed the best way is to map only one object to the actual midi parameter and then just link it with the other via scripting....
For example if wer have LeveFader and LevelKnob objects....And we have LevelFader sending on CC21....
We add script in LevelFader
on expression x, any
Code: Select all
LevelKnob.x=x;on expression x, any
Code: Select all
LevelFader.x=x;So, I repeat, you map ONLY one of them to actual Midi or OSC which will obviously receive the feedback too - this way you are saved from all the erratic-feedback-surface-software-catching-up behaviors.
Re: linking faders/button
many thanks for your informative answer.
i can't make aliases cause i need to resize some of them.
i've tried using your script suggestion, "on expression" it does not work, while it work "on frame" for faders, for switches only 1 works correctly, the other one doesn't even lights up if i press that. maybe there's something else to do?
i can't make aliases cause i need to resize some of them.
i've tried using your script suggestion, "on expression" it does not work, while it work "on frame" for faders, for switches only 1 works correctly, the other one doesn't even lights up if i press that. maybe there's something else to do?
Re: linking faders/button
????
On expression x works fine here
STOP using onframe on everything lol!
On expression x works fine here
STOP using onframe on everything lol!
Re: linking faders/button
i like to burn my ipadSoftcore wrote:
STOP using onframe on everything lol!
Re: linking faders/button
ah ok i have to put the x variable to the right of the drop down menu 
Re: linking faders/button
You essentially instruct Lemur to:
"Hey man, dont ALWAYS look up the two values (on frame), just look it up when x changes" (on expression x) - that is, when the button-fader-knob is moved.
The "any" part (further on the right) adds the "when x changes in any way"....It could be that the script will only execute when x has a certain change (goes from 0 up, from any number to zero and more).
The rise from zero (up arrow) and drop to zero (down arrow) are very handy for pads and z expressions - x rise from zero is essntially "when a pad is pressed" while x drop to zero is "when a pad is released" (or with z, when a object is touched, when a object stops being touched).
"Hey man, dont ALWAYS look up the two values (on frame), just look it up when x changes" (on expression x) - that is, when the button-fader-knob is moved.
The "any" part (further on the right) adds the "when x changes in any way"....It could be that the script will only execute when x has a certain change (goes from 0 up, from any number to zero and more).
The rise from zero (up arrow) and drop to zero (down arrow) are very handy for pads and z expressions - x rise from zero is essntially "when a pad is pressed" while x drop to zero is "when a pad is released" (or with z, when a object is touched, when a object stops being touched).
Re: linking faders/button
good morning, i had some issues last night linking your relative fader, basically once linked the fader becomes a little choppy, is not smooth as before, also i had to double the multiplier on the gesture in order to have the same effect.
By the way even doubling the multiplyer the fader is not as smooth as before.
so i've found another way, that is basically the same way i used with reaktor, but doing it inside lemur has no issues.
As i don't need faders to be refreshed immediately because are on another page, and also all faders are refreshed by incoming midi, so the only case where i need to refresh is when i move the fader inside lemur, so i made a script on the gesture that cheks for movements and if it's been idle for at least 1 second it will refresh the other fader, it works very well this way and the fader is smooth, the only drawback is that i will have extra midi outputs when it refreshes but it's not a big problem, also i will have the refreshed fader locked for 0.1secs but again is not a problem cause i would need at least a second to switch page so when i will be there the fader will be refreshed and working,
posted examples:
container1: linked fader as you can see fader is choppy and the gesture movement is lowered.
container2: linked faders with fixed gesture, as you can see the fader is not as smooth as the third container
container3: fader with refresher, if it's been idle for at least 1 second it will send the value to the other fader, all works fine.
i hope i'm done with this project, just need to fill all the pages but i know all i need now to finish it, many thanks for your help it has been crucial.
sorry i had to use an "on frame" script for the time calculation
By the way even doubling the multiplyer the fader is not as smooth as before.
so i've found another way, that is basically the same way i used with reaktor, but doing it inside lemur has no issues.
As i don't need faders to be refreshed immediately because are on another page, and also all faders are refreshed by incoming midi, so the only case where i need to refresh is when i move the fader inside lemur, so i made a script on the gesture that cheks for movements and if it's been idle for at least 1 second it will refresh the other fader, it works very well this way and the fader is smooth, the only drawback is that i will have extra midi outputs when it refreshes but it's not a big problem, also i will have the refreshed fader locked for 0.1secs but again is not a problem cause i would need at least a second to switch page so when i will be there the fader will be refreshed and working,
posted examples:
container1: linked fader as you can see fader is choppy and the gesture movement is lowered.
container2: linked faders with fixed gesture, as you can see the fader is not as smooth as the third container
container3: fader with refresher, if it's been idle for at least 1 second it will send the value to the other fader, all works fine.
i hope i'm done with this project, just need to fill all the pages but i know all i need now to finish it, many thanks for your help it has been crucial.
sorry i had to use an "on frame" script for the time calculation
Re: linking faders/button
Yup, when time is involved you gotta have onframe!
sorry i had to use an "on frame" script for the time calculation