Jump to content

pipelineaudio1

Members
  • Content Count

    144
  • Joined

  • Last visited

  • Days Won

    1

pipelineaudio1 last won the day on May 15 2018

pipelineaudio1 had the most liked content!

Community Reputation

14 Neutral

About pipelineaudio1

  • Rank
    Iknowathingortwo

Profile Information

  • Registered Products
    1

Recent Profile Visitors

631 profile views
  1. https://line6.ideascale.com/a/dtd/On-off-option-for-wah-auto-engage-to-fix-snapshot-bug/1026321-23508 On/off option for wah auto engage to fix snapshot bug It is very hard for me to put this title into short but catchy words so if anyone has a better title, let me know and I'll edit it. The problem: Using an expression pedal to "auto bypass" say a wah results in a bypass toggle rather than actually specifying bypassed or enabled. This causes the wah to often be in the wrong state and turn off when it should turn on in snapshot situations, as documented in many threads such as: https://line6.com/support/topic/47968-auto-engage-and-snapshots/ From page 50 in the Helix manual "For example, moving EXP 1 forward past the heel down position can enable a Wah or Poly Wham block, and returning EXP 1 to the heel position will bypass it again" This is not actually true. When using this method, the Position parameter actually determines the toggle point. Whatever state the wah is currently in, going past Position will toggle it. Example problem case: Lets say you have enabled your wah and the wah is on and everything is working fine. You are done with your wah movements and lift your foot off with the pedal halfway thru its travel, but above the Postion value You now switch to a new snapshot where you specify the wah being bypassed. The wah is in fact bypassed and all is fine, until; You decide you need the wah on so you move it forward. Since it has not crossed Position, it stays bypassed Well, OK, you just rock it back to heel down passing thru Position Oops! Now the Wah is ON on heel down, but moving it back towards toe down bypasses the wah once you pass Position Suggested (but not really working) workarounds: Put the expression pedal in per preset mode. Same problem, the bypassed/enabled state can still flip the wrong way (and can happen in presets as well as snapshots!) Put the expression pedal in global mode (snapshots will no longer bypass the wah, though you could set the mix to 0% for snapshots where you KNOW you'll never want a wah) What DOES work (with caveats, and silly to need to do) which hopefully Line6 can implement in the EXP Bypass method: According to the manual on page 51 "Incoming CC values 0-63 turn the block off; values 64-127 turn the block on" Unlike auto-engage with the EXP pedals, this is not a toggle. So as silly as this sounds, plugging the MIDI out of the Helix back into the MIDI in of the helix can work far more closely to the intended behavior! The video at this link shows proof that MIDI controls the bypass state as claimed: https://www.dropbox.com/s/vr4ihix5usjy0zc/2021-07-25%2012-07-12.mp4?dl=0 I was wrong about the stretching, so ignore it when I say that in the video, as I learned a bit later. This next video shows the wah working with wherever you set the MIDI value so you can pretty well emulate the Position parameter that you attempted to use with the EXP pedal: https://www.dropbox.com/s/750xhpkcifzcd19/2021-07-25%2012-25-58.mp4?dl=0 Desired Behavior: Have at least the option to change the EXP pedal bypass method to On/OFF rather than toggle, like MIDI control of bypass can do. ( I can see use cases where toggle would be the desirable behavior, so it would nice to chose) Still able to have the wait time as it is now An option to turn the wah on by moving it even if it is currently past the Position value, and of course turn if back off once it goes under Be sure that this works as predicted with snapshots, especially if that snapshot is meant to start with the wah bypassed Of course all this applies to other FX such as the whammy and others that would be nice to auto engage
  2. Line6 support got back to me, and like we had thought, there seemed to be more than one user who never did get this thing to work with the same issues, it wasn't a bug that got fixed a ways back, its an ongoing problem.
  3. Please upvote this ideascale https://line6.ideascale.com/a/dtd/On-off-option-for-wah-auto-engage-to-fix-snapshot-bug/1026321-23508
  4. PLEASE upvote this Helix bugfix at ideascale: https://line6.ideascale.com/a/dtd/On-off-option-for-wah-auto-engage-to-fix-snapshot-bug/1026321-23508 On/off option for wah auto engage to fix snapshot bug It is very hard for me to put this title into short but catchy words so if anyone has a better title, let me know and I'll edit it. The problem: Using an expression pedal to "auto bypass" say a wah results in a bypass toggle rather than actually specifying bypassed or enabled. This causes the wah to often be in the wrong state and turn off when it should turn on in snapshot situations, as documented in many threads such as: https://line6.com/support/topic/47968-auto-engage-and-snapshots/ From page 50 in the Helix manual "For example, moving EXP 1 forward past the heel down position can enable a Wah or Poly Wham block, and returning EXP 1 to the heel position will bypass it again" This is not actually true. When using this method, the Position parameter actually determines the toggle point. Whatever state the wah is currently in, going past Position will toggle it. Example problem case: 1. Lets say you have enabled your wah and the wah is on and everything is working fine. 2. You are done with your wah movements and lift your foot off with the pedal halfway thru its travel, but above the Postion value 3. You now switch to a new snapshot where you specify the wah being bypassed. The wah is in fact bypassed and all is fine, until; 4. You decide you need the wah on so you move it forward. 5. Since it has not crossed Position, it stays bypassed. Well, OK, you just rock it back to heel down passing thru Position. Oops! Now the Wah is ON on heel down, but moving it back towards toe down bypasses the wah once you pass Position! Suggested (but not really working) workarounds: 1. Put the expression pedal in per preset mode. Same problem, the bypassed/enabled state can still flip the wrong way (and can happen in presets as well as snapshots!) 2. Put the expression pedal in global mode (snapshots will no longer bypass the wah, though you could set the mix to 0% for snapshots where you KNOW you'll never want a wah) What DOES work (with caveats, and silly to need to do) which hopefully Line6 can implement in the EXP Bypass method: According to the manual on page 51 "Incoming CC values 0-63 turn the block off; values 64-127 turn the block on" Unlike auto-engage with the EXP pedals, this is not a toggle. So as silly as this sounds, plugging the MIDI out of the Helix back into the MIDI in of the helix can work far more closely to the intended behavior! The video at this link shows proof that MIDI controls the bypass state as claimed: https://www.dropbox.com/s/vr4ihix5usjy0zc/2021-07-25 12-07-12.mp4?dl=0 (I was wrong about the stretching, so ignore it when I say that in the video, as I learned a bit later.) This next video shows the wah working with wherever you set the MIDI value so you can pretty well emulate the Position parameter that you attempted to use with the EXP pedal: https://www.dropbox.com/s/750xhpkcifzcd19/2021-07-25 12-25-58.mp4?dl=0 Desired Behavior: 1. Have at least the option to change the EXP pedal bypass method to On/OFF rather than toggle, like MIDI control of bypass can do. ( I can see use cases where toggle would be the desirable behavior, so it would nice to chose) 2. Still able to have the wait time as it is now 3. An option to turn the wah on by moving it even if it is currently past the Position value, and of course turn if back off once it goes under 4. Be sure that this works as predicted with snapshots, especially if that snapshot is meant to start with the wah bypassed Of course all this applies to other FX such as the whammy and others that would be nice to auto engage Please share this!
  5. I really appreciate the deep dive you are looking for in my case very much! I don't think that was ever in contention Because the behavior of this issue is so close to these others, I'm not so sure. It is in fact identical to the problem described previously. It could have a different cause, but it is exactly as they described in other threads here and on reddit. I've done this a few times, as well as cleared out anything Line6 including from the registry as much as I could find anything. Programdata, appdata, etc as well. Mine isn't crashing, its giving the same screen as shown here and in the earlier threads by others with the same sort of problem. Also all the vst3 files were deleted from common files and I hadn't installed vst2 only vst3 and aax (aax was manually confirmed deleted after the uninstall as well) Regarding the earlier complaints, for the most part, there didn't seem to be a resolution. Some people were able to get it running by doing some rather insane things to their SSD drives, but I don't see where it was truly ever resolved. Was it a bugfix in a later version that allowed them to run normally or did they end up giving up and getting refunds? I'm not sure what the end was.
  6. Is there any way to save presets without prompts? Just a regular quicksave or update type function?
  7. This particular computer was able to run helix native v1 but it doesn’t have the same phone home feature as v3. I installed v1 by mistake. it has never successfully run v3
  8. All of the computers are windows 10. Helix native runs fine on the two that for some reason line6 is identifying as windows 8. the computer being identified as windows 10 is the one having the problem that the screenshot shows. The yidentical problem to the other threads on this forum where it often turned out to be a bug helix native has with some ssd systems that aren’t listed as drive 0. In my case all three computers show the drive helix native is installed in in drive 0. this is confirmed in reaper, protocols, Cubase and nuendo. Same issue.
  9. OK, so here is a pretty good workaround until Line 6 fixes it. Set the MIDI CC transmit to a minimum of like 60 https://www.dropbox.com/s/750xhpkcifzcd19/2021-07-25 12-25-58.mp4?dl=0
  10. I made a video today, trying to fix this issue by doing MIDI loopback. It definitely observes the correct polarity under MIDI, so hopefully Line6 can get this as an option with the auto engage function. Please see the video for details: https://www.dropbox.com/s/vr4ihix5usjy0zc/2021-07-25 12-07-12.mp4?dl=0
  11. Strangely its the one that says "windows 10" that's giving me the grief.
  12. I'm not sure what else to say. Its identical to the problem they were having earlier in the 2.81 build. It shows me as authorized both in the plugin and website but just has a helix background with none of the GUI elements.
  13. Hey thanks theElevators, I'll see if your trick works out for me! This is actually a pretty common bugaboo that a lot of software developers mess up. Pretty sure Positive grid makes it all toggle on purpose as its more like a live pedalboard, but its a PITA. The way the manual reads, allegedly if MIDI controls the wah on/off, its actually on/off, not a toggle so it might actually work. I'm going to go pick up a MIDI cable today from guitarcenter to try that. There's also a chance the CV out to a EXP in could fix this as well. We actually created an Auto Engage plugin a few years ago as a workaround for people who's plugins messed this up. Hoping line 6 fixes this, or gives it as an option (lots of good reasons for it to be toggle instead as well, its not always a bug)
  14. I'm having this exact problem. The auto engage is a toggle not an "on above this value and off below this value" Same issue as the Positive Grid stuff has
×
×
  • Create New...