“Engage Preset” message type is not toggling states across banks. However, when engaging presets within the current bank (ie. preset A engaging preset B) the states are toggled.
I reverted back to v3.13.3 which is the last version I had before I skipped to .6. Engage preset works fine with .3 locally and across banks. I uploaded .4 and the problem starts with that version.
This bug was reported in January.
A Trello card has been created for this request: “Engage Preset” message type not toggling states across banks
Do you have “Remember Toggle States” turned on?
Yes. That’s one of the first settings I checked. Again, it works fine with v3.13.3.
can you upload your controller backup either here or via email ( jason@morningstarfx.com )?
Two e-mails have been sent. First one explaining the presets and the second one with the actual files.
Thanks
Jason have you been able to take a look at the presets I e-mailed last week?
If not, at the very least see if you can replicate the problem.
Thanks
Sorry for the delay! I just checked now. The presets you sent have Set Toggle Presets, but nothing is checked:
Though I did go and select the appropriate one and try again, and it looks like they can’t set themselves when triggered across banks. This works though (if I’m just needing a preset to toggle itself on command, it’s what I prefer):
Also, you can use Set Toggle in other switches, just not the one calling. I can’t currently confirm if the behavior was different in earlier firmware, but I can see what you’re talking about now.
So the good news is you’ll be able to program whatever behavior you’re looking for, with the caveat that if you’re setting multiple toggles, you’ll need a command for the receiver itself and a separate one for any others it sets. I’ll discuss the possible bug with engineering as well.
Thanks for the reply.
The unchecked boxes was purposely done. It doesn’t make sense, but oddly enough it worked correctly that way in v3.13.3. However, in the new version I did try a multitude of methods to engage across banks and could not get it to work. It seems to be a position 2 bug. But I can’t confirm.
So yes, if you can bring it to the attention of engineering and have them test it in the new version and most importantly in v3.13.3 that would be great. The “engage preset” message is the core of my workflow.
Thanks
Okay, just to make sure we’re on the same page.
Toggle Preset (pos:1) to set the switch’s own position to 2 and Toggle Preset (pos:2) to set it to position 1.The way your commands are currently programmed, using Set Toggle → Engage Toggle and Set Toggle → Disengage Toggle, currently don’t do anything because nothing is checked. If a command like that previously did something, that’s bugged logic and it was probably fixed. I’d suggest updating your commands to the correct logic if you’re using the new firmware.
Yes, that’s correct and it’s what I’ve observed myself. I’ve been using the workaround without any problems. But, something definitely changed with the set toggle message type starting in v3.13.4.
It’s not a huge problem. I could continue using the “toggle preset” message type in addition to “set toggle”. My purpose for the combination of engage preset and set toggle message types is to imitate IA linking. The “toggle groups” feature has some built-in limitations with that workflow.
Thanks for looking into it.
Is the primary limitation the number of Toggle Groups? I don’t see a functional difference otherwise (I’m just basing that observation on a skim of the RJM documentation).
In the interest of not rehashing the subject , I posted this very topic 2 years ago with an explanation here:
I won’t speak for the engineering team, but i guess the reason this hasn’t been a problem for me personally is because I’ve typically relied on a different logic for syncing.
I’m guessing you’re generally using this state-linking for engage/bypass? If so, what I’ve generally done is create a “stompbox” bank that has a “master switch” controlling the state of each device. That switch has a unique toggle group, so that if you want to a copy of a device on another bank, you just make a switch on that group to sync.
That switch is also the only place the engage/bypass CCs are fired. The logic of that switch is typically something like:
If you go there, you can physically press to toggle it back and forth, but any other switch can use an Engage Preset → Long Press to force it on and Engage Preset → Long Press Release to force it off. A complex preset, engaging and bypassing a bunch of pedals might look like:
A couple of those on the same Toggle Reset Group gives you a radio-button style selector for song parts or whatever else.
and a simple switch sync’d to one of the master switches (e.g. direct control of a drive/boost) might simply be:
My method for IA linking has never been a problem. It works flawlessly. I’m always looking for ways to streamline a workflow and if the set toggle message type had a bank parameter, the amount of messages would be trimmed down (refer to the link in my previous post). Though, I have no problem continuing with my current method.
Mostly, but certainly not entirely.
My method on my MC6 pro has 1 bank that’s programmed with everything that has remote access on my pedalboard either by MIDI or relays including my amp. That bank acts as a central bank or stompbox mode that all other banks communicate to.
I have preset X (that I don’t ever use) programmed the same across all banks with several no action “engage preset” messages that individually link to every preset in the stompbox bank. This linking sets the toggles of each preset which have no action “toggle preset” messages in each. In addition, preset X last message (32) also has a no action “engage preset” that links to the stompbox bank preset X as well. In it, I have one simple message, a “set toggle” message set to “disengage toggle” of all presets in the stompbox bank. This acts as a reset or “wiping the slate clean”. The stompbox bank does not actually execute messages out to the FX field (pedalboard). The song presets in other banks do this. The stompbox bank just displays the current state of the FX field but can also activate the presets with the switches if needed. So if I need to jump to the stompbox bank during an improvisational moment, I can quickly add a pedal (ML10X loop) to the currently active song preset (from the previous bank) and jump back. All it takes is 3 moves: jump there, select, and jump back.
When programming a preset for a song, I use “trigger messages” to trigger preset X. The idea here is to have a simple check-box system for IA style linking. All the messages in preset X are strategically numerically ordered to match the loop #s of my ML10X. Msg 1= Loop 1, Msg 2=Loop 2 etc, with additional Msg #s that are not related to the ML10x. This makes a check-box system even easier. Fundamentally, preset X serves as an intermediate preset. If additional banks other than the stompbox bank need to have states toggled to reflect the current state of the FX field (it’s rarely more than 3 banks), then these are programmed individually in the song preset as well with “engage preset” messages.
A typical song preset (or other) would look like this:
On first engage - “trigger messages” preset X msg#32 (reset/“wipe slate clean”)
Press - “trigger messages” preset X msg#1(loop 1 comp.), msg#9 (loop 9 delay), msg#10 (loop 10 reverb),
Press (3 seperate msg)- activate presets on MIDI equipped devices ML10X, delay & reverb
Press - “engage preset” for delay (in dedicated bank)
Press - “engage preset” for reverb (in dedicated bank)
On the average, each preset is less than 10 messages
All navigation (bank toggle, bank jump, toggle page, last bank etc.) and tap tempo is done by an MC4 Pro that acts as an aux switch (smart aux switch).
This is all a very efficient system that allows a planned workflow and most importantly, plenty of flexibility for improvisation with a minimal amount of moves. But like I said earlier, always looking for new ways to streamline.