Jump to content
HonestOpinion

Helix Bug Reports

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

 

image.thumb.png.4d78215d5dd654c456fb9ac2edec8638.png

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites

And to bring this to an end, here's an MP3. A duplicated (not doubletracked) guitar track. Original recording and a re-amped version playing simultaneously. 2 bars aligned and 2 bars with 2ms offset for the reamped version (which is the offset you'd get when reamping through a physical amp with the Helix under macOS).

Tight vs. phasey mud.

In case that doesn't bother you and you still fail to see the reason why recordings should be lined up properly (even if 2ms aren't noticeable in the timing realm for most humans, which I never even argued with), well, more power to you. Or maybe you're just saying the Helix shouldn't be used for reamping purposes. I must have misunderstood some of the Line 6 marketing then.

2ms.mp3

Share this post


Link to post
Share on other sites
7 hours ago, SaschaFranck said:

And to bring this to an end, here's an MP3. A duplicated (not doubletracked) guitar track. Original recording and a re-amped version playing simultaneously. 2 bars aligned and 2 bars with 2ms offset for the reamped version (which is the offset you'd get when reamping through a physical amp with the Helix under macOS).

Tight vs. phasey mud.

In case that doesn't bother you and you still fail to see the reason why recordings should be lined up properly (even if 2ms aren't noticeable in the timing realm for most humans, which I never even argued with), well, more power to you. Or maybe you're just saying the Helix shouldn't be used for reamping purposes. I must have misunderstood some of the Line 6 marketing then.

2ms.mp3

 

Just to be clear, are you using the downloaded Mac drivers or the Core Audio driver?

Share this post


Link to post
Share on other sites
41 minutes ago, phil_m said:

 

Just to be clear, are you using the downloaded Mac drivers or the Core Audio driver?

The downloaded ones. Otherwise HX Edit wouldn't even work.

 

Fwiw, too bad, because 2.7/2.8 broke class compliance under OSX, so I can't use the Helix with my old MacBook.

Share this post


Link to post
Share on other sites

Having corrupted presets here. Using Helix Edit 2.82 and matching firmware form my helix floor. I had some presets be corrupted. Names all weird. I can't do anything with them. So I exported the setlist and tried to re-import it. It seemed to import fine but then bigger blocks of presets are now corrupted.  I am going to try to do  global reset but I am afraid my saved presets might be corrupted as well.  

 

Now when I load a setlist it stops with my Helix and the Helix screen goes blank. I have to restart it and it rebuilds presets.1418198790_HelixCorruptPresets.thumb.png.0f6d91c84aa7872d6f732544793c6569.png

 

I have noticed others in the forum with similar issues. Has Line 6 had a trouble/bug report logged for something like this?

 

 

 

 

Helix Corrupt Presets.png

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, reginaldStjohn said:

I have noticed others in the forum with similar issues. Has Line 6 had a trouble/bug report logged for something like this?

 

I think corrupted presets and setlists are on Line 6s agenda. Or well, let me put it that way: If they weren't, it'd be just horrible. IMO the corrupted preset/setlist issue (which is absolutely wellknown) is by far the most horrible thing in Helix land. I can safely say that in case this doesn't get fixed and happens more than just 1-2 times over the next months or so, I will go for another modeler. If anything, I need my tools to work reliably. And as many people are saying the Helix is a computer, so you should expect the same things as from a computer - well, yes please. My computer never corrupts files out of the blue.

 

 

 

 

Share this post


Link to post
Share on other sites

Bonjour la communauté
, Désolé pour mon anglais aproximatif. Je suis Français. J'expose ici, un problème, désormais récurrent, malgré les nombreux Maj, que j'ai toujours fait scrupuleusement, et que j'ai depuis un certain temps pour ne pas dire un certain temps, avec "les offres de configurations midi" en hélice. .... J'ai un plancher hélicoïdal et j'essaye de contrôler quelques fonctions basiques midi d'un microkorg xl + via l'hélice. Procédure. 1-Par preset, je lance un changement de programme (switch instantané PC, utilisation de l'onglet du bas = nombre simple x) + 2 ou 3 notes midi avec le switch 8/9 + CC (CC6 on / off l'arpégiateur et CC 64 Old fonction) avec le switch 10/11 tout ça vers le korg .. (je pense avoir compris le fonctionnement du comand center .. affectation midi pour preset ou snapshot ...) 2- Problème: l'affection du contrôleur ON / OFF de l'arpégiateur Korg (commande midi CC6) à un comportement erratique et plus aléatoire 'EX: Il faut une fois le preset chargé du Korg via l'hélice, actionner manuellement le bouton de l'arpégiateur (korg) donc que la "connexion-reconnaissance" avec le commutateur dédié, CC6 de l'hélice, (malgré la sauvegarde du preset avec l'arpégiateur ON sur le Korg). Ça ne marche plus pour l'usage ... BOGUE sur Bug pas de stabilité .... Désolé .. mais ça fait ... Plus que dingue ..., un autre résultat fatal de ce comportement, les notes, avec la mauvaise fonction du cc6, restent bloqués .... De plus, le commutateur Notes affecté s'allumera momentanément ou pas du tout. Je suis en quart de travail 2.82. J'ai également réinitialisé l'hélice via les commutateurs 9 et 10, rien n'a changé. ... Finalement, J'ai tenu et j'ai pris le risque de faire un concert hier avec une telle configuration. ..C'était dire. ... Les mots me manquent pour écrire mes ennuis ...;) ... Merci d'avance, pour tout partage d'expériences midi helix et toute aide ..

Share this post


Link to post
Share on other sites

I'm using Helix Floor on 2.82. I'm in stomp box mode and every few times I change patches some of the patch names will remain replacing the stomp box names. Any tips? 

Share this post


Link to post
Share on other sites
On 12/9/2019 at 3:11 AM, AppleTreeChen said:

Why does this happen?

 

That looks to me like some sort of glitch.

 

I would suggest that you make sure that you have a backup of all your presets etc., them perform a reset on your hardware to see if the glitch is cleared. If a reset doesn’t work, then your other option is to raise a ticket with Line 6 support.

 

It also helps to know what firmware revision you are using and if this is only a problem with the hardware or is the HX Edit display also screwed up?

 

Backup and then try a reset x these are your options:

 

HX Stomp

Button Combination

Description

All 3 Footswitches

Clears all presets/IRs

FS1+2

Resets presets and IRs

FS 2+3

Factory restore (globals, presets, IRs)

 

 

 

 

Share this post


Link to post
Share on other sites

Firmware: Firmware 2.82
Bug: When I edit some preset/snapshot settings the main control knob stops responsing to press after some (not always the same) time. It starts working again after I save the preset/snapshot.

Note: If this is the intention, it would be nice to show it to user on display like "You have to save, before continue." 

  • Like 1

Share this post


Link to post
Share on other sites
On 2019/12/10 at PM11点26分, datacommando said:

 

在我看来,这有点像小故障。

 

我建议您确保已备份所有预设等,它们会在您的硬件上执行重置,以查看是否清除了故障。如果重设不起作用,那么您的另一选择是在第6行支持下加票。

 

它还有助于了解您正在使用的固件版本,以及这仅仅是硬件问题还是HX Edit显示屏也被拧紧了?

 

备份然后尝试重设x这些是您的选择:

 

HX践踏

按钮组合

描述

所有3个脚踏开关

清除所有预设/ IR

FS1 + 2

重置预设和IR

FS 2 + 3

恢复出厂设置(全局,预设,IR)

 

 

 

 

Thanks, the 2.82 firmware has been reinstalled and everything is ok now

  • Thanks 1

Share this post


Link to post
Share on other sites
On 12/12/2019 at 8:56 AM, AppleTreeChen said:

Thanks, the 2.82 firmware has been reinstalled and everything is ok now

Very depressed. Despite resetting the firmware, the same failure occurred again and again

微信图片_20191216112636.jpg

微信图片_20191216112628.jpg

Share this post


Link to post
Share on other sites

I experienced a bug with my Helix at my latest gig Friday night - My foot switches are all in snapshot mode and when I changed from one preset to another the switches kept the snapshot names of the previous preset, although the name of the preset changed to the new one on the screen.

Share this post


Link to post
Share on other sites
On 12/16/2019 at 4:35 AM, AppleTreeChen said:

Very depressed. Despite resetting the firmware, the same failure occurred again and again

 

Because this is still happening after reinstalling the firmware it may indicate there is a hardware issue. Contact Line 6 Customer Support and raise a ticket. If it is quite new it may be possible to return it to the store you bought it from and have them swap it for a new one that works correctly.

 

Sorry, you are unhappy about the situation, but occasionally things go wrong.

Share this post


Link to post
Share on other sites
On 12/16/2019 at 4:36 AM, tochiro said:

I experienced a bug with my Helix at my latest gig Friday night - My foot switches are all in snapshot mode and when I changed from one preset to another the switches kept the snapshot names of the previous preset, although the name of the preset changed to the new one on the screen.

 

Did you figure out any solution to this? I'm hoping mine doesn't do this during a gig. I've been experiencing the same thing. 

Share this post


Link to post
Share on other sites

 

On 11/29/2019 at 10:04 AM, 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.

 

 

On 11/30/2019 at 11:49 AM, SaschaFranck said:

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

 

I am experiencing a recording offset with Logic Pro X, too. I am sending a DI track (sine wave, in this case) to USB 3/4 of the Helix and record USB 1/2 to a new audio track (empty preset). This is the re-amplification method according to the Helix manual. As you can see in the screenshot, there is a negative offset in the re-amped track. Through adjusting the Logic recording offset settings in the audio preferences by trial and error, I determined the offset to be -28 samples.

Helix Re-Amping Offset.png

  • Like 1

Share this post


Link to post
Share on other sites
On 12/16/2019 at 6:36 AM, tochiro said:

I experienced a bug with my Helix at my latest gig Friday night - My foot switches are all in snapshot mode and when I changed from one preset to another the switches kept the snapshot names of the previous preset, although the name of the preset changed to the new one on the screen.

 

10 hours ago, MatthewMcGhee said:

 

Did you figure out any solution to this? I'm hoping mine doesn't do this during a gig. I've been experiencing the same thing. 

 

Fwiw, I had a freakout issue with switches going a little haywire during last gig.  I have my Helix Floor setup to run in snapshot mode (8 buttons) and Bank up/down.  What I did was switch the global settings to up/down buttons = presets so I could just advance through my presets by song according to set list.  For whatever reason it was not advancing correctly so I switched back to bank up/down mode and every time I would tap on the bank switches it would go to the last bank no matter which bank I was currently on.  In addition to that, the mode button (#6, top row counting from left to right), was dead.  i.e., I could not toggle between stomp and snapshot mode.  Fortunately for me, the particular gig only required me to hit snapshots which I've programmed extensively.  The latter problem of the mode switch (#6) wasn't revealed until I fired the unit up at home to troubleshoot and try to get it configured correctly.

 

Where I'm at now with this issue is I backed everything up and did a reset (the button 5 & 6 one) and that got all the switching back to normal and the mode button is working again.

 

Next I went ahead and updated HX Edit and my Helix Floor from 2.81 to 2.82.

 

I've got some Christmas gigs, BIG ones starting tomorrow and then a couple worship services on Christmas Eve so I'm spending some quality time running it through the paces to make sure it is working properly.  At last gig where the button chaos happened I'm just really glad I wasn't in a situation where I had to go to stomp mode.  Love this thing and when it's working right it is truly amazing but when stuff like this happens it can be a disaster.

Share this post


Link to post
Share on other sites
On 12/22/2019 at 10:42 AM, Chris-7777 said:

I am experiencing a recording offset with Logic Pro X, too. I am sending a DI track (sine wave, in this case) to USB 3/4 of the Helix and record USB 1/2 to a new audio track (empty preset). This is the re-amplification method according to the Helix manual. As you can see in the screenshot, there is a negative offset in the re-amped track. Through adjusting the Logic recording offset settings in the audio preferences by trial and error, I determined the offset to be -28 samples.

 

I stand corrected. I did more tests, and the recording offset seems to be bigger. I also noticed that in the MacOS Audio MIDI Setup, the Helix Ins/Outs sample rate is set to 44.1kHz, while in the Helix global settings it is 48kHz. I can not change the sample rate in the MacOS Audio MIDI Setup, but in the Helix Global Settings. I re-amped the sine wave with two different sample rate settings, and that leads to a different recording offset.

 

Helix Ins/Outs Sample Rate 48 kHz (MacOS Audio MIDI Setup: 44.1kHz)843155168_Re-amped48kHz.thumb.png.16434a16e1dd16474db87910a9c3cf9c.png

 

Helix Ins/Outs Sample Rate 44.1 kHz (MacOS Audio MIDI Setup: 44.1kHz)

1397970049_Re-amped44kHz.thumb.png.ab2a3b24476795c1d8d84eeddf58547a.png

 

 

The negative offset is significant in both cases, and in the latter example it causes phase cancellation that is audible, obviously. 

I am on the latest Helix driver (Line 6 Helix Driver 1.0.7), which I downloaded and re-installed two days ago just to be sure.

Share this post


Link to post
Share on other sites
On 12/30/2019 at 9:14 AM, Chris-7777 said:

I also noticed that in the MacOS Audio MIDI Setup, the Helix Ins/Outs sample rate is set to 44.1kHz, while in the Helix global settings it is 48kHz. I can not change the sample rate in the MacOS Audio MIDI Setup, but in the Helix Global Settings.

 

Hi Chris,

 

Try installing the Helix Mac Driver 1.0.7 once again to access the higher sample rates - download it from here:

https://line6.com/software/index.html

 

Here you see can Mac Audio MIDI Setup and Logic ProX have access to the higher rates (the italic numbers in LPX mean that the rate is unavailable) - attached pix.

 

1511163929_OSXAUDIOMIDI.thumb.png.d5bd39f34057a53246820afc98cef0e6.png

 

 

 

 

ProX.thumb.png.e711831050c520b269a6d083bf12e2a8.png

 

 

I know it doesn't help with the "out of phase" thing, but hope it helps in other ways.

 

Share this post


Link to post
Share on other sites

Thank you. I do see these sample rate options in the Audio MIDI Setup, but everytime I tried to set it to something else than 44.1kHZ, it bounced back to 44.1. It did not seem to matter what the sample rate setting in the Helix global settings menu was, btw. What I just noticed is that this happens only when Logic Pro X is running. In any case, as you said, it does not help with the recording offset.

 

64930302_Bildschirmfoto2019-12-31um17_22_02.png.9cf3b640d445d1989a8b635788ec4da8.png

  • Thanks 1

Share this post


Link to post
Share on other sites
On 12/30/2019 at 3:14 AM, Chris-7777 said:

 

I stand corrected. I did more tests, and the recording offset seems to be bigger. I also noticed that in the MacOS Audio MIDI Setup, the Helix Ins/Outs sample rate is set to 44.1kHz, while in the Helix global settings it is 48kHz. I can not change the sample rate in the MacOS Audio MIDI Setup, but in the Helix Global Settings. I re-amped the sine wave with two different sample rate settings, and that leads to a different recording offset.

 

Helix Ins/Outs Sample Rate 48 kHz (MacOS Audio MIDI Setup: 44.1kHz)843155168_Re-amped48kHz.thumb.png.16434a16e1dd16474db87910a9c3cf9c.png

 

Helix Ins/Outs Sample Rate 44.1 kHz (MacOS Audio MIDI Setup: 44.1kHz)

1397970049_Re-amped44kHz.thumb.png.ab2a3b24476795c1d8d84eeddf58547a.png

 

 

The negative offset is significant in both cases, and in the latter example it causes phase cancellation that is audible, obviously. 

I am on the latest Helix driver (Line 6 Helix Driver 1.0.7), which I downloaded and re-installed two days ago just to be sure.

 

I'm wondering if this isn't so much a bug but rather just a side-effect of doing this sort of re-amping completely in the digital realm. I just tried this in Reaper on Windows 10, and I get a slight negative offset for the re-amped track as well. I think what's happening is that the driver is telling the DAW to compensate for latency from the converters, but in this case the converters aren't coming into play since the input for the preset is coming over USB. I don't know that there would be anything in the driver that would be able to tell the DAW what input the Helix is actually using for any given preset, so it may just be something that you have to correct manually by sliding the track over.

Share this post


Link to post
Share on other sites
On 12/8/2019 at 3:49 PM, MatthewMcGhee said:

I'm using Helix Floor on 2.82. I'm in stomp box mode and every few times I change patches some of the patch names will remain replacing the stomp box names. Any tips? 


I did a full reset and restore from backup. All was fine for a week or so but it happened again. Must be something with the firmware. The word “Cancel” comes on the upper right switch and if you hit it it usually corrects this issue. I hope they address it. Not fun to be on stage and have this happen. 

Share this post


Link to post
Share on other sites
14 hours ago, phil_m said:

 

I'm wondering if this isn't so much a bug but rather just a side-effect of doing this sort of re-amping completely in the digital realm. I just tried this in Reaper on Windows 10, and I get a slight negative offset for the re-amped track as well. I think what's happening is that the driver is telling the DAW to compensate for latency from the converters, but in this case the converters aren't coming into play since the input for the preset is coming over USB. I don't know that there would be anything in the driver that would be able to tell the DAW what input the Helix is actually using for any given preset, so it may just be something that you have to correct manually by sliding the track over.

 

Good point and great advice, Phil. It is also good to know that this occurs in another DAW, too. I am still puzzled because the Helix sample rate settings do seem to affect the recording offset. It might also be that I am not experienced enough to know that there always will be an offset and that I have to adjust re-amped tracks accordingly. If this can't be solved through improving the drivers, a hint in the Helix manual would be tremendously helpful.

Share this post


Link to post
Share on other sites

under global settings in my Helix, 2.82.0, i have    MIDI PC Recieve     turned off, yet, when i switch guitar sounds on my variax, helix sends those patch changes out to my computer, this needs to work correctly please., 

Share this post


Link to post
Share on other sites
33 minutes ago, pinetrax said:

under global settings in my Helix, 2.82.0, i have    MIDI PC Recieve     turned off, yet, when i switch guitar sounds on my variax, helix sends those patch changes out to my computer, this needs to work correctly please., 

 

Set MIDI Over USB to Off in Global Settings.

Share this post


Link to post
Share on other sites
On 12/7/2019 at 5:29 PM, reginaldStjohn said:

Having corrupted presets here. Using Helix Edit 2.82 and matching firmware form my helix floor. I had some presets be corrupted. Names all weird. I can't do anything with them. So I exported the setlist and tried to re-import it. It seemed to import fine but then bigger blocks of presets are now corrupted.  I am going to try to do  global reset but I am afraid my saved presets might be corrupted as well.  

 

Now when I load a setlist it stops with my Helix and the Helix screen goes blank. I have to restart it and it rebuilds presets.1418198790_HelixCorruptPresets.thumb.png.0f6d91c84aa7872d6f732544793c6569.png

 

I have noticed others in the forum with similar issues. Has Line 6 had a trouble/bug report logged for something like this?

 

 

 

 

Helix Corrupt Presets.png

 

Brand new Helix.  2.82 and I am experiencing this exact same issue.  

  • Like 1

Share this post


Link to post
Share on other sites
On January 2, 2020 at 11:54 AM, phil_m said:

 

Set MIDI Over USB to Off in Global Settings.

no, i use usb to send patch changes from helix, as well as continuios controllers, i was able to filter the patch changes Variax sends out in my program, but this still needs to work as advertised.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...