General
pad-switch frustration [solved]
Started by Softcore on .
Sign in or create an account to join the conversation.
Ok I am working on a nice Mackie emulation for a DAW which hasnt yet appeared in the user library (wink) and after days of work to make the LED meters work (oh yes they do finally) and just when I was thinking this will be the best template I 've made...I 've hit a brickwall.
The case: in Mackie, many buttons send note-ons to control "switches" in the software although they behave as pads - for example a mute button mutes and unmutes in the software by consecutive 127 values of a given pitch (note on velocity) and the 0 velocities are ignored. What this means is that in Lemur a pad works perfectly for this purpose BUT unfortunately, being a pad it doesnt stay lit when you press it - although the corresponding controlled parameter, in our example the "mute" is a "on-off" parameter (its really a switch not a pad).
So it comes down to this: if you use a pad in Lemur you have correct control but poor feedback - its only accurate when you press the buttons IN the software with your mouse - if you press the Lemur buttons, the release of your finger causes the pad to unlit regardless of what the actual value of the software is.
If you use a switch, then you have perfect "feedback" but you need to press the button twice to control the parameter in th software.
Ideally, I would need a button that
1.sends 127 when pressed -0 when released, 127 when pressed again and so on
2.On each consecutive push, it toggles between on and off visually (either different color or light would do)
3.It correctly identifies incoming 127 and 0 values as ons and offs
I thought about playing a bit with script and "light" to create a pseudo-on appearance by changing the light but still cant make it work!
Any ideas?
The case: in Mackie, many buttons send note-ons to control "switches" in the software although they behave as pads - for example a mute button mutes and unmutes in the software by consecutive 127 values of a given pitch (note on velocity) and the 0 velocities are ignored. What this means is that in Lemur a pad works perfectly for this purpose BUT unfortunately, being a pad it doesnt stay lit when you press it - although the corresponding controlled parameter, in our example the "mute" is a "on-off" parameter (its really a switch not a pad).
So it comes down to this: if you use a pad in Lemur you have correct control but poor feedback - its only accurate when you press the buttons IN the software with your mouse - if you press the Lemur buttons, the release of your finger causes the pad to unlit regardless of what the actual value of the software is.
If you use a switch, then you have perfect "feedback" but you need to press the button twice to control the parameter in th software.
Ideally, I would need a button that
1.sends 127 when pressed -0 when released, 127 when pressed again and so on
2.On each consecutive push, it toggles between on and off visually (either different color or light would do)
3.It correctly identifies incoming 127 and 0 values as ons and offs
I thought about playing a bit with script and "light" to create a pseudo-on appearance by changing the light but still cant make it work!
Any ideas?
Subject: Re: pad-switch frustration
There are instances that require scripting to sync buttons, but I'm not sure what you are talking about regarding mute.Just use a switch object, it syncs perfectly with the DAW using the Mackie protocol or a generic remote regardless of if it's activated in Lemur or the sequencer. (make sure your Daw is transmuting)
I am close to releasing a Mackie Cubase template that uses both generic remote + mackie selected ch and mixer, and i have no issues with feedback
You can actually keep pads lit using scripted light settings. Have a look at the settings section of my XYPad template in the library or any of AB's stuff, he uses loads of awesome tricks
Subject: Re: pad-switch frustration
Using a "switch" for a Mackie button (mute buttons, solo buttons etc) is not a good solution because you have to press the "switch" twice! Here's another post with exactly the same problem:
http://liine.net/forum/viewtopic.php?f=26&t=2334#p8846
I'll have a look at the stuff you said though! The only other solution I could think of was to have visually hidden pads (no light at all) and indicate the state of the buttons via "led" objects - it works fine, but its just visually not that pleasing and clear to the eye as a lit pad-switch would be!
Subject: Re: pad-switch frustration
Softcore im trying to solve same problem look at the tread i just started. I posted my almost finished mackie control that also has pads instead of switches. We need lemur to recieve midi from live to light pads i believe that way it show excatly what live seesSubject: Re: pad-switch frustration
Softcore thanks for led ideas that might be what i was missing in my template we still need a way for buttons to light up. Mazia how can we have buttons. light up by recieveing midi from live.Subject: Re: pad-switch frustration
I just had an idea but I dont have the DAW and iPad with me to check it! It incorporates "custom button" objects which are scripted to change behavior (switch - pad) to accomplish what we want. If it passes the testing tonight I'll post my idea here so you can use it! In the meantime, the closest I could come up with was black off black on, no lights pads array overlayed by text and a 2x3 small LED array. Im mapping the LED array to each note on so for example the first led array is mapped to note on - pitch 8, channel 1 (the first Solo button). When you press solo they light up to indicate that the channel is pressed - whether from the software or from Lemur itself.
Again, the problem is that the feedback TO the pad comes, usually, before you release the pad - so the finger's release turns it off - If you use the software's buttons, the pads light up correctly. This why it works with LEDs they do not interact with your finger. My custom button workaround however turns it into a "switch" when that happens - I'll test and post back.
Subject: Re: pad-switch frustration
What Daw are you using?Have you looked at the bunch of Mackie templates in the user library?
Subject: Re: pad-switch frustration
Cakewalk's Sonar. But I really doubt this is relivant. Every Mackie template I downloaded for Live has pads, not switches. Perhaps however, Cubase treats the switches diffrently than the rest of DAWs - cant tell because I dont have it to test!Subject: Re: pad-switch frustration
Like i said i use switches for 2 state functions such as mute amd solo, not pads.Look at these templates, they uses custom buttons / switches for mute / solo, and feedback works correctly.
MACKIE FOR CUBASE (IPAD) V1
http://liine.net/en/community/user-library/view/151/
CUBASE ARRANGEMENT TEMPLATE
http://liine.net/en/community/user-library/view/309/
This template uses pads, and Feedback does not work correctly
CMTEC STUDIOONE V1.1
http://liine.net/en/community/user-library/view/204/
Subject: Re: pad-switch frustration
Great, thanks but like I said perhaps ALL OTHER DAWs besides CUBASE require pads to work without double pressing - hence why the Studio One template you found and the ones for Ableton Live I find are all with pads. Furthermore, I have tried 4 times to use a "switch" and the result is ALWAYS the same - the feedback is correct but the parameter changes every SECOND press of the switch! In other words, the software mutes-unmutes or solos-unsolos for every "Note on velocity 127" it receives - the switch sends a "on" message (Note on 127 velocity) but then, when you switch it off, it sends "Note on 0 velocity" so each second press is ignored.Thanks again!
Subject: Re: pad-switch frustration
Seems odd since Mackie is a universal control structure. If you look at the mackie implementation chart you can see that
Note on 127 = Mute on
Note off 0 = Mute off
http://home.comcast.net/~robbowers11/MCMap.htm
Perhaps you could dump mackie for certain functions and create a custom map?
Subject: Re: pad-switch frustration
Hear ya but its not the first time the mackie Protocol is interpreted differently by different manufacturers. I imagine noone ever had to decrypt a secret handshake with mackie emulations and Live or Cubase, correct? (like Novation's Launchpad with Ableton Live)Guess what happens in Sonar!
By the way, the document is correct in the sense that Sonar sends the correct on-off values back to Lemur as feedback - it just doesnt "hear" the correct messages.The same happens in Ableton Live - I just checked. It also "listens" only note ons and requires pads to work correctly (but of course, feedback is problematic).
Anyways, I ve decrypted the damn handshake, I ve managed to make level meters work in Lemur, this aint gonna stop me!
Subject: Re: pad-switch frustration
Have you tried playing with the light property of the pad?So PadName.light = x
I've found that setting the light value to 0.325 will emulate the the look of the pad when its x value is 1.
This should be simple enough for you since you're only doing on/off (I had to do some interpolation as I was mimicking the value of the fader with the pads light value)... It would be nicer if the number was a bit more round (1 or even .5) but not the end of the world.
The only downside is you need to see the pad's on and off colors to the same value for it to appear seamless...
Subject: Re: pad-switch frustration
that's actually possible. See this post:Traxus wrote:The only downside is you need to see the pad's on and off colors to the same value for it to appear seamless...
http://liine.net/forum/viewtopic.php?f=28&t=2310&p=8868#p8868
Subject: Re: pad-switch frustration
traxus could you right the script out a little bit easier i So PadName.light = x is this a script and if so you you write out what our things are need to complete. Im learning lemur buit don't make everything out learning to code.
Subject: Re: pad-switch frustration
Basically, when you want the pad to be displayed fully litwrite (replace PadName with the actual name of your pad object)
PadName.light = 0.325;
when you want to turn the light in the pad off:PadName.light = 0;
This is ugly but should work, try adding a script to the Pad, set the execution to x and paste in:if (PadName.light == 0) {
PadName.light = 0.325
} else if (PadName.light == 0.325) {
PadName.light = 0;
}Subject: Re: pad-switch frustration
Sorry, I don't see how that applies?Phil999 wrote:that's actually possible. See this post:Traxus wrote:The only downside is you need to see the pad's on and off colors to the same value for it to appear seamless...
http://liine.net/forum/viewtopic.php?f=28&t=2310&p=8868#p8868
With my example, setting the light to .325 mimics the brightness of the pad when x = 1... even when x = 0. If the off state were a different color, the pad would still be brighter but the color would be different and the effect would not appear seamless...
Subject: Re: pad-switch frustration
I'm also a bit confused. When I have the same colour for off and on, and set the light to 0.325, the pad gets slightly brighter when I touch it. Can you post an example? I'm sure I misunderstood something.Traxus wrote:Sorry, I don't see how that applies?
With my example, setting the light to .325 mimics the brightness of the pad when x = 1... even when x = 0. If the off state were a different color, the pad would still be brighter but the color would be different and the effect would not appear seamless...
In my example I leave the light at 0, and only change saturation and value, to compensate the 'on' state which changes saturation and value.
Edit: ah, now I think I understand. I am trying to leave the pad untouched so to speak ("The only downside is you need to see the pad's on and off colors to the same value for it to appear seamless..."), and you want the exact opposite. Sorry, my fault, I misinterpreted the topic entirely. My bad English. Sorry for the confusion.
Subject: Re: pad-switch frustration
Thanks for all the suggestions guys! Got plenty of stuff to test after reading the posts! Will be back soon!Subject: Re: pad-switch frustration
Thanks for the help everyone...the solution was finally based on the light toggling script by Traxus plus a few minor aditions to further make it seemless when it receives feedback from the DAW for anyone interested link with exampl in the following post
http://liine.net/forum/viewtopic.php?f=26&t=2334&p=8892#p8892