pad-switch frustration [solved]
Re: pad-switch frustration
Softcore thanks can't wait to try and implement.
-
electrofux
- Regular
- Posts: 294
- Joined: 24 Jan 2012 18:22
Re: pad-switch frustration [solved]
I was having a similar problem with Reason and Lemur. When i pressed the button in the Lemur it lit up the corresponding button in Reason and the Lemur but instantly unlit in the Lemur again. This was because the button was set up bidirectionally and at the moment i pressed it and it got lit in Reason, Reason also sent the same cc back to the Lemur so it unlit again.
What i did was making Reason receive the cc that the Lemur sends (eg cc#41) on press but send a different one (eg #cc42). On the Lemur button i set up a scrip which receives the cc and alters the attribute of the button (light, colour, outline what have you).
What i did was making Reason receive the cc that the Lemur sends (eg cc#41) on press but send a different one (eg #cc42). On the Lemur button i set up a scrip which receives the cc and alters the attribute of the button (light, colour, outline what have you).
Re: pad-switch frustration [solved]
Actually, I believe its the release of the finger off the pad that causes the pad to un-lit - as it should, because its a pad and it has to return to 0 state when released. Hence, if you press and release the pad very very fast (release before the feedback from the DAW arrives) then the feedback arrives and lights it up.
In other words, the functionality with a pad as a Mackie button is not consistent - sometimes it shows feedback sometimes it doesnt. The solution relies, as you say, on using that feedback to change ANY attribute of the pad (to be perceived as "on") besides its state - so it requiers to map a custom variable to your desired midi out, so that the feedback in return, doesnt change the object's state.
Its occasions like this that the need to be able to allow or not allow feedback back into Lemur with scripting appears. Also, as a sidenote with my experiments until finding a solution I discovered that the "feedback" is independent from the litle checkboxes in front of objects in the project panel - something that Im not sure if its made clear in the manual - I have thoroughly read it but even if its mentioned, I missed it.
In other words a "pad" mapped to a specific target and CC or Note on will receive feedback even if the checkbox of the object is unticked - the checkbox disables only the triggering, the midiout of Lemur - not the midi in.
Semantics, I know, Im just saying.
In other words, the functionality with a pad as a Mackie button is not consistent - sometimes it shows feedback sometimes it doesnt. The solution relies, as you say, on using that feedback to change ANY attribute of the pad (to be perceived as "on") besides its state - so it requiers to map a custom variable to your desired midi out, so that the feedback in return, doesnt change the object's state.
Its occasions like this that the need to be able to allow or not allow feedback back into Lemur with scripting appears. Also, as a sidenote with my experiments until finding a solution I discovered that the "feedback" is independent from the litle checkboxes in front of objects in the project panel - something that Im not sure if its made clear in the manual - I have thoroughly read it but even if its mentioned, I missed it.
In other words a "pad" mapped to a specific target and CC or Note on will receive feedback even if the checkbox of the object is unticked - the checkbox disables only the triggering, the midiout of Lemur - not the midi in.
Semantics, I know, Im just saying.
Re: pad-switch frustration [solved]
I found an easy solution for this
Custom Button
set to "switch"
scale from 127 to 126
now it works like it should both directions
tested in Ableton live mackie emulation
Custom Button
set to "switch"
scale from 127 to 126
now it works like it should both directions
tested in Ableton live mackie emulation