The 2 screenshots above show how I have tried to configure buttons 9-12 (the 4 small buttons below the LCD screen). The 1st shows how button 11 for page 4 is set-up (with the same setting on button 11 for page 1-4. The 2nd shows how button 9 for page 1 is set-up… again the same setup for button 9 for all 4 pages.
The aim is to emulate the pressing of the little utility button on the bottom edge of the controller - ie press button 9, changes to page 1 (from any other page), through to pressing button 12 changes to page 4 (from any other page).
That is not what happens…some examples:
from page 1 I press button 10 (expectation is change to page 2): Nothing happens
from page 4 I press button 9 (expectation is change to page 1): nothing happens first press, but 2nd press it changes to page 2!!
from page 2 I press button 12 (expectation is change to page 4): Stays on page 2 and loses device connection ( “No device” in info panel). Grid editor needs to be restarted as well as the controller power cycled. (I reported this final issue in my previous post (Java Error when launching Grid Editor (also previous hanging DAW)
This is not making any sense. Am I doing something wrong or is there a serious problem with my set-up???
Try moving all the Page Change code to the Release section.
I think what’s happening is that when you Press the button and change to a page the button gets stuck in its Pressed state. This is Why it requires two presses to switch again when you return to the same Page.
Ok - I have done that and it seems to work, but is not great. Having to put page_load() on the Release is not the behaviour I want. I was actually looking into an approach where I have a different page load on Press , and another on Release (to return to the previous page…thereby enabling me to jump between encoder and button set-ups quickly on the fly:
Control the mapped parameters on page 1…Press and hold page_load() to change page…then tweaking the mapper parameters on page 2…Release to go back playing with Page 1.
So it would be could if this could be looked at - it strikes me that maybe the page_load() code needs some tweaking to accomodate this timing issue.
In addition I am still getting this weirdness:
Pressing (and releasing) button 9 or 10 (to select Pg1 and 2 respectively, has quite variable timing to take effect, usually fastish, but can occasionally be slower for some reason.
Pressing and releasing button 11, is ALWAYS slower than button 9 or 10
Pressing button 12 ALWAYS caused the grid editor to lose connection with the controller (No Device displayed in top right), and all page_load buttons stop working. I have to disconnect controller and restart editor.
Something is still not 1005 right here. Please help.
So states as you want will not transfer between Pages. That’s just a fact of how the Page system works. Each Page essentially is its own LUA environment and when you switch to a different environment, information from the previous one becomes inaccessible.
How to get around that? Don’t switch Pages.
If you need a lot of functionality in a single controller, you can create a configuration that changes its variables within a single Page in such a way to accommodate a faux-Page change as you need it, without switching to a different LUA environment.
For a quick example take a look at the 64CTRL or 256CTRL profiles which offer 4 and 16 banks of 16 (so 64 and 256) fully customizable control messages for the EN16.
Also - one more question on pages…How did you envisage those would be used? Different use cases and switched as you use different apps? Not really expected to be switched in mid live stream?
I looked at them as different banks which are designed to be rapidly switched on the fly, which is probably not their ideal use , I guess?
Regarding the module not communicating to Editor after switching to page_load(4) with the press of button 12: the code means you’re switching to Page 5 actually, because Pages are numbered from 0 and Grid lets you do this, but Editor does not support it.
Because of this, Grid will work properly even on Page 5, but you can’t configure it.
Originally the idea was that you would switch Pages during a performance to access more controls or a different set of controls for a different part of the performance.
This idea is no longer well supported because Grid far outgrew its original potential regarding customizability.
Now, we mostly view it as a relic of this idea and are planning on sunsetting it when we’ll have a good alternative.
Currently the best way to utilize Pages is when you have completely different configurations for different software/use cases and you would like to have controls for all of them in one place.
