Helix 3.7: The Freeman Update

They could do with some sort of "hold this thing and then turn the knob, and you'll get properly fine micro adjustments"

Thought about that, too, but given that finetunings are often done while you, say, hold a chord or note (or simply just need to stabilize your guitar while dialing things in with the other hand), that's not exactly the best solution. If it wouldn't confuse people a lot (which it would, so that's just hypothetic), the default press/dial behaviour could be switcheable from default-reset/snapshot-control (which it does right now) to "hold = fine" or "hold = larger movements" (which I'd likely prefer as I need it less often). But as said, switcheable knob behaviour would confuse folks.
Anyhow, personally, I'd still like to have the old behaviour back. I do all larger adjustments via the editor anyway.
 
as long as just "auto-accelerate" is concerned, the different parameter resolution isn't too relevant.
The parameter resolution combined with the total range is indeed relevant. If you have a range spanning 1 to 1000, and need quick traverse between those two endpoints, but also require single-digit precision, that will be much more demanding on encoder resolution and encoder sampling frequency than a range of 1 to 10. This is because of the math involved in implementing acceleration curves which feel natural to the user.

Intuitively it doesn’t seem like it should be the case—“just spin the knob faster and make it go faster!”—but when you work through the math behind it, the challenges reveal themselves.
 
The parameter resolution combined with the total range is indeed relevant. If you have a range spanning 1 to 1000, and need quick traverse between those two endpoints, but also require single-digit precision, that will be much more demanding on encoder resolution and encoder sampling frequency than a range of 1 to 10. This is because of the math involved in implementing acceleration curves which feel natural to the user.

Yeah, you're possibly right - but otoh, I don't think it'd be *that* much of an issue. It's just realized way less than ideal within the HX family.
 
And fwiw, I just had a look. The vanilla Digital Delay of the Zoom MS-50 has a range from 0-3000ms, can be adjusted in 1ms steps. So, that's quite comparable to the average HX family delay (whatever it might be). Editing on the Zoom is a whole lot easier than on the HX Stomp. Acceleration included. In fact, the HX acceleration seems to be somewhat broken. Sometimes, when you dial faster clockwise (which should take you to higher values quicker), it's jumping down to lower values. *yuck*
 
Acceleration is not simple to implement.
Besides the velocity derivative (position over time) and a counter to accelerate to 'next speed' when you turn at high enough velocity the second time, you also have to include several conditional time counters to not lose the acceleration values when you stop turning to reposition your fingers.
I probably forgot several details but encoder acceleration is NOT easy to implement or tweak the implementation until it feels just right.

Edit:
I also want to say that we don't know what is the resolution of the screen encoders, we might be on the edge of the hardware capability as SwirlyMaple said, or not.
 
Last edited:
In fact, the HX acceleration seems to be somewhat broken. Sometimes, when you dial faster clockwise (which should take you to higher values quicker), it's jumping down to lower values. *yuck*
I explained why this happens a few replies above. If the rate of rotation exceeds the encoder’s sampling frequency, it misses pulses. So instead of seeing 20 per second, it might see only 10 or 5, for example. The faster you turn it, the worse it will get. At a certain point, fast rotation in one direction will look like slower rotation in the opposite direction to the algorithm that converts those pulses to rotation.

Remember, the Helix hardware dates back to 2015. It’s entirely possible that the encoders used are not up to 2023 standards for resolution and sampling frequency, and if so, no amount of software tweaking will fully bridge that gap.
 
Last edited:
And fwiw, I just had a look. The vanilla Digital Delay of the Zoom MS-50 has a range from 0-3000ms, can be adjusted in 1ms steps. So, that's quite comparable to the average HX family delay (whatever it might be). Editing on the Zoom is a whole lot easier than on the HX Stomp. Acceleration included. In fact, the HX acceleration seems to be somewhat broken. Sometimes, when you dial faster clockwise (which should take you to higher values quicker), it's jumping down to lower values. *yuck*
I have to agree, the Delay Time acceleration is not very good either, I'm having a hard time to reach my destination unless I 'learn' the encoder's behavior and pay careful attention.
 
For those with an extra footswitch or midi controller, you could add a CC to toggle "slow/fine mode" versus "fast/coarse" mode. Build it and (a small number of) they will come.
 
Remember, the Helix hardware dates back to 2015. It’s entirely possible that the encoders used are not up to 2023 standards for resolution and sampling frequency, and if so, no amount of software tweaking will fully bridge that gap.

As said, the MS-50 does it almost perfectly. A cheap a$$ device more than two years older than the Helix.
 
I explained why this happens a few replies above. If the rate of rotation exceeds the encoder’s sampling frequency, it misses pulses. So instead of seeing 20 per second, it might see only 10 or 5, for example. The faster you turn it, the worse it will get. At a certain point, fast rotation in one direction will look like slower rotation in the opposite direction to the algorithm that converts those pulses to rotation.

Yeah, even my technically mediocre brain understands that to be a possible reason. But it still shouldn't happen. I mean, it doesn't happen on other devices, either.
 
Remember, the Helix hardware dates back to 2015. It’s entirely possible that the encoders used are not up to 2023 standards for resolution and sampling frequency, and if so, no amount of software tweaking will fully bridge that gap.

What?! No. I can guarantee this is not the case.

Disclaimer: don't work for L6, of course, but my background is on Electronic Engineering.
 
Yeah, even my technically mediocre brain understands that to be a possible reason. But it still shouldn't happen. I mean, it doesn't happen on other devices, either.
It happened a lot on an M Audio MIDI controller keyboard I bought back in 2014. That had by far the worst digital encoder response of anything I’ve ever used. It was so bad I actually returned it because of that, even though the piano keys on it were pretty good.

I don’t know if the major difference between the devices in question is hardware or software, or both. I do know that there are a few different types of incremental rotary encoders. Some are mechanical, some are optical, some are magnetic, and the measurement resolution varies although most are pretty high. Mechanical encoders (which are common in consumer electronics) are prone to other accuracy issues like the pulse edge de-bouncing that James mentioned, and this limits the max rotation speed they can accurately function at.
 
Nice, another compressor I won't ever use. Yay.

Ok, I use one on bass, the Opto Comp. But I just copy some settings from the (real) Opto Comp manual and never fiddle with it.

Can we have a gnarly Fuzz, too, that sounds like my guitar is played through an 1 inch speaker in an Altoids box? Already have that for the shoegazers?

Just joking. Be thankful for anything that is extra. Love and peace. X O X O.
 
Enter Jason Sadites ”glue” method
:bag

(No… never felt any of that is needed personaly… but it is funny how the forums got all winded up by his gluing)
IMG_1469.jpeg
 
Back
Top