I’m starting to use electra with a Daw (Logic Pro) in place of an Xtouch controller which uses Mackie Protocol to control functionality within logic
For some types of functionality Mackie Protocol will use a single CC. It then uses a value of 1 to increment and a value of 65 to decrement
So for example the jog wheel on the Xtouch (and most Mackie compatible controllers) will use CC 60 on channel 1. When you rotate it clockwise it sends out a value of 1 which moves the playhead forward. When you rotate it anti clockwise it sends out a value of 65 which moves the playhead backwards
It would be useful to be able mimic this on the electra
Just posting random things I’m finding on Mackie Protocol. Please don’t take this as me hassling you with a list of development demands. It’s just me documenting stuff as I find it
Mackie Protocol (MP) uses note on/off messages to toggle various parameters on/off. I’ve noticed a difference between electra and MP. Both Electra and MP send note ons with a velocity of 127. When sending Note Off messages MP sends them with a velocity of zero whilst MP sends them with 127. I haven’t yet worked out is this is significant or not
For on off buttons under Mackie Protocol the message that the button sends is decoupled from the lighting state of the button. Whether a button is lit or not is controlled by the feedback sent to the Mackie controller.
So when a button is pressed to turn something on it sends a note on message with a velocity of 127 then a note off message with a velocity of zero. A note on message with a velocity of 127 is then sent back to the device to turn on the appropriate light.
When the button is pressed to turn the parameter off a note on message with a velocity of 127 is sent followed by a note off message with a velocity of zero. A note off message with a velocity of zero is sent to the Mackie device to turn the light off. Regardless of whether turning on or off the message that is sent from the mackie controller is the same
In terms of button presses the button on the Mackie controller is acting the same as a momentary note pad on electra.
There are a few differences though which upset the functionality and get the electra out of sync.
When I setup a pad as a momentary button it doesn’t stay lit. Electra sends out the note on message, it receives back a note on message, it then sends out a note off message and because it does that it turns off the lit status of the pad. Functionality in the daw is turned on or off as expected but the lighting status of the pad doesn’t accurately represent this.
If I setup a pad as a toggle. Then it sends out the note on message to turn on and stays lit. However when you untoggle it – it sends out a note off message. Mackie Protocol ignores this as it is waiting for another note on message to toggle the status. The electra pad is now dimmed but the functionality in the daw is still turned on. If I press the pad again it turns off the functionality in the daw but the pad is now lit. So after the initial press it will always take two presses to toggle the functionality on or off
Regardless of whether a toggle or momentary pad is used the message sent by electra is driven by the lit status of the pad. If the pad is not lit it will send a note ON, if the pad is lit it will send a note off. So if I’m using a momentary pad and turn the functionality on in the daw (using a mouse) then the pad on electra will get the feedback and light up as expected. But if I press the lit pad on the electra to turn off the functionality it sends out the wrong message
both of these points, are actually a flip side of the same coin
basically they are used when the ‘controllers’ logic is implement on the compuer (or some other device which retains state,but I’ll use the term computer , just for brevity)
the first, sending 1, 64 to increment/decrement, is so called relative midi cc , there are a couple of forms of these. often the midi controller uses endless encoders.
the ‘issue’ for electa one, is that you cannot really show a ‘value’ since you dont know what the value the computer has for this control. (*)
the second, disconnecting UI state from the button.
again, this is the same really… its saying that the computer will hold the state and inform the controller to just ‘reflect’ this state.
the good news for electra one… I think the new Lua stuff would be perfect to resolve this.
as we could
a) detach a controls state/value from a midi message, and let incoming midi messages change the state of a particular control.
b) reinterpret an encoders value change to generate a particular midi message.
so I think it would be cool to consider this as a use-case for the lua extension.
(I think this could be done with current beta?)
(*) on some devices this value might be sent as a separate CC/sysex, but not always, rather depends on the device.
Whilst I can see how in the current beta you can control a controls appearance based on value I couldn’t see a method of working out what was the source of the value change (incoming midi or interaction with electra). I maybe missing something though (probably am). I guess you could work around it using hidden controls but that would quickly become a pain as you added more
yeah, I suspect your right - that you’d need to use hidden controls.
I was partly thinking about the midi handling in the standalone lua version , where you just get to hook into the inbound CC (etc)
I wonder if this would be an area where the preset lua extension could be enhanced?
to facilitate this disconnect between UI value and inbound/outbound midi value.
this ‘hardcoded’ link between control <-> midi seems to be the crux of the ‘problem’ here…
