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...