Is there a way to not reset all the values on page change? I am using two pages for my application, and am setting some buttons’ and their LEDs’ values with press/longpress scripts. I’d like the values to stay whenever I change pages. Is there a way to accomplish that?
Pages are like completely separate collections of buttons, like a while another BU16 in this case.
Changing the page changes the LEDs, because the underlying button’s state on the other page if off!
And there is no way to get around this? That effectively makes pages useless for me when performing.
Why would you change Pages in this case? I’m kind of confused.
Users usually switch pages because each CC/note on the first page is bound to specific parameters and the second page is bound the same way to different parameters.
So for example if I change a parameter to value 45 on my first page, but on the second page it would control a different parameter I would not want it to be on value 45.
Hope my example explains why it works like it does.
I see the confusion, let me try to rephrase what I want to achieve:
When I hit my button on page one, it will go from value 0 to value 127. When I go to page 2 and then go back to page 1, the same button will be reset to value 0 again, with the LED value also back at 0. But I want the page to remember what its buttons’ values where, even after changing to another page and coming back.
Essentially, I want pages to remember their respective state across page changes, but of course not have the same value across all pages, as you pointed out.
Does that make sense?
1 Like
It makes sense, but you assume a lot of things in your statements.
With some other controllers bi-directional communication is a given, and it’s usually well integrated into the DAW itself. DAWs will recognize your controller and will instantly work with them and follow along.
Grid is not like that. For everything you want it to do, you will have to set it up to do it.
Now about buttons. Based on your description I imagine you used that button to toggle a Mute on an audio track for example. In this case you send out a MIDI message to the DAW and the DAW recognizes it as a MIDI message used for Mute on that track. It Mutes the track.
Now in the above example Grid knows literally nothing about what happened. It doesn’t know about the DAW side recognition nor about the Mute state toggling in the software. Because of this, it has no way of setting the LED brightness accordingly.
This is a problem we’re trying to fix in your case, Pages are only a byproduct.
There is an easy version and a hard version of implementing what you’re trying to achieve.
- The easy version will simply use toggles to make every odd numbered press an ON message and every even numbered press an OFF message. The LED will follow in kind.
- The hard version is to implement Grid-to-DAW-and-back communication on the module and tell it what to expect and how to react to it. Describing this process would be too long for this short example.
The above idea has two answers to the question of “Which device remembers states?” and the answer will differ from user to user.
If my above example is correct and you’re a DAW user/producer/composer, then DAW users usually let the DAW remember states and let it communicate its state to the controller.
This would mean you need the harder to implement version.
I am using the Grid controller to control a Processing application that I am writing.
I could send updates about the corresponding button states from my application to the Grid controller occasionally, but since it is very resource intensive already, I would prefer to handle this with the Grid controller itself.
Therefore, I think it would be much easier if it could remember a button’s value even after having been on a different page.
My guess is that the initialisation that happens after a page change sets all the values back to 0. Unfortunately, in the Grid editor, that initialisation step is not editable, right?
Maybe I just do not understand how pages work, but is there really no way to save a value and then re-apply it on initialisation?
Thanks for trying to help!
Hi!
That’s the easier way then! Please just follow the link above about setting a button to a toggled behavior. This way it will remember states between Page changes.
1 Like
I see, thank you. It seems to be working, but only for the short press. I thought maybe adding a Button Mode Action Block to the timer section where a long press is handled and set it to 1 as well, but it won’t remember the value across page changes.
Is there a way to combine these behaviors? Having a short press / long press AND remembering values across page change for BOTH short press and long press?
I didn’t mean the shortpress/longpress profile, but only the simple toggle setting in the Button Mode. The shortpress is a different thing entirely (and is currently bugged in Editor sadly).
I know you didn’t mean the shortpress/longpress profile, but that is what I (need to) use.
I can switch the short press button mode to toggle and it will work for that, but it will not make the long press remember its value across page changes. That is the behaviour I need.
Is there a way to combine the shortpress/longpress functionality WITH remembering values across page changes?
No way to combine the two across pages as pages only retain button value information between pages and the longpress information is not retained on a change like this.
1 Like
Hello!
Well, I seem to be in the same place as the OP. But I’m on a EN16. Honestly, and not to insult anyone, but this design decision is a bit short sighted. I would be so simple to just implement a save mechanic for simple button states and encoder positions on each page (no need to remember fancy longpress or multi-values on buttons). Especially on the EN16 since there’s no absolute positionning like faders and pots. If people know about this, it could dissuade them from buying. I used to be a programmer and the programming API is clunky to say the least.
I managed to do almost everyhting I wanted to do on the EN16 although I had to bring my expectations back a bit. I’m trying to control my Bluebox and since there’s mutes, solo, rec arming on the buttons and volume, gain, pan and FX1/FX2 sends, it’s a bit hard to fit all on one page! I managed two. The mostly used params are on page one with only FX sends and gain on the second one which are less used.
So, really unfortunate for the lack of page memory… Yep, that would be a big feature request…
1 Like
Oh, also, another feature request that would help a LOT would be to be able to have two values when using rotate vs push and rotate. It’s useless if I use rotate to control volume and then push+rotate for pan, only to have a completely different value when going back to rotate only (volume).
Ok, been quickly reading for my last comment about two values on one encoder. I’ll look into self variables to juggle between each event (rotate vs push/rotate) to swap in and out values for each state. Will let you know…
Everything is doable in Editor that you described above, except for saving variables between Pages.
That’s just not something that’s possible right now considering how Grid handles memory.
My advice is, that if you’re looking for a compact solution (more than 16+16 events/messages on one module) you develop your configuration with ‘pseudo Pages’ like on the profile 64CTRL. I also know that this is a big ask, but it’s also an advanced user request. Currently we provide the tools and guidance for these requests, but we only make the configs that are good stepping stones for others looking to create their own.
If you can tell me what exactly you’re looking for, I can help you create your own.
And for the record @katze203 above wanted to know if the longpress from a specific config is retained between Pages or not. To that the answer is no. But it would be possible to make a config that has multiple ‘pseudo Pages’ that are able to remember the state of longpress/shortpress per Page as well. But that’s a whole another story as it requires building a new config from the ground up.
Blockquote
That’s just not something that’s possible right now considering how Grid handles memory.
Is that constraint a hardware thing or a software thing?
I think for me it will be easier, like we’ve already touched on, to just have my program occasionally send the values to the GRID so that it can retain even the long press values across page changes.
I would however still be interested in this config with multiple ‘pseude pages’. Is there documentation for that?
Thanks in advance!
For pseudo pages, the technology itself is very simple. Grid stores encoder states when switching between these fake pages in global LUA variables.
You can check how it works if you have access to an EN16 or TEK2 with the 64CTRL or the 16CTRL profiles.
So this will not work for the PBF4?
Sadly I only made configs for the modules will fully digital elements like endless and encoder elements. Potentiometers would require pickup algos after bank changes to prevent parameter jumps.