I have four EN16 modules and they are amazing to control VCV Rack patches and complex VSTs.
But now i’m searching a way to bypass the 4 pages limitation and be able to control more than 4 instruments (Rack patches, VSTs…).
I had the idea to dynamically change the midi channel number of all elements with one encoder (to control 16 instruments (Rack patches, VSTs…)).
And it works! But only for one module because I can’t find a way to declare a global variable at the page level, only at the module level.
Is that possible ?
The documentation page on global variables isn’t very clear : “Variables created on one module, are not accessible from other modules.” and “Variable created on a Grid module Page is accessible by any function anywhere on that Page all the time.”
This means that you cannot pass any data of any type between modules. So there’s no way to set a Grid multi-module visible variable or data structure.
Global variables are visible to any element at any time on any single page. You can’t pass data between pages.
All that being said, are you wanting to change the MIDI channel mapping on one EN16 then have that mirrored across all of your EN16s? This would not be possible.
Thinking of just one EN16, how many different sets of mappings are you looking to flip between? If you wanted, say, 4 mappings of channels/CC on a single page, accessible from one encoder, could you limit your self to just one page on a module?
I understand what you’re trying to achieve but I’m thinking of a way that gives maximum flexibility with minimal headaches.
The way that I would approach this problem, if I’m indeed understanding what you’re hoping to achieve, would be:
Only use 1 page on the EN16s. We’ll say page 1. The reason being is that, when you change pages on one device, all connected devices change their pages to the same one. I would not want this behavior.
On page 1, I would setup one array to store channel mappings, one array to store CC mappings, one array to store/recall the current values of each encoder so we can avoid parameters jumps when paginating, and likely one array to store LED colors in so I have a visual indicator of what set of mappings I’m on. Just thinking that you would also need an array to store the current ‘page’ to. This would be need for the encoder button presses to keep track of which ‘page’ you’re on. Without tracking this, you would have no way to store/recall specific mappings.
If the above indeed works, then I would mirror that code across the remaining EN16s. With 4 sets of mappings per EN16, that would cover a lot of 16 parameters across 16 instruments. You could independently control each EN16 with an encoder twist.
I personally would use the bottom 4 encoder buttons to swap between the 4 mappings. This way I could directly select a mapping rather then using an encoder twist to paginate. If you use an encoder twist to select pages then you would be sacrificing an encoder just to paginate.
That’s my ‘quick and dirty’ thoughts on how I would set this all up.
You understood what I want.
And I understand it isn’t possible.
The solution to have one encoder (or different buttons) to dynamically assign midi channel to all others elements of a module works. But only on a per module basis (global variables not very global).
Let’s say I have a track 1 with 64 encoders mapped (4 modules x 16 encoders) to different devices (midi effects, instrument, audio effects) on midi channel 1.
To control another track 2 with a different set of devices, I would like to twist an encoder (or push a button) and assign all other elements to midi channel 2. And so on for 16 tracks.
Doing that 4 times (1 encoder x 4 modules) isn’t a solution for my use case.
Any hope to have a global variable available to all modules connected together ?
Any hope to have more than 4 pages, 16 pages corresponding to the 16 midi channels ?
For now I made a controller script for Bitwig and I use the performance pages concept to automap encoders to parameters. And it’s what I want.
But I wanted to use Ableton too, and simply use the default mapping feature without having to create a script and Max for Live devices to automap 64 parameters per track.
On a single module? Or 4 pages x 4 modules for a total of 16?
I’m thinking/typing out loud here because I just woke up.
I am wondering if, to overcome having 4 pages x 4 modules for 4 sets of 64 CCs/Notes (Let’s say MIDI channels 1 - 4), we could use a scenario like what I proposed for being able to have 4 ‘sets’ per page of a module for a total of 16 (and 16 MIDI channels) per module. We’d need to think about keeping the ‘per page’ set swaps in sync.
It’s easy to do 4 pages of unique channels on each module. The Utility button keeps all modules in sync. Getting MIDI channels 1 - 4 and keeping them in sync is easy. But, I’m wondering if we figured out the code for what I proposed and looked to see if we could use MIDI and the ‘midi_rx’ to trigger a ‘set change’ function on each device.
So, on the primary module, the bottom 4 encoders manage the ‘set’ change per page. Could we code it so that, when you change a set on the primary module, it’s sending out a MIDI message that is listened for on the other 3 modules and makes them do the same set change? If this could be done then, I wonder if that helps us break the limitations here? If we can’t pass LUA variables between modules, could we use MIDI to achieve the same?
If MIDI and ‘midi_rx’ could be used to trigger a function on another device then, I think it would be possible. I just don’t know if we’d run into issues with character limitations. There would be a fair bit of data structures required to store values for recall on page changes.
For the above to work, I suspect a MIDI router would also be needed for the ‘loopback’ behavior.
The midi rx solution is awesome.
Thanks for the idea!
I am now able to send information to Ableton which returns midi rx messages to the EN16s.
With these midi rx messages I can update all elements on all modules.
But… the midi rx system is not stable yet.
I remember trying to use it one year ago and now it’s the same problem.
It works for a short period of time and suddenly it stops working (too many messages or I don’t know).
I’ve not yet leveraged ‘midi_rx’ but I’ve been reading about the stability issues. It’s definitely on their radar and sounds like it’s being looked at. You can track the progress here:
It might be helpful to post in that thread with a brief summary of what you’re sending and what the adverse behavior is. Could be helpful to the devs for chasing out the issues.
Happy ‘midi_rx’ is the solution. Saddened that it’s still unreliable. Still, there’s hope for the future
Are you sending the full re-maps down the pipe? I wonder if that’s the source of overload?
It would be complex but doing the store/recall of values on-device, triggered by a ‘midi_rx’ event (if possible), would alleviate piles of data being pushed down (‘piles’ being relative to the ease at which ‘midi_rx’ seems to get overloaded). You would really only need to send possibly 1 CC with 4 separate values in order to swap sets. The only thing I haven’t looked into is if you can trigger/call functions on ‘midi_rx’ event receive. Just some thoughts.
