Helix Talk

I don't blame Line 6 at all here.

I do. I mean, if you knew me, you'd know that I hate Apple with a passion (even if I'm using their products), but in this case only Line 6 is to blame. No decent audio interface driver requires rebooting into "security adjustment mode" (in lack of better words) to even make it work.
 
No decent audio interface driver requires rebooting into "security adjustment mode" (in lack of better words) to even make it work.
Universal Audio's do at least. https://help.uaudio.com/hc/en-us/ar...M3-Compatibility-with-Universal-Audio-Devices

My understanding is that a big part of the issue is that Apple introduced a framework called DriverKit that you are supposed to use to develop drivers. But that means you need to start all over with the driver development. A lot of work, testing and development cost just to satisfy Apple's ever-changing security measures. Instead many opt to just keep using the kernel extension based driver, and ask users to adjust the security settings because they don't have the resources to write a new driver right now, or it will take a lot of time to do that and they want their users to still be able to use their hardware as usual.
 
[…] No decent audio interface driver requires rebooting into "security adjustment mode" (in lack of better words) to even make it work.
That‘s not true. Kernel extension drivers were the standard until Apple decided to put security restraints on them and force developers to code new drivers for DriverKit. Many companies struggle(d) to deliver DriverKit drivers that perform as good as the old ones (you can read a good article about this on the RME website).

However, I do blame Line 6 for shitty latency of their driver.
 
  • Like
Reactions: Elf
That‘s not true. Kernel extension drivers were the standard until Apple decided to put security restraints on them and force developers to code new drivers for DriverKit. Many companies struggle(d) to deliver DriverKit drivers that perform as good as the old ones (you can read a good article about this on the RME website).

However, I do blame Line 6 for shitty latency of their driver.
Video from the article I think you meant:



I wouldn't be surprised that this is also the reason some audio interface companies don't have their own Mac drivers.
 
My understanding is that a big part of the issue is that Apple introduced a framework called DriverKit that you are supposed to use to develop drivers. But that means you need to start all over with the driver development
That‘s not true. Kernel extension drivers were the standard until Apple decided to put security restraints on them and force developers to code new drivers for DriverKit. Many companies struggle(d) to deliver DriverKit drivers that perform as good as the old ones (you can read a good article about this on the RME website).

Ok, thanks for the clarification, folks. Still, I think a company such as Yamaha should have the ressources to develop something better. I mean, it works for others, too (even if not for all of them).

However, I do blame Line 6 for shitty latency of their driver.

Yeah well - but you gotta give them props for being the worst in this class.
 
I actually don't care whether any one else buys or sells Helix devices beyond the point I want to see L6 succeed, both in gratitude for the immense enjoyment I've got from my Helix device (LT, and I'll throw in my barely explored POD E even though it's technically not Helix), and so that they will judge it worth their while to invest in new flagship-caliber "Helix successors" in the future.
 
Side note but, to this day, i don't know why Helix/HX drivers even require drivers to work. Thery're *almost* USB class compliant, failing just to report the correct sample rate back to the host.

In Linux, for example, sample rates for different HX products at hardcoded at kernel level. Helix products are literally plug-and-play.

Unless i'm missing something obvious, i see no reason why this couldn't be fixed via firmware updates, and be done with drivers for good.
 
Last edited:
Side note but, to this day, i don't know why Helix/HX drivers even require drivers to work. Thery're *almost* USB class compliant, failing just to report the correct sample rate back to the host computer.
Wait... failing to report the correct sample rate to the host? Is this from the hardware? When I hook up my Helix (Floor or LT) to iOS devices, trying to film using the iOS Camera app and the Helix audio in Class Compliant mode, I get recorded audio that has crackles and pops, just like when there's a mismatch with the sample rates.

I've been at this with L6 support for 2 weeks now, seemingly with no success to understand or remedy the issue.
 
Fwiw, my "half apologies" to L6, it does indeed seem to be a common hassle for interface makers to deal with Apples security measures.
I just learned that Focusrite give you an option to either use their interfaces in class compliant mode or original driver supported as well - now, the same could be said for L6, but with the Scarlett 2i2 4th Gen, latency is at least dropping when going for the original driver option.
 
Side note but, to this day, i don't know why Helix/HX drivers even require drivers to work. Thery're *almost* USB class compliant, failing just to report the correct sample rate back to the host.
Wait... failing to report the correct sample rate to the host? Is this from the hardware? When I hook up my Helix (Floor or LT) to iOS devices, trying to film using the iOS Camera app and the Helix audio in Class Compliant mode, I get recorded audio that has crackles and pops, just like when there's a mismatch with the sample rates.

I've been at this with L6 support for 2 weeks now, seemingly with no success to understand or remedy the issue.
Indeed. Somehow, Helix does not respond to sample rate requests.
@Digital Igloo is there anyway to get this crucial info to L6 support, in hopes that they put the pieces together? I haven't been able to get support to verify this issue, even though it's consistent and repeatable. Even others are having this issue (link)...
 
Ah, and speaking of YouTube clickbait...

Screenshot from 2024-04-21 18-44-18.png


*loud sigh*
 
That's kinda cool. A lot of possibilities with those midi wifi thingamabobs.

The main issue with all these things being that once you switch a patch, everything is lost. There's just no feedback between the hardware and the software.
This is precisely why Line 6 should come up with something like that on their own. Doesn't even have to be a fullblown editor, call it a "performance tool" or whatever. Would still work best with global blocks in addition as such a tool would be the perfect place to adjust your HX series device to suit whatever live situations.

Btw, you don't need wireless MIDI for this stuff at all, a plain old USB OTG adapter will do.
 
Btw, you don't need wireless MIDI for this stuff at all, a plain old USB OTG adapter will do.
Yeah, I just like the wireless aspect of it.
Honestly, I need to do some research in midi switching functions for the helix stomp. Can you do full patch switches in the stomp with something like the voodoo lab midi switcher? I have a couple of them.
 
Back
Top