HX Stomp: Can't change Preset AND Snapshot via MIDI

[boseki]

Hey there, HX Stomp newbie here.

 

I recently bought a HX stomp and a Boss ES-5 effects switcher to upgrade my pedalboard.

So far everything works pretty good, but i have one problem i can't solve.

 

I use the ES-5 to send MIDI commands to the HX stomp. Every time i press a switch on the ES-5 it sends a program change (PC) to select a preset on the Stomp and also a Midi CC #69 (values 0-2) to select a snapshot of that preset. However, i only get to the wanted snapshot if the Stomp preset is already active. But if the stomp does indeed need to change the preset it seems to ignore the CC #69 and will always start with the snapshot that was last edited in HX edit or on the stomp itself.

 

Does anyone know a solution for this? Could it be a bug? My firmware is at V 3.01.0.

 

Thanks in advance.

[phil_m]

It probably has to do with the timing of the two commands. I'm not sure what the gap needs to be, but I believe there needs to be one, otherwise, I'm not sure the CC69 command will get though. As far as the snapshot that's active when you load the preset, it's always going to be whatever snapshot was active when the preset was last saved.

[rd2rk]

I've tested this using Helix to Stomp, FCB1010 to Helix and/or to Stomp, and recorded MIDI from a DAW to both Helix and/or Stomp.

Works correctly every time. Probably timing as phil_m said.

[boseki]

In my case there is no gap (i think...), since PC and CC69 are part of the same MIDI message.

 

However, it is possible to turn individual blocks on and off (by assigning a free CC#) with the same MIDI message which does the preset change.

That's why i was confused that it does not work with snapshots.

 

Considering that there are only 3 snapshots in the Stomp (which forces me to use additional CCs in let's say 90% of all cases),

i think i wont be using the snapshot functionality at all, but i will exclusively use individual CCs for each block.

 

Since the Boss ES-5 can send up to 16 CCs on preset change, i think i will be safe.

Slightly less convenient but more robust... :-/

 

 

[rd2rk]

3 minutes ago, boseki said:

In my case there is no gap (i think...), since PC and CC69 are part of the same MIDI message.

 

 

PC and CC are separate messages. If the CC arrives before the preset change completes, it has no effect. There NEEDS to be a small gap to allow the change to take place.

[rd2rk]

I'm having second thoughts about this. I was sure that I had it working at one time, and had tested it as mentioned above.

Now I can't seem to make it work with ANY hardware!

I've opened a support ticket. Will report back!

[poboyer]

Exactly same problem with snapshots with a FCB1010 and an hx effects.

[rd2rk]

Support got back to me on this. As phil_m suspected, timing. The Instant Commands are sent simutaneously (vs consecutively), and the preset isn't yet loaded when the CC is received.

The workaround is to save the preset multiple times with different snapshots as defaults. Not a great fix if you're short on preset slots on a HXS, but it is what it is.

 

https://line6.ideascale.com/a/dtd/Loading-a-preset-and-a-snapshot-via-midi/1007491-23508?submitted=1

 

I put it up on Ideascale if you want to vote on it. I give it Lottery odds, but you never know. Could be as easy as adding a checkbox to Command Center and code like:

 

If Checkbox W=1 Then

Send IC1

Wait 10

Send IC2

etc

 

Or not......

[poboyer]

T_T

[rd2rk]

1 hour ago, poboyer said:

T_T

 

?

[poboyer]

I think it’s sad. The instants commands should be sent consecutively.

[abw1989]

I've got the same issue, I did a search but didn't find this thread. 

 

If you view the midi trace you can see that when the PC sent isn't the same as the PC the Stomp last received, it double reads it. I've done some. I've done some more traces and the CC command appears in the middle of the duplicated PC, so the Stomp swaps to the default snapshot when the second PC arrives. 

 

Here's my thread explaining more:

 

 

[rogerio_sugui]

Hi all,

 

I’ve just got an external midi controller. Funny thing is that in the very first test I did, I faced this issue. Tried to send a PC and CC69 messages to load a preset in a specific snapshop, and it doesn’t work: it just loads the preset (according to the PC message), but CC message has no effect.

 

Another strange behaviour is that, if I press the midi controller switch a second time, then the CC message is processed and the according snapshot is loaded.

 

As someone said, on the other hand, when I send PC plus any other CC message (to activate a block, for example), it works correctly.

 

Considering this, it doesn't make sense the feedback that @rd2rk  received (saying that "the Instant Commands are sent simutaneously (vs consecutively), and the preset isn't yet loaded when the CC is received"). If that should really be the case, why does it work when other CC messages are used (instead of CC69)?

 

Would anyone have any news on this? My firmware is 3.01.0.

 

Thanks!

[jayfirka]

I've just bought an ES-5 too and am having the same problem. It's extremely disappointing since I've solely bought the controller with the idea to switch to specific snapshots on a dime.

[DunedinDragon]

I don't know why this would surprise anyone.  When you change presets there's a bit of internal processing that needs to take place which involves unloading the current preset and loading the new preset before anything can be done on the new preset.  It's always been that way.  That's why you can't physically (through footswitches) select a snapshot until after you've changed and loaded a the new preset.  If your MIDI controller allows for a delay or for buffering of outgoing MIDI commands you could possibly pull this off.  Other than that were you to save the target preset with the appropriate snapshot selected, then simply selecting the preset would automatically load and engage the snapshot you saved it with.

[abw1989]

33 minutes ago, DunedinDragon said:

I don't know why this would surprise anyone.

 

It would surprise me as it works perfectly well in firmware 2.9.3  which I've rolled back to. It's clearly an issue in firmware 3.x onwards.

[rogerio_sugui]

On 4/2/2021 at 10:13 AM, DunedinDragon said:

When you change presets there's a bit of internal processing that needs to take place which involves unloading the current preset and loading the new preset before anything can be done on the new preset. 

 

That's not correct. If you send any other CC besides CC69 along with the PC message, it does process everything correctly.

 

On 4/2/2021 at 10:13 AM, DunedinDragon said:

Other than that were you to save the target preset with the appropriate snapshot selected, then simply selecting the preset would automatically load and engage the snapshot you saved it with.

 

Although this can be done, this would be just a non elegant workaround for this faulty behaviour. The Hx Stomp offers snapshots for a reason. This is the same reason I would not like to replicate similar presets, occupying 2 or 3 times more presets than I should.

 

Just adding an additional info: I have registered a support ticket. However, the answer I first got was that "if the CC command is being sent via instant commands, along with a preset change, then the preset change will supersede the snapshot change. Since the preset does require the process to load it onto the HX Stomp, the CC command can't be done at the same time", and "Its much easier to simply save the preset desired to with the snapshot you want. Then change it after the preset has been loaded".

 

Honestly, I got really disapointed with this answer, because technically this is not correct, and I had someone from Line6 telling me that it would be "much easier" to have an approach where I could not take benefit of the snapshots. Well... I reiterated the question, based on two main arguments: 

 

A.) Before version 3.0 was launched, it did work (based on customers reports)

 

B.) When I send any other CC command, along with a preset change, the preset change DOES NOT supersede the CC command. I tried sending preset change along with CC49, CC50, CC51, CC71-0, etc., and all of them work, but not CC69.

 

The answer I got was: "I will need to look into this further, and see if our team has seen the same thing. We are currently getting alot of requests, so it may take me some time to attempt at reproducing", which is, again, very frustrating... :-(

 

[rd2rk]

1 hour ago, rogerio_sugui said:

Honestly, I got really disapointed with this answer, because technically this is not correct, and I had someone from Line6 telling me that it would be "much easier" to have an approach where I could not take benefit of the snapshots. Well... I reiterated the question, based on two main arguments: 

 

A.) Before version 3.0 was launched, it did work (based on customers reports)

 

B.) When I send any other CC command, along with a preset change, the preset change DOES NOT supersede the CC command. I tried sending preset change along with CC49, CC50, CC51, CC71-0, etc., and all of them work, but not CC69.

 

The answer I got was: "I will need to look into this further, and see if our team has seen the same thing. We are currently getting alot of requests, so it may take me some time to attempt at reproducing", which is, again, very frustrating... :-(

 

A) I believe you are correct. This is not the first time this came up, and I know that it worked in previous versions because I tested it before telling someone else how to do it.

 

B) The reason they gave you is technically correct per what DD said above. The Preset needs to fully load before a Snapshot can load. It's very likely the support person you spoke to was entirely unaware that this once worked, as it's not really something that a lot of users do, and he used the term "supersedes" (implies intentional behavior) when he should have said that the message is sent, but since the preset hasn't loaded, it just doesn't work as expected, it just goes on by into the ether.

 

I think that what happened is that in the course of adding the new MIDI functions that came with v3.0, the piece of code which checked that if an incoming MIDI command is CC#69, Helix should WAIT X-ms before processing so that the Preset has time to load first, got lost. In any case, I reported it when I discovered it (another thread), you've reported it, let's hope it gets fixed in v3.1, If not, I assure you that I will bug them about it, and you should too! We'll gang up on 'em!

 

[soundog]

...wondering if your controller allows a separate command sent on a momentary switch "press down" (for PC) and "release" (for the CC). I've got an old controller that allows that. If so, try it. Or try repeating the CC command in a string numerous times. One of them might take hold. Just need enough milliseconds for the new preset to be activated and accept the CC command.

[rogerio_sugui]

4 hours ago, rd2rk said:

The Preset needs to fully load before a Snapshot can load.

 

Yes! I understand that and agree. However, the same applies when you send any other CC messages... and for all theses other CCs, it works.. that's what is strange.

 

4 hours ago, rd2rk said:

I think that what happened is that in the course of adding the new MIDI functions that came with v3.0, the piece of code which checked that if an incoming MIDI command is CC#69, Helix should WAIT X-ms before processing so that the Preset has time to load first, got lost.

 

I agree with you, and this would explain why only CC69 is not processed in version 3.0.

[rogerio_sugui]

2 hours ago, soundog said:

...wondering if your controller allows a separate command sent on a momentary switch "press down" (for PC) and "release" (for the CC). I've got an old controller that allows that. If so, try it. Or try repeating the CC command in a string numerous times. One of them might take hold. Just need enough milliseconds for the new preset to be activated and accept the CC command.

Regarding the first suggestion, unfortunatelly no... :-( About the 2nd suggestion, I have tried that but with no success. Apparently, the midi messages are sent with such short delay in between each one that the Stomp still can not handle the CC69...

[rd2rk]

1 hour ago, rogerio_sugui said:

Yes! I understand that and agree. However, the same applies when you send any other CC messages... and for all theses other CCs, it works.. that's what is strange.

 

In a previous life, I did quite a bit of computer application programming.

It only takes a small error in an algorithm to let something like that happen. Writing code, especially the kind of complex code that goes into something like Helix, is tricky.

It gets even trickier when you're modifying existing code, especially if the coder didn't write the original code.

Then, in beta testing, if the mistake doesn't throw an error, and you're not testing that function specifically, the problem wouldn't even be noticed.

And finally, there's always a long list of stuff their small crew of programmers needs to do. Even if the problem gets reported, if it's not high on the priority list, well, you know about the squeaky wheel. That's why we need to stay on their case if it doesn't get fixed in v3.1.

[rogerio_sugui]

An update...

 

I received a reply on my support ticket. In summary, they recognized that this popped up after 3.01 was released. Although it's not likely going to be fixed in 3.10 update, it will likely be back to normal after that next update.

 

That may not be the perfect news, but I'm happy that they gave attention to a customer report and addressed it.

[DunedinDragon]

We used to refer to these as "over yonder" bugs.  As in, fix a little something over here and something completely unrelated pops out WAAAAAAY over yonder.....

[rogerio_sugui]

V3.10 has just been released. In its description, it says that CC69 problem is now fixed. However, I have just updated it and tested it, and unfortunately this still is not working... has anyone else tried?

[datacommando]

4 hours ago, rogerio_sugui said:

V3.10 has just been released. In its description, it says that CC69 problem is now fixed. However, I have just updated it and tested it, and unfortunately this still is not working... has anyone else tried?

Hi,

 

If you think you have discovered a bug, then you really need to post to the section where it will has more chance of being noticed.

 

https://line6.com/support/topic/16083-helix-bug-reports/

Hope this helps/makes sense.

 

[abw1989]

4 hours ago, rogerio_sugui said:

V3.10 has just been released. In its description, it says that CC69 problem is now fixed. However, I have just updated it and tested it, and unfortunately this still is not working... has anyone else tried?

 

 

Yup, disappointed doesn't cover it. I was optimistic for this update when I read the release notes regarding CC69 but I'm still getting the exact same response I had in 3.01. Oh well, back to 2.9 I go...

[mousepunk]

If you have a delay option in your midi controller, you can set it to 130 ms to turn the snapshot on along with the preset.

[rd2rk]

10 hours ago, rogerio_sugui said:

V3.10 has just been released. In its description, it says that CC69 problem is now fixed. However, I have just updated it and tested it, and unfortunately this still is not working... has anyone else tried?

 

Confirmed. It does not work.

 

54 minutes ago, mousepunk said:

If you have a delay option in your midi controller, you can set it to 130 ms to turn the snapshot on along with the preset.

 

It's supposed to be fixed so that this is not necessary:

 

New and Improved MIDI Implementation

Helix Floor, Helix Rack/Control, Helix LT, HX Effects, HX Stomp, HX Stomp XL

Switches in Snapshot Footswitch Mode can now have custom labels and colors.

• MIDI Snapshot changes on CC69 that are received during preset loads will now be buffered and executed once the preset load is finished. This means that you can send a MIDI Snapshot change immediately after a PC message to effectively load a preset with a different Snapshot than it was saved with.

 

 

EDIT: Support Ticket opened.

[rd2rk]

I've been playing with this for a while now. To make the situation even worse, depending on which preset you're coming from (001-000; 002-000; New Preset-000), sometimes it works, sometimes the SS# on the display flashes the desired SS before switching to either the saved SS or, in some cases, I've seen the display for SS3 flash (or not) before going to SS4!

 

FWIW - I'm running a MIDI Monitor while I test, and my FCB is sending the proper message in every case.

Also FWIW - In 3.01, if I placed a WAIT between the PC# and the SS#, it worked fine. I haven't tried this in 3.1.

 

There's a BIG problem with this algorithm. 

[rd2rk]

Reply to my Support Ticket:

 

From one of our software engineers:

âSo this technically does work, but there seems to be some sort of thread priority bug. I am seeing that even when the CC69 is sent after the PC, the actual time it takes to load the preset can be longer than the CC69 being received depending on what is in the preset, which would result in the snapshot not being loaded as expected.

Using the wait parameter in command center set to 150ms or higher would avoid the issue. Or if an external device has a wait feature, using it there to send the CC69 to Helix/HX would work as well.

To Clarify, it is the CC69 that should be set to wait 150ms or so, not the PC message.â

 

-----------------------------------------------------------------------------------------------------------------------------------------------------

 

IOW - there's a new WAIT parameter in Command Center, but if using an external controller, it must be capable of adding it's own WAIT command.

 

EDIT: I haven't had a chance to try this yet, but I'm thinking that if you use CommandCenter to assign the Preset/Snapshot load to a FS using the WAIT command, then trigger the FS from the external controller instead of sending the PC and CC, that might work I'll try it later and report back.

 

EDIT EDIT: Of course that doesn't work. What was I thinking? Need more coffee.

[datacommando]

3 hours ago, rd2rk said:

Need more coffee

 
Keep at it, you will crack it in the end.

[rd2rk]

2 hours ago, datacommando said:

 
Keep at it, you will crack it in the end.

 

I fear that I've been foiled by a dreaded "Thread Priority Bug". 

Hopefully they'll fix it in v3.11 (3.2? Baffling version numbering system...)

[mousepunk]

Fixed with the last update. Yay!