shmaque

Hit my first show-stopper level 3.15 issue today (Helix Floor): I like to run Stomp/Snap mode, with four snapshots on the bottom row and four stomps on the top (for my live style, it just works best for me). However, on some presets, I end up using more than 4 snapshots. Rather than manually having to remember which presets to hit bank up+down to switch to 8-snap display, I’ve taken to assigning snapshots to some of the top row stomp switches via command center. This worked great through 3.11, but at least one of those presets went berserk today on 3.15. snapshot1 looks & behaves totally normal (first image), but when I hit snaps 2-4, the upper row flips to SNAPSHOT^ on all buttons. To fix this, I had to enable “recall” for snapshot edits, and walk through every snap in the patch, manually fixing the command center setting, then re-save. Basically, I’m saying something broke my preset in the 3.15 preset rebuild & only retained the snapshot setting metadata for the first snap in these kind of patches. The rest knew there was a cmd center event, and knew it was a snapshot event, but overwrote it with “1” (Next). Yes, I did a full factory reset & restore from backup when upgrading, including letting it rebuild all of my presets after the restore. EDIT: even stranger, it only appears to have affected this one preset. All of my others (which only have one cmdCenter snap saved as a stomp vs the 4 here) are fine EDIT #2: You know what, I apologize. I just went back and decoded/parsed all of my setlist backups for the past year. This issue has been in my patch since at least last August, which tells me something different, but equally interesting: this must've been a bug in previous firmware, where snapshots didn't honor different parameters on CommandCenter settings from one snap to the next that they fixed in 3.15. I don't see anything specifically tied to it in the release notes, but perhaps it was related to some of the other CommandCenter bug fixes. So, yeah. The firmware is actually doing what it's supposed to now. *shrug*

fwiw I'm not sure this is anything new. It was definitely there in 3.0 (don't recall what that screen looks like on 2.9x), but as a midi user, I kind of appreciate it & hope it sticks around. I also found it in a screenshot on a L6 wiki page: https://helixhelp.com/manuals/helix/midi/

For anyone else who gets stuck here (found several other threads related), I was one of the folks who got stuck on "Firmware downloaded successfully" and then nothing when attempting to update to 3.01 from 3.0 via hx edit 3.0 (note, didn't hang my helix, just refused to start pushing the update down). The L6 solution worked just fine - make a backup; go grab the latest L6 updater standalone software; manually update; manually factory reset (sw 9+10 on helix floor, eg); restore backup in hx edit.

Honestly as a MIDI hound I kinda like it. CC32 is bank, PC index, and CC69 is snap. I honestly can’t remember what’s normally above that knob?

As long as the Stomp is being sent a MIDI tempo/clock, it'll slave to that. If that (constant) clock goes away, it'll revert to whatever you had previously tapped in. So, depending on how the loops work on your RC500, that's either ideal or makes it impossible to do what you want to do :) (It's an all or nothing thing, and I'm not sure if you can arbitrarily tell the RC500 to send clocks or not send clocks on a loop by loop basis)

Correct, the HX logic (at least up to the last time I did this a year or so ago) needs the midi clock constantly sent to it to be slaved to that tempo - it doesn’t train its internal clock to the midi clock, but rather switches over to it wholesale (tap led turns blue iirc). Once the midi clock stops being received, it reverts to its internal clock (which hasn’t been re-trained at all throughout this process). And yes, this is contrary to how several other vendors do it, and is super annoying.

Yes. Interestingly, increasing headroom to max just seems to increase the volume at which the oscillation happens. Even more interestingly - I just tried to recreate it in Helix Native and can only replicate the issue if I select 6 bit. The other bit depths all behave properly, while 6 hangs out with a steady ~-50 to -48dB (depending on the headroom setting) circuit noise repeat forever. <EDIT> I take that back - I switched to a slightly noisier stock setting for sanity check (01B Essex A30) and added the vintage digital right at the front of the chain. 6,8, and 16 bit all exhibit this behavior even in Native.

Help me out here - I rarely use the Vintage Digital Delay, but in 2.92 I'm noticing that if you select 6, 8, or 16 bit depth (6 is especially gnarly due to the bit corruption), it will infinitely oscillate the noise floor after processing any sound (even if you immediately then ground the input or put a volume block at 0% immediately preceding the delay) with anything > 2% for a feedback setting on the delay. 10,11,12,14, and 24 bit do not do this. Flipping to another preset and back kills it until you play something else, as does moving blocks around in HX Edit. Is this some quirk that's accurately being modeled or a bug? I've never encountered this before, and I swear I've used 16 bit before.

Talked to a friend who had experienced the same thing w/ this model in the 2.8 fw range - he said try tweaking down the Hum parameter; on his end it was actually the modeling of line hum that was causing this odd harmonic to show up.

I’ve actually had a similar support ticket open for the better part of the last year. Just had it bite me again tonight (still on 2.82 because I’m waiting for the 2.9 new bugs to settle). Mine always happens when copying a preset to a new slot *from within HX Edit* - I’ve never had corruption from saving to a new slot directly on the unit. It seems like the sysex command (or whatever wrapper they use to send commands down) gets a corrupted length value and just plows over massive sections of flash. My ONLY fix has been to reset all set lists to factory default with buttons 7&8 and manually start restoring from backups again. It’s freaking infuriating.

Hate to necrobump, but I just had this happen to me again (fw 2.82.0) while copying blank presets over existing ones in HX edit. End of this particular setlist is irrecoverably corrupted again just like a couple months ago. My guess is there isn't much data validation going on and one of the messages from HX edit got corrupted, causing it to stomp on flash where it shouldn't. Guess I'm off to restore presets again and hope my patch backups are up to date...

It's dead simple using Morningstar's editor - you can do it manually on the controller itself, but it takes much longer - I'd strongly recommend the editor - look for info and user guides on Morningstar's website. Regarding useful commands for controlling the HX Stomp, here were the main ones I used: Disregard the channel 6 bit - you'd set the midi channel on the mc6 to whatever you've got the HX configured for. Preset selection is a midi PC (program change) with whatever number preset you want. The others are all midi CC (control change) message types with the id selecting what type of control and the message value being the setting eg on vs off (second column in my picture) This is all out of the user manual - I just had stashed it in a spreadsheet for quick reference. Cheers

Firmware: HX Edit 2.81, Helix FW 2.82.0 OS: OS X High Sierra Bug: Just filed a ticket for a setlist corruption issue that I've had multiple times tonight when copying patches around within a setlist. Giant chunks of the setlist will become corrupted (names scrambled or blank, and previously empty patches filled with random dsp blocks). Attempts to overwrite the corrupted patches crash the helix & require a power-on-reset. Rebuild all patches doesn't fix this, nor does restore from backup. The only solution I've found is to reset all presets/setlists & manually restore the patches, however, I had the exact same issue pop up on a different setlist while restoring my patches, so I'm not sure if it's just a game to see when it'll next strike or what. Found one other person w/ the same issue about a week ago: https://line6.com/support/topic/52598-corrupted-presets/ which, combined with the way it moved between setlists for me tonight, tells me it's not likely a flash memory failure, but an actual bug in writing patches to flash in this latest fw version. EDIT: just realized somehow I was still using HX Edit 2.81. I'll update to Edit 2.82 and verify it's still an issue.

Oddly enough, I wiped all presets/setlists & all was good again. Tried manually restoring my patches to a *different* setlist one at a time (not from a setlist backup), and that setlist got corrupted, too. I'm trying to narrow down if one specific patch is causing it, or if it's just interacting with hx edit that's my problem... The way it followed me into a different setlist in much the same way makes me doubt it's a problem with the flash itself?

@themetallikid I just had the same exact problem (fw ver 2.82) - landed here searching for any others w/ this issue. Mine's a couple of ranges of contiguous patches in setlist #3 that were previously "New Preset" and are now all corrupted. Same symptom - can't overwrite them w/o error, and trying to blanks the helix screen requiring a reboot. I was hoping it was just a memory corruption, but I'm not encouraged by the fact that yours persisted after a wipe. Maybe I'll try /not/ doing the restore from backup & see if that helps...

Honestly the only thing you really have to be attentive to is the input impedance. By default it'll be set to 'auto' which sometimes lends itself to impedance mismatches that cause awkward volume drops or pedal misbehavior. If you pay attention to your pedals' output impedance & set the Stomp's input to something appropriate, it behaves amazingly well with every amp model I've tried.

Now this thread is more my speed :) Gotta admit, as much as I resisted it, the MIDI control options open up a whole new world... I've got the MC6 configured for patch and snapshot + bypass looper controls primarily, but always have a hidden quick-jump menu one click away that has deep dive commands set up for the looper, stomp, Riverside, and Big Sky that I can jump in and back out of easily to tweak on the fly. It's wired up to support 4CM, direct out to FoH, or both simultaneously (amp is in an fx loop). Loving it!

Just to follow up on this: after sending an example patch and video of the problem, Line6 support was able to reproduce this behavior & has filed a bug ticket to be fixed in a future FW rev. There's definitely a flash read/write bug wrt the snapshot tempos in 2.71.

Haven't found this in a search, but has anybody else had major issues with snapshot based tap tempos not working lately? HX Stomp FW ver 2.71 - tempos set to per snap, snap changes set to discard. When editing a snap (eg to enable a block) and then saving, the snap will at times arbitrarily adopt (and save) the stored tempo for a different snapahot. This happened to me about 4 times over the weekend when trying to save quick updates to gain structures. Additionally, tapping manually to override the current snapshot's (eg ss3) tempo, then switching to a different snap and back does *not* restore the snap's (ss3) stored tempo. Instead, it reverts to whatever I tapped while 3 was last selected, regardless of the fact that snapshot changes are set to discard. Seems tap tempos are all squirrelly in this FW version - is this an issue on floor/lt or just stomp?

I'll add one more solid vote for the MC6. IMO, Morningstar is lightyears ahead of the DMC in terms of flexibility and capability, not to mention overall design quality. The DMC doesn't even come close as far as I'm concerned. Re: your second question - by default on the Stomp, the base predefined midi commands can only selectively manipulate presets or snapshots or reproduce the function of any one of the Stomp footswitches. *HOWEVER*, you can selectively assign any individual dsp block on the stomp to learn a unique MIDI CC message from the controller, and toggle that setting on and off just by sending that CC witha value of 0-63(off)/64-127(on). As far as I can tell, that's always possible regardless of play mode/stomp footswitch setup, since you've baked it into the chain. It's really super flexible. See page 48 on the Stomp manual for info on custom bypass per block via MIDI.

Yeah sorry - didn't mean to have my contempt for the shortcoming bleed through in my response. :) The sad part is that snapshots are flat out amazing, and the hx stomp shortchanges that feature in a way that feels excessive and artifically limiting. I suspect (and this is pure speculation) that even though the stomp technically supports 5 footswitches, the extra features associated with capacitive touch made it simpler to just limit to 3 snapshots. I'd like to believe the reason is more complicated than that, but somehow I don't believe it is. 3 is just a very small number, and once you get into the territory of compensating with a more capable midi switcher (eg the mc6) the question of why you'd chose stomp vs LT really comes back into play.

Kilrahi, I think you're missing one of the fundamental benefits of snapshots vs presets - the delay (however subjectively short) associated with forcing the unit to load a new dsp chain (preset) vs the instantaneous response of a snapshot change. That's kind of the entire beauty behind snapshots. If you're stopping in between songs, sure preset changes get you there just fine. If you rely on continuity and trails, you're screwed. So surely, your proposed scenario does *not* cover most situations for any of us in that boat. Also, yes, I've considered "stompshots" (and will actually be using a MC6 to do exactly this to overcome the snapshot limitation) - it just stinks for those of us whose setlists change drastically one week to the next to now have to program two units for every change as opposed to being able to leverage capability that's a huge boon in every other helix family platform.

Agreed 100%. I can get behind even eliminating the dynamic dsp at this price point, but the 3 snapshot limit feels extremely underhanded as a user. I was really hoping to see it expanded to at least 4 or 5 in 2.70, but alas, no. Really hope they'll at least consider this for future fw revs...