Helix Bug Reports

[Metal-Cellista]

saving issues in HX Edit with multible devices attached:

 

last week in the rehersal i had attached my LT. as i pluged the USB cable out of the LT and into the stomp of my colleaque without closing HX Edit in between, HX Edit opened the Stomp in a new window but the user presets on the Stomp instantly where messed up. some where missing, the others in a weird order.

i hope, this description helps to recreate, trace and eliminate the problem.

 

LT and HX Edit had the latest updates. with the Stomp i am not 100% shure but the hardware was shiped just two weeks ago. so i guess its 2.8, maybe 2.7.

[fish95]

ok. I got another one:

Took some time to figure out the "auto-engage" of wah-wahs, but I got it now :-)

 

Set up everything, works fine, wah engages when the pedal is moved, so far - so good.

Patch has been saved.

I select the wah-block and dial in another wah with the joystick, the "bypass assign" resets to "EXP toe switch".

I got to re-assign to EXP1 in the "menu / bypass assign screen" and save it again, before it works as set up before.

Otherwise the controller will show the movement from 0-100%, but no fx.

 

It´s quite annoying, because you have to re-assign and save the preset after every singke change to get it work properly.

Turning back to the saved wah-block (so to say, the preset as it has been saved) will let the bypass assign set to "exp toe switch",

it´ll not return to the saved setting.

 

Maybe this has been posted before?!

 

Helix rack, floor control, FW 2.82 

[HonestOpinion]

On 10/19/2019 at 6:35 AM, PeterHamm said:

 

...

And, fwiw, you will, if you follow your plan, get 11 or 12 YEARS out of that Mac Pro. Try that with a Windows machine. In my experience, that ain't happening.

 

Having friends who are absolute Apple fanatics I also don't want to get in a platform war but I have to say I am running on a couple of Windows desktop boxes and even a laptop that are probably about ten years old or close to it with Windows 10 installed and they are still running just fine although I also have a couple of laptops that are more recent. Have to say Microsoft has been pretty good about their OS versions having backwards compatibility with old hardware, especially in recent years. Matter of fact I have been kind of shocked that I have not been forced to upgrade my hardware already by Moore's Law or other advances. I just have not seen the kinds of exponential leaps in speed and operation in the last few years that kept me in a constant upgrade cycle for decades. Not saying boxes haven't gotten faster but they seemed to reach a sort of baseline several years ago where unless you were doing something like advanced graphics processing any slowness in older machines was fairly tolerable. 'Course I am not much of a gamer these days and you can always get an Xbox or PS4 for that. The only reason I would upgrade would be DAW latency issues. A lot of ills can be prevented just by throwing enough RAM at your PC. Guess I'm holding off to buy my first quantum computer.

 

https://www.intel.com/content/www/us/en/support/articles/000006105/processors.html

[jdonah]

Firmware: 2.7.0 through 2.8.2 (HX Stomp)

Global Settings: default all, Footswitches->stomp select->press

Bug: When Press is selected as the option for “Stomp Select” under Preferences->Global Settings->Footswitch it appears to do nothing in that touch capacitance is still active.  It can be quite frustrating to accidentally trigger the Tap Tempo feature with my hand on FS5 while manually adjusting the HX Stomp.  It would be ideal if touch capacitance could be fully disabled through this setting or a separate setting.  

[cgar18]

I guess its not a bug its something that worked before the 2.8.2 update I wonder if there is some way to make it do this again......Using hx edit I was able to switch between amp cab and amp with out the setting changing.It is changing now,not sure if its just me or something that happens now.Just to be clear I would change bass treble middle  settings on an amp cab model and when I would just switch to just the amp model the setting would carry over.

[SaschaFranck]

6 hours ago, cgar18 said:

I guess its not a bug its something that worked before the 2.8.2 update I wonder if there is some way to make it do this again......Using hx edit I was able to switch between amp cab and amp with out the setting changing.It is changing now,not sure if its just me or something that happens now.Just to be clear I would change bass treble middle  settings on an amp cab model and when I would just switch to just the amp model the setting would carry over.

 

So you're saying the amp settings stayed intact when switiching between the two in previous FW versions? That's just nice and I almost filed a feature request already (fwiw, I bpught mine with 2.8.2). Seems as if Line 6 just had to reactivate this very useful feature. I often wish I could keep a patch intact but replace the cab with an IR. And fwiw, IMO there could as well be an IR option for the cabs in the Amp+Cab blocks.

[HonestOpinion]

1 hour ago, SaschaFranck said:

 

So you're saying the amp settings stayed intact when switiching between the two in previous FW versions? That's just nice and I almost filed a feature request already (fwiw, I bpught mine with 2.8.2). Seems as if Line 6 just had to reactivate this very useful feature. I often wish I could keep a patch intact but replace the cab with an IR. And fwiw, IMO there could as well be an IR option for the cabs in the Amp+Cab blocks.

 

Maybe retaining the settings would be a nice option but I stopped using amp+Cab blocks almost immediately when I started using the Helix. Using separate amp and cab blocks provides more flexibility and makes it much easier to swap cabs for IRs or vice-versa. Makes alternate routings easier too. For example all three channels of an amp's blocks(e.g. clean, crunch, lead) loaded up  and routed through a single cab. Maybe I'm missing something but I never use the amp+cab blocks any more. I don't see any advantage to not using separate blocks. Hard to run out of available blocks on the Helix.

[SaschaFranck]

44 minutes ago, HonestOpinion said:

 

Maybe retaining the settings would be a nice option but I stopped using amp+Cab blocks almost immediately when I started using the Helix. Using separate amp and cab blocks provides more flexibility and makes it much easier to swap cabs for IRs or vice-versa. Makes alternate routings easier too. For example all three channels of an amp's blocks(e.g. clean, crunch, lead) loaded up  and routed through a single cab. Maybe I'm missing something but I never use the amp+cab blocks any more. I don't see any advantage to not using separate blocks. Hard to run out of available blocks on the Helix.

 

I totally agree on all points and none of the patches I'm actually using has an Amp+Cab block in them.

Yet, when quickly looking for sounds, that block is pretty handy as it provides a (more or less) matched cab instantly, whereas you'd need to look one up separately using just the amp block (you usually don't want to run a Marshall style amp through a Jazz Rivet cab, do you?). Which, btw, is also why it'd be cool if we could save the default settings ourselves (or even block presets in general, which would as well come in handy for other more complexed blocks such as the delays and reverbs).

[guitphil]

2 hours ago, SaschaFranck said:

 

I totally agree on all points and none of the patches I'm actually using has an Amp+Cab block in them.

Yet, when quickly looking for sounds, that block is pretty handy as it provides a (more or less) matched cab instantly, whereas you'd need to look one up separately using just the amp block (you usually don't want to run a Marshall style amp through a Jazz Rivet cab, do you?). Which, btw, is also why it'd be cool if we could save the default settings ourselves (or even block presets in general, which would as well come in handy for other more complexed blocks such as the delays and reverbs).

Fwiw, I have a "default settings" patch dedicated to my favorite effects settings.  The nice thing about the helix is that i can copy and paste a block from one patch to another with settings from the original block kept in tact.  But yes, being able to save user setting defaults would be nice.  Saving multiple user defaults would be even better.

[SaschaFranck]

36 minutes ago, guitphil said:

Fwiw, I have a "default settings" patch dedicated to my favorite effects settings.  The nice thing about the helix is that i can copy and paste a block from one patch to another with settings from the original block kept in tact.  But yes, being able to save user setting defaults would be nice.  Saving multiple user defaults would be even better.

 

I'm doing it pretty much like you, in addition I'm using Helix Native for such tasks as you can open multiple instances and drag'n'drop between them. When done, the patches go to HX Edit and hence onto the hardware. All this is working miraculously well already and it's almost a godsend. Doesn't mean it couldn't be improved, though.

As just another example: I find myself using the same blocks straight after each other in many patches (such as a certain combination of drives/comps/EQs, amps and cabs). Would be quite a time saviour if this could be done with one copy/paste action.

[SaschaFranck]

And it'd be even better if one could save a bunch of serial blocks as one single "multi block" preset. I know this would possibly be a tad difficult to handle from a coding aspect, due to the dynamic DSP allocation of the Helix, but there's always the good old option of "Not enough DSP power to load/paste!" or "Not enough free blocks to load/paste!" messages.

[jdonah]

Firmware: 2.7.0 through 2.8.2 (HX Stomp)

Global Settings: default all, Footswitches->stomp select->press

Bug: When Press is selected as the option for “Stomp Select” under Preferences->Global Settings->Footswitch it appears to do nothing in that touch capacitance is still active.  It can be quite frustrating to accidentally trigger the Tap Tempo feature with my hand on FS5 while manually adjusting the HX Stomp.  It would be ideal if touch capacitance could be fully disabled through this setting or a separate setting.  

[cgar18]

17 hours ago, SaschaFranck said:

 

So you're saying the amp settings stayed intact when switiching between the two in previous FW versions? That's just nice and I almost filed a feature request already (fwiw, I bpught mine with 2.8.2). Seems as if Line 6 just had to reactivate this very useful feature. I often wish I could keep a patch intact but replace the cab with an IR. And fwiw, IMO there could as well be an IR option for the cabs in the Amp+Cab blocks.

yeah it was nice because I use my helix thru my duncan powerstage 170 going into a 212 blackstar so I would have a setting with the cabs then I would just switch to amp so I can hear how it sounds with the blackstar with out cabs.I know the blackstar is not an frfr but its ok for me I like how the cabs sound and I also like how the 212 sounds with some amp models.

[HonestOpinion]

Firmware: PC+ 2.00.1, HX Edit 2.82, Helix firmware 2.82

OS: Windows 10

 

Bug:  It appears that on the Helix the Global Settings > Ins/Outs > 'Digital Out Level' does not control the level out via L6 Link to the PowerCab+. It has no effect on the PC+'s volume. Is everyone else seeing the same thing? Maybe it works with a device connected AES/EBU but not with L6 Link. At least not for me. Is this as designed or is this a bug in the Helix 2.82 firmware? 

[shmaque]

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.

Edited November 19, 2019 by shmaque
Fixing HX Edit version

[HonestOpinion]

On 11/18/2019 at 5:04 PM, HonestOpinion said:

Firmware: PC+ 2.00.1, HX Edit 2.82, Helix firmware 2.82

OS: Windows 10

 

Bug:  It appears that on the Helix the Global Settings > Ins/Outs > 'Digital Out Level' does not control the level out via L6 Link to the PowerCab+. It has no effect on the PC+'s volume. Is everyone else seeing the same thing? Maybe it works with a device connected AES/EBU but not with L6 Link. At least not for me. Is this as designed or is this a bug in the Helix 2.82 firmware? 

 

After a bit more research I think this may be working as designed. That is to say the Helix's Global Settings > Ins/Outs > 'Digital Out Level' does not control the level out via L6 Link to the PowerCab+. Found the following in the Helix manual although it does not mention the PC+ which had not been released when the manual was written nor does it directly mention the 'Digital Out Level' setting but the wording implies that these settings don't affect the L6 link.:

 

From the Helix Rev.D manual pg. 22:

L6 LINK Output

Alternatively, the digital XLR connector can be used for L6 LINK output (use of a 110Ω XLR cable is recommended). L6 LINK provides easy digital audio connectivity between Helix and Line 6 StageSource speakers and/or DT-Seriesamplifiers. Two StageSource speakers or DT amps can also be connected in series via L6 LINK and your stereo Helix signalis intelligently split,with the left channel going to the firstStageSource/DT and the right channel to the second. If you have one StageSource/DT connected, the Helix output is collapsed to mono and fed to the StageSource/DT. Connecting an L6 LINK device to Helix automatically disables S/PDIF out and routes audio out the digital XLR connector - no adjustments of the Global Settings > Ins/Outs > Digital Audio or Sample Rate options are necessary.

[Andree88]

On 8/19/2019 at 5:59 PM, Andree88 said:

2.81 issue.

 

In my patch in stomp mode I have assign EXT amp in order to change channels of my Engl Powerball 2.

FS 1 (ring) channel 2

FS 2 (tip) channel 3

FS 3 (tip&ring) channel 4

 

If I press in order FS1 - FS2 and FS3 all was perfect in 2.80. (i.e. channel 2 - channel 3, channel 4)

 

Now in 2.81 if I press FS1 - FS2 and FS3 it goes in channel 2 - channel 4 - channel 4.

For me it's a problem, I use a lot channel 2 (crunch) then channel 3 (lead 1) in this order. To access in channel 3 I have to go directly to it by the clean channel, not using channel 2.

 

I rolled back to 2.80 but I hate the expressione pedal problem (set to exp 2 at every reboot). Opened a ticket.

 

Still same problem with 2.82. 

Line 6 said to me to use 2.80 for this problem (or rollback at 2.7x).

Wish they solve the problem, 2.82 is awesome.

[SaschaFranck]

Helix Floor as an audio interface causes a negative recording offset of 90 samples at 44.1kHz on USB 1/2 or 7/8 (empty preset, but that shouldn't matter). So all recordings will be delayed by around 2ms.

Some (maybe most by now) sequencers allow for a global compensation of such offsets, in case someone cares and wants to look it up.

Should be corrected on a driver level by Line 6, though.

 

[datacommando]

15 hours ago, SaschaFranck said:

Helix Floor as an audio interface causes a negative recording offset of 90 samples at 44.1kHz on USB 1/2 or 7/8 (empty preset, but that shouldn't matter). So all recordings will be delayed by around 2ms.

Some (maybe most by now) sequencers allow for a global compensation of such offsets, in case someone cares and wants to look it up.

Should be corrected on a driver level by Line 6, though.

 

 

Bug?

I really cannot understand why you have bothered to post this supposed “around 2ms delay” as a bug?

What is going on in your head to think that is a bug? 

Not many humans could detect that time discrepancy!

Let me direct you to an article which you may wish to read regarding latency,  and direct monitoring.

 

Note well, the section “As Near Zero As Makes No Difference”.

https://www.soundonsound.com/techniques/living-latency

 

And why you hear your input signals without having to wait for them to be buffered in and out of the computer. “still have to pass through the A-D and D-A converters, which is why this method doesn't give true zero-latency monitoring”

 

What you mention is and instance of “physics” at work - not a bug!

It is not likely to trouble many people, only maybe passing dogs or bats.

Glad you took the time out of your life to discovered this anomaly, although I question the validity of your bug statement. Why should a possible 2ms delay worry a Helix user.

 

You really do do seem determined to find faults with this box of tricks.

 

 

[SaschaFranck]

2 hours ago, datacommando said:

 

Bug?

I really cannot understand why you have bothered to post this supposed “around 2ms delay” as a bug?

What is going on in your head to think that is a bug? 

Not many humans could detect that time discrepancy!

Let me direct you to an article which you may wish to read regarding latency,  and direct monitoring.

 

Very sorry, but you don't seem to understand what this is about. It's a recording offset. Interfaces are supposed to record the stuff coming in and have it placed on the timeline in a sequencer just at the right position. This is all about proper communication of the driver and the recording software and it's got zero to do with latency (which I am absolutely informed about) but with a proper driver implementation. Any decent interface doesn't suffer from this problem. And while most humans won't be able to detect 2ms od delay reliably, it's good enough to cause other issues, such as phasing ones.

Anyway, this is very clearly a bug on the interface side of things. And as said, it's got nothing to do with latency. My other interfaces don't suffer from that issue, regardless of their RTL values or the buffersize settings.

As far as testing this goes: Play any audio file in a sequencer and re-record it. Then compare the two signals on your timeline. Ideally, they would align perfectly, regardless of the samplerate and buffersettings. Which they are, using other interfaces. Which they aren't, using the Helix. Hence it's a bug. One that should defenitely be adressed in case you want to call the interface part of the Helix decent.

[SaschaFranck]

And fwiw, that SOS article is pretty dated and not exactly well written. The guy doesn't even mention the socalled "safety buffers" each and every interface will introduce. These exist to warrant proper functionality and they're usually not documented, plus, apart from a few rare exceptions (I know MotU offers low safety buffer options - which doesn't seem to help their interfaces, but that's another story...), you can't access their settings as a mere user, so they're baked into the interface. And quite often they're responsible for a large percentage of your overall RTL, especially on cheaper interfaces. Which is also why you will get vastly different RTL values from different interfaces, even if you're using the same samplerates and buffersizes. The SOS author is not mentioning this, which is a bit of a shame, as SOS usually is a pretty reliable source.

In case you want some extensive but interesting reading, I recommend this thread:

https://www.gearslutz.com/board/music-computers/618474-audio-interface-low-latency-performance-data-base.html

 

Anyway, it still hasn't got much (if anything) to do with the recording offset the Helix introduces. That's all about proper host-driver-communication.

[jdonah]

On 11/11/2019 at 12:23 PM, jdonah said:

Firmware: 2.7.0 through 2.8.2 (HX Stomp)

Global Settings: default all, Footswitches->stomp select->press

Bug: When Press is selected as the option for “Stomp Select” under Preferences->Global Settings->Footswitch it appears to do nothing in that touch capacitance is still active.  It can be quite frustrating to accidentally trigger the Tap Tempo feature with my hand on FS5 while manually adjusting the HX Stomp.  It would be ideal if touch capacitance could be fully disabled through this setting or a separate setting.  

Any way to disable full touch-capacitance yet?  Also, I am not able to reassign Tap/Tune to other switch locations successfully.  

[phil_m]

18 hours ago, SaschaFranck said:

Helix Floor as an audio interface causes a negative recording offset of 90 samples at 44.1kHz on USB 1/2 or 7/8 (empty preset, but that shouldn't matter). So all recordings will be delayed by around 2ms.

Some (maybe most by now) sequencers allow for a global compensation of such offsets, in case someone cares and wants to look it up.

Should be corrected on a driver level by Line 6, though.

 

 

Are you saying the 2ms latency is compared to the real-time performance? It sounds like you're talking about the latency introduced by the converters themselves. I'm not sure I agree that most interface drivers will automatically compensate for this.

[SaschaFranck]

6 minutes ago, jdonah said:

I'm a bit surprised that this issue isn't taken more seriously considering the commercial success Line 6 has with its products in general.  I suppose we aren't talking professional grade level equipment here or even prosumer, but in the recording world 2ms down the line upon layers of processing and other time dependent events can be amplified quite literally and figuratively exponentially to have very real-world noticeable effects.  

 

Well, as the lack of proper driver communication is known by most host makers these days, quite some of them are offering a global record offset compensation. Once that is done, you're all fine. I'm using Logic and after measuring the Helix offset, I just set the global compensation to -90 samples and that was it. It's just that I have to remember it whenever I switch to another interface not suffering from recording offsets (would be great if the host would remember the settings per interface).

 

In general, it's quite astounding, though, because even some dedicated interfaces are still suffering from that issue - let alone those slapped in as a sort of afterthought. The one in my Zoom G3 comes with a recording offset of a whooping 475 samples.

[SaschaFranck]

21 minutes ago, phil_m said:

 

Are you saying the 2ms latency is compared to the real-time performance? It sounds like you're talking about the latency introduced by the converters themselves. I'm not sure I agree that most interface drivers will automatically compensate for this.

 

As said, this has *zero* to do with device latency, be it from converters, internal processing or whatever. It's about a recording offset - which is an entirely different thing.

One of the most crucial features of an audio interface is to record things in time. For this to work, the driver needs to communicate with the host. And in case, say, the input converter is adding 2ms of latency (arbitrary number, I know it's less on the Helix), the driver needs to tell the host "Hey, please take that into account when placing the file on the timeline". Same goes for any internal processing the Helix is doing before the signal hits the sequencer.

This is what each and every even remotely professional (or semi-professional) interface will do. If you have access to one of these, you can check for yourself by perfoming the dead simple loopback test described above. They're "suffering" from the very same converter and processing latency as the Helix (sure, the exact numbers will vary as they're all designed slightly different) - and yet, recordings will be placed accurately on the timeline. The reason being that the driver is properly communicating with the host (well, on most interfaces at least). It's pretty much exactly the same what I'm now doing with Logics global recording offset compensation, just that it's happening on a driver level, which a) is likely more efficient, b) takes the burden off the user and c) doesn't need re-adjustments when changing samplerates (which is often required with interfaces suffering from that very issue).
 

Fwiw, these very issues are something often ignored in all sorts interface reviews. You may find resumes about how great an interface performs at low latencies, how great it sounds and what not - only to find out it comes with a massive recording offset once its in your hands. Which, btw, isn't necessarily a dealbreaker, as long as the offset isn't varying (something happening as well on rather shoddy interfaces), but it's still something that shouldn't happen. It's a matter of proper QA in the driver development department and should be adressed.

[phil_m]

9 minutes ago, SaschaFranck said:

It's about a recording offset - which is an entirely different thing.

 

This wouldn't be a driver issue, though... This would be DAW specific.

[SaschaFranck]

And fwiw: The global recording offset compensation of some (these days most) sequencers hasn't exactly been added to compensate for offsets introduced by less than shiny interface drivers but because you might be dealing with things the driver of whatever interface can't adress, such as using an external AD converter. The latency introduced by such an external converter is something unknown to the interface, so the only way to find out about it (apart from things being documented by the converter makers) and cure it, is performing a loopback test and adjusting your global offset compensation.

In case of an interface coming with a fixed set of converters, that shouldn't be required.

 

Anyway, I didn't even mean to start a discussion about all this. Just wanted to report this driver bug.

[SaschaFranck]

7 minutes ago, phil_m said:

 

This wouldn't be a driver issue, though... This would be DAW specific.

 

No.

Sorry, I don't want to be a smart a** or anything, but please do yourself a favour and look it up. It's not DAW specific.

It sometimes *is* platform specific (as there's different drivers for different platforms), but it's never DAW specific.

 

Edit: And fwiw, yes, I have done cross-DAW-tests regarding that very issue in the past. Recording offsets are the same throughout.

[phil_m]

18 minutes ago, SaschaFranck said:

 

No.

Sorry, I don't want to be a smart a** or anything, but please do yourself a favour and look it up. It's not DAW specific.

It sometimes *is* platform specific (as there's different drivers for different platforms), but it's never DAW specific.

 

I think I'm getting what you're saying now, and I just tried a quick test in Reaper in my WIndows 10 machine. It looks like the latency is being reported properly in the ASIO driver. I just created a hardware Send in Reaper from one of the USB outs, and the re-recorded track is actually ahead of the original track by about 90 samples. So in this case Reaper is compensating for a conversion that's not actually happening.

 

 

[SaschaFranck]

5 hours ago, phil_m said:

 

I think I'm getting what you're saying now, and I just tried a quick test in Reaper in my WIndows 10 machine. It looks like the latency is being reported properly in the ASIO driver. I just created a hardware Send in Reaper from one of the USB outs, and the re-recorded track is actually ahead of the original track by about 90 samples. So in this case Reaper is compensating for a conversion that's not actually happening.

 

Hm, not sure if I understand what you're doing.

 

Version 1)

You're sending out a signal via USB Outs XYZ (shouldn't matter which) through one of the Helix' sends, then you reconnect it to the Helix' input (guitar input should be sufficient) and record it.

In that case, the Helix should act every bit the same as it would when using one of the main outs. Without anything loaded, everything should function as on any typical multi I/O interface.

 

Version 2)

Or are you entirely bypassing the Helix' hardware and rerouting the USB "stream" internally? You know, the "hardware Send in Reaper" part is a little confusing - I'm not familiar with Reaper, is that a Reaper terminology to integrate additional I/Os or are you refering to the Helix' sends?

Anyhow, in case you were bypassing the Helix' hardware, yet sort of emulating a hardware environment within Reaper by utilizing the additional USB routing options as kinda virtual audio cables, then your assumption might be correct.

 

I am for now assuming that (2) is what you meant.

However, whether the 90 samples in your example (which would match the value I've seen in opposite order) are "proving" that this is a defined value the Helix will have to report to the host regardless of platform is beyond me. It might as well just be coincidental. In case it's not a coincidence, it could of course tell us that the ASIO driver for Windows is in fact reporting the correct values to the host (which would be what you concluded already) so recordings are lined up properly whereas the Core Audio version comes with an offset.

Could you do the same test I did, just re-recording something from the Helix' main out into the guitar in and compare things again? In case these recordings would line up properly, we should've nailed down the culprit, namely the Core Audio driver (which may or may not be of informational value for Line 6).

[PeterHamm]

The idea that this 2ms is "Multiplied" by the other things that are going on in a DAW btw, seems to be complete malarkey to me.

This is not a bug.

 

[SaschaFranck]

38 minutes ago, PeterHamm said:

The idea that this 2ms is "Multiplied" by the other things that are going on in a DAW btw, seems to be complete malarkey to me.

This is not a bug.

 

 

We could argue whether things are multiplied or not. It's nothing I would worry about personally (hence I didn't mention it...), but in case you'd route something out of the Helix and rerecord it along with other things, there's a certain chance of running into issues.

Example: You route a dry signal into a hardware device to do some nice doubling effect (say, an Eventide H series device). When you then re-record the signal (to have it available straight inside your computer), the doubling will be 2ms off compared to the signal you were listening to when creating the effect. In case of a doubling effect, 2ms can pretty much make it or break it in terms of phase relationships. I'm not saying this is a very common thing one could do, but you'll get the idea.

 

Regarding "This is not a bug" - yes, it is. Recording offsets defenitely qualify as bugs (well ok, you may call it lack of QA - but that's not all too different). And in some areas of the recording world, they would even qualify as major bugs and you wouldn't sell a single unit.

 

Edit: Another example. You record a basic track 1. You record another track 2 along with it, using track 1 as a timing reference. You've totally nailed it, in the pocket and all. That track 2 will be off by 2ms compared to track 1 on the recording. You record another track 3 along with it, this time using track 2 as a timing reference. Totally naiing it, etc. Recorded track 3 will be off by 2ms compared to track 2 - and it will be off by 4ms compared to track 1. You get the idea.

Does that happen every day? No way. Most often we may use a metronome or the tracks recorded first as our timing reference. But then, I'm just illustrating certain possible scenarios.

[SaschaFranck]

Just to make this clear again: I didn't mean to make a big fuzz about the offset issue. It's just something that should be adressed at some point in time - and from all I know, these things can be adressed more or less easily, perhaps even without affecting anything else in the firmware (fwiw, the Axe FX IIIs interface part suffered from much more noticeable recording offsets when it was released - and I think it's fixed by now). It's as well something that some people would like to be aware of. And yes, it's very unlikely to turn into something that would get in the way of using the Helix as an interface too much, especially as there's ways to compensate for it once you're aware.

[phil_m]

3 hours ago, SaschaFranck said:

 

Hm, not sure if I understand what you're doing.

 

Version 1)

You're sending out a signal via USB Outs XYZ (shouldn't matter which) through one of the Helix' sends, then you reconnect it to the Helix' input (guitar input should be sufficient) and record it.

In that case, the Helix should act every bit the same as it would when using one of the main outs. Without anything loaded, everything should function as on any typical multi I/O interface.

 

Version 2)

Or are you entirely bypassing the Helix' hardware and rerouting the USB "stream" internally? You know, the "hardware Send in Reaper" part is a little confusing - I'm not familiar with Reaper, is that a Reaper terminology to integrate additional I/Os or are you refering to the Helix' sends?

Anyhow, in case you were bypassing the Helix' hardware, yet sort of emulating a hardware environment within Reaper by utilizing the additional USB routing options as kinda virtual audio cables, then your assumption might be correct.

 

I am for now assuming that (2) is what you meant.

However, whether the 90 samples in your example (which would match the value I've seen in opposite order) are "proving" that this is a defined value the Helix will have to report to the host regardless of platform is beyond me. It might as well just be coincidental. In case it's not a coincidence, it could of course tell us that the ASIO driver for Windows is in fact reporting the correct values to the host (which would be what you concluded already) so recordings are lined up properly whereas the Core Audio version comes with an offset.

Could you do the same test I did, just re-recording something from the Helix' main out into the guitar in and compare things again? In case these recordings would line up properly, we should've nailed down the culprit, namely the Core Audio driver (which may or may not be of informational value for Line 6).

 

Here's what it looks like using a 1/4" as the output and running that back in through a Return. It looks like it's perfectly aligned to me.

 

[silverhead]

Just as a reference, in 2ms sound travels 2.24 ft through the air under normal conditions. So if you're standing farther away than that from your amp/speakers you are experiencing a longer lag/latency.

[SaschaFranck]

54 minutes ago, phil_m said:

 

Here's what it looks like using a 1/4" as the output and running that back in through a Return. It looks like it's perfectly aligned to me.

 

Thanks - and yes, that's looking quite perfect. So it's a macOS/CoreAudio only issue as it seems. Nothing too surprising, I already had it the other way around as well.

 

56 minutes ago, silverhead said:

Just as a reference, in 2ms sound travels 2.24 ft through the air under normal conditions. So if you're standing farther away than that from your amp/speakers you are experiencing a longer lag/latency.

 

As said before, the entire issue hasn't got anything to do with latency (even if there's some overlapping elements that also relate to latency).

 

Fwiw, we could happily discuss the various implementations of latency, the somewhat astounding aspects, side effects and possible workarounds for it one day. It's a topic I am very interested in since almost 2 decades already, I also performed certain quite interesting tests, the results sometimes being different from what I've expected. Might not be the appropriate place for such discussions, though.

[PeterHamm]

4 hours ago, silverhead said:

Just as a reference, in 2ms sound travels 2.24 ft through the air under normal conditions. So if you're standing farther away than that from your amp/speakers you are experiencing a longer lag/latency.

 

In defense of those who are complaining about this. set up stereo speakers with one speaker 2.24ft further away than the other... it will sound odd.

 

Yes, such an offset can indeed be an issue.

I still don't think this is a bug per se.

[SaschaFranck]

32 minutes ago, PeterHamm said:

I still don't think this is a bug per se.

 

Well, everywhere else in the recording world, record offsets are considered a pretty bad thing, especially as they usually come along with drivers that aren't taken care of too well.

[datacommando]

On 11/30/2019 at 12:22 PM, SaschaFranck said:

Just to make this clear again: I didn't mean to make a big fuzz about the offset issue.

 

O.K. you didn’t mean to make a fuss about the offset issue - so why bother to post to the forum that this is a “bug”? Weird!

 

On 11/30/2019 at 12:22 PM, SaschaFranck said:

And yes, it's very unlikely to turn into something that would get in the way of using the Helix as an interface too much, especially as there's ways to compensate for it once you're aware.

 

Again, why state this is a “bug” when in everyday use 2ms is negligible. I have been using Helix as an interface for 4 years and never had problem with this “bug”, and I don’t recall anyone else posting to say this is a major fault in the Helix.

 

As the old saying goes - “it’s close enough for rock ‘n’ roll” or “near enough for jazz”.

 

Not wanting to make a fuss - yeah - that didn’t work out too well.

[SaschaFranck]

6 hours ago, datacommando said:

 

O.K. you didn’t mean to make a fuss about the offset issue - so why bother to post to the forum that this is a “bug”? Weird!

 

Again, why state this is a “bug” when in everyday use 2ms is negligible. I have been using Helix as an interface for 4 years and never had problem with this “bug”, and I don’t recall anyone else posting to say this is a major fault in the Helix.

 

As the old saying goes - “it’s close enough for rock ‘n’ roll” or “near enough for jazz”.

 

Not wanting to make a fuss - yeah - that didn’t work out too well.

 

1) It is a bug. As easy as that. No way around it. Whether it affects you or anyone else is completely irrelevant. The audio interface part of the Helix isn't working accurately under macOS. That's a bug. Period.

2) There's zero room for "close enough to rock'n'roll". Apparently you don't seem to fully understand the concept of digital audio. If you were a math teacher and someone would resolve 1+1 to 2.0000000001, would you say "yeah, cool, close enough for rock'n'roll"? And when would you say it's not close enough for rock'n'roll anymore? At 3ms? Or at 5? Or at 10? In other words, you would base the decision on whether something is a bug or not on subjective perception?

3) I have posted examples how this bug could become an issue. Again, whether it's an issue for you is completely irrelevant.

4) I did not make a fuss. I reported a bug, plain and simple. It was you alone who started all the fuss about it.