As I have changed one of my keyboards, I now require a workaround that will allow me to drop midi events filtered by midi channel based on the status of a specific CC on a specific channel.
I was hoping I could do it globally using a script.
To be as brief as possible I want to have a script read the value of a CC and based on the channel of the CC I want it to filter (mute) or unfilter (unmute) the midi events on that channel.
Any suggestions? and no I am not going to redo all my rackspaces and start using variations. It doesnt match y workflow.
Yeah I think it might be the end result. Im going to experiment first with constraners and widgets linked to the CC and if that doesn’t work I’ll have to try to learn GP4 scripting.
Why did changing a keyboard require such a workaround? And rather than describing a workaround, can you tell us what exactly you are tryig to accomplish? In other words, what is the actual problem you are needing to solve?
I change sounds using midi channels. I had a kb that let me change zones by pressing buttons. I dont have that now, so i need to simulate the same thing using assigned CCs
I had a JV-80. It allowed me to quickly press buttons to turn on and off parts. Each “part” was assigned to a midi channel. I was able to quickly switch between sounds by simply turning on and off whatever “part” I wanted…by pressing the “PART SWITCH”(es)… Now this week the JV-80, which is over 30 years old, decided to partially die, which resulted in me having to quickly buy another controller. This new controller does not have zone buttons even though it has 4 zones internally, it is not an easy task to turn the zones on and off. Stupid design but oh well.
So I now have implemented 4 widgets and assigned them to 4 midi constrainers and linked the widgets with the block all traffic… and I’ve assigned these buttons to 4 buttons on the new controller. It works but the only problem now is that It doesnt work backwards so that if i change the widgets manually, they dont reflect on the controller… but it will have to do unless there are better options.
The manual I found for the Oxygen Pro 61 doesn’t seem to say a whole lot about it. It makes reference to using the Mackie MCU/HUI protocol, but also a section on configuring it to work with your DAW.
In the Mackie protocol the buttons send note on/note off when pressed and released. It’s up to the DAW to tell it when to light and un-light each button. In that Mackie protocol not all buttons are able to be lit. Some devices that adhere to the Mackie protocol adhere to that, some don’t.
Let’s say one of your pads is sending Note On 54 when pressed. Sending the same Note On message back will generally light the button. To unlight the button you’d send a Note Off 54 (or Note On 54 with a zero velocity as the original Mackie units expected).
I’ve also seen devices like that where you can set them NOT to operate in Mackie mode. One such item that I had refused to light the buttons unless you were in Mackie mode. I have another that’s always in Mackie mode, but you can configure buttons to send messages outside the Mackie protocol. If set that way, those buttons refuse to light.
