HonestOpinion

Definitely not just you. I have had the Helix since last year and although I make this error rarely now I still don't like how fiddly the knob is and the feeling of dread and surplus of caution that accompany its use. There is more than one idea on Ideascale on how to address the issue, you can find them by clicking on the Helix ideas and then doing a search on "Joystick". I like some of the suggested remedies better than my own and they all seem to have merit: Here is mine, but hey, vote for them all, why not: http://line6.ideascale.com/a/dtd/Make-joystick-require-larger-turn-before-effect-changes/788248-23508

I also intend to exercise patience and recognize that working on stability and bug fixes will largely precede enhancements. With that said, the two somewhat conflicting priorities can be dual tracked to some extent, and I am sure that is what they are doing. One also can't forget the ever present tension which I have mentioned on the forum previously between Line6's particularly broad, innovative, and aggressive product release schedule and the perhaps resultant shortened maintenance and enhancement window for the current product line. If things take too long, significant pressure may develop within the company to simply move on to the latest new devices despite their commitment to the Helix right now.

One strategy I have used for finding the frequencies where the pick noise is most egregious, particularly with my acoustic guitar, is to use the old trick with a parametric equalizer -- set the Q on the parametric fairly narrow and the db boost high and then sweep the frequency range until you find the spot(s) where the noise is worst. You can also use it in the opposite fashion by a substantial cut to the db level and sweeping until the noise diminishes. You can then dial some of those frequencies down with the PEQ or a GEQ. One more tip, you can sometimes get a good idea of where the offending frequencies lie by first using a low pass filter (high cut) and sweeping the entire frequency range until the sound disappears. Then drill down to specifics with the parametric EQ.

Great write-up and I wholly agree with the bulk of it! I hesitate to even comment further because as I stated initially I am fairly confident that there is great stuff coming and don't have any desire to belabor this point. But anyway, here goes. Absolutely true, and an important qualification of my original statement. Not aggravating customers by piecemealing out constant bugfixes is unarguably a good general guideline but when you have a major bug like tap tempo failing or total system lockups, particularly when the Editor is not involved meaning it can happen live, then a quick fix can be just the ticket as the bug is already more "aggravating" to your customers than the fix will be. I have found that the process of bug releases can be very different from the initial product release. I do agree heartily that one important objective is not to introduce a new bug into the system in the process. That is essentially what has happened however already with the new firmware releases. To some extent it is inevitable in a system this complex and I am not trying to find fault with L6. However, the timeliness with which it is addressed can be somewhat dependent on the depth and complexity of the bug. Some bugs are just the product of a very simple mistake or are located in a module or area of the code that is isolated and highly unlikely to reintroduce a new bug. These simple or isolated bugs can change the risk/benefit equation, only take a few minutes to fix, and be eminently worthy of pushing out quickly. Additionally, if you have a well constructed and comprehensive automated test harness, sometimes you can do a fairly extensive retest and QA of your code in short order. I guess what I am trying to say is that in my experience, there are a number of variables that drive how quickly a fix can and should be released, dependent on the bug's severity, complexity, and the amount of risk involved, as well as the sophistication and automation of the test process. A large system of code can be somewhat like a piece of art. The developer(s) like the artist rarely or never truly feels it is finished or flawless. At some point though you have to fix the major issues as quickly as possible, add the enhancements that resources and ROI allow, and just get on with it. At some point you have to deliver. I do agree though that it is critical to strike a balance between the pace of development and the stability of the product and you should not allow pressure from the users to drive you to deliver an inferior product.

Are you a writer or professional comedian? I don't always agree with you although I do in this case. Your posts have to be some of the funniest on the forum when you are not savaging some hapless soul (and sometimes even then). I dread ever being the target of your rapier wit but definitely find myself chuckling on a regular basis at your posts. Most entertaining! If you write songs I would love to see some of your lyrics!

I never play a gig without a backup, that is why I always carry some sort of redundant gear that I can get a sound I can live with in the event of equipment failure. It also explains why I took up tap, beat-boxing, interpretive dance, and can mime in five different languages. :D

Agree with most of what you are saying phil_m, and it definitely does take some time to ramp up new developers. That's why I say "Buy a Helix, employ a developer!", the more and better the merrier. L6 certainly does support an impressive array of products which is why I believe all those developers should be immediately reassigned to working only on the Helix (just kidding). New Line6 promotional "Groupon". Every group of 100 Helix purchasers gets their own personal developer assigned to them. :D

Love me those colored lights. Forget anything else, if only the Helix had muave and taupe LED's they could forego all other development efforts. ;)

A humorous but perhaps not wholly apt metaphor. This is not nature, last time I checked Helix was man-made despite that umbilical cord to my guitar(although there is a school of thought that argues that since humans are a product of nature anything they make is as well). There is no roughly 9 month time-frame dictated by nature for the Helix, the speed of its development is a function of the quality and quantity of manpower devoted to it. Even if it is a "pregnancy" I believe that BigRalphN's point was that it has exceeded 9 months and is now "late-term". :D

This does not sound like sour grapes to me. I have to point out that BigRalphN has been on the Helix forum almost from the beginning and has never been one to pressure L6 for "more", quite the opposite. His has generally been a voice of restraint when requests go off the deep end. So... when he puts up a post urging L6 to speed up their development cycle it definitely catches my attention.

I have to agree with BigRalphN as well as the other posters here who stress functional improvements like switching lag time versus the addition of new models and effects, everyone has a legitimate point. I believe all of these areas are worthy of attention. As has been commented on by others, for me, the Line6 interface, hardware I/O options, scribble strips, and built-in expression pedal are so compelling that I would not even entertain switching to the AX8. The Helix platform is so vastly superior to the AX8 that if they can make it rock solid, fix some fundamental issues, and add some much needed content it becomes the superior device it is destined to be. There are still old bugs as well as some fairly substantial new ones (tap tempo issue, Editor and Helix lock-ups) that need to be addressed. I would like to see the bug situation (although I don't mean to imply it is bad, it is not) stabilize so more attention could be paid to adding value instead of fixing problems. I could not agree more that one new amp and a few effects in nine months is not exactly what I was hoping for in terms of content support and development for the Helix. I say this with the hopes that this does not erupt into yet another thread about what expectations for this product should be or not be. I think the issues with the external amp control are a total debacle. My thanks to the electronics experts on this forum who have offered some clever workarounds, they should not have been necessary. As I stated the I/O options are part of what place the Helix in the MFX stratosphere, but they need to work properly. A few dollars more spent on the external amp control parts as well as a MIDI clock would have been money well spent. For my requirements there is simply no competition to the Helix on the market so as always I hope that my comments are construed as being part of the respectful chorus that will if nothing else provide some ammunition to the more ambitious developers and product managers at Line6. I honestly do not view any other product on the market as a viable alternative to the Helix, I can't and don't wish to switch horses. All I can do is offer ammunition and customer feedback that can be provided to a CTO and VPs to procure the necessary resources for a vision that I believe will result in a Helix that exceeds all corporate profit expectations and simultaneously provides its users with the maximum mojo possible. Ultimately whilst hoping L6 will put their foot on the accelerator I would encourage folks to hang in there and be patient because if DI's recent posts are any indication it looks like there is some great stuff in the pipeline coming soon.

This has nothing to do with MichaelHardly, the OP's, software. There is a brand new bug in Line6's website on the CustomTone download page that has the precise symptoms he described. If you hit the download arrow icon at the right side of the page, the web page greys out and you get a tiny "x" icon. This is definitely not normal behavior and not the way the CustomTone site has worked in the past, this started a few days ago and needs to be fixed. It is the same behavior on Chrome, IE, and Firefox. You can work around it for now by clicking the linked name of the custom preset on the left of the page instead of the download arrow icon on the right side of the page; then go to the download arrow icon on the right side of this one level down page and the download will function normally. Line6 please fix this when you get a chance. Thanks!

That pretty much sums it up. The backup files are so small it doesn't take much extra room to keep things like multiple backups in well sorted directories. In case there are compatibility issues from one editor/firmware version to the next I know exactly which version of the editor and firmware I used to make my backups. Gives me a rough timeline on things and enables me to roll back easily in case I screw something up or a new version of the software/firmware has a bug I can't live with.

I use the default directories Line6 installs with the editor but create my own sub-directories underneath them that include separate directories for each editor revision with their corresponding backups, as well as special named directories that help me sort out my IRs, dowloaded presets from CustomTone, etc..

I am not currently using an external expression pedal but I think a workaround would be to select the "Volume/Pan" (Volume Pedal) block, then go to "Controller Assign" and change the "Controller" parameter to "EXP Pedal 3" (make sure you have your external pedal plugged into EXP 3 on the back of the Helix). You are correct though, unless you have discovered a bug with the new firmware you should not have to do this. Plugging an expression pedal into the "EXP 2" jack on the back of the Helix is supposed to switch the default operation of the expression pedal included with the Helix to only control "EXP 1". I wonder if your external expression pedal is not being recognized properly by the Helix and therefor not deactivating the Helix's built-in expression pedal's default control of "EXP 2". It might be worth experimenting with a different external expression pedal or the cable connecting it to the Helix. Here is the excerpt from page 6 of the Helix manual: Expression Pedal Move the expression pedal to control volume, wah, or a combination of amp and/or effects parameters. Activate the hidden toe switch to toggle between EXP 1 and EXP 2. (The scribble strip above tells you which one is active.) If an external pedal is connected to the rear panel EXP 2 jack, the built-in pedal becomes EXP 1 only. See "Controller Assign".

This should definitely be placed as a "P1" top priority bug to squash. This is not good and probably easy to fix.

Yep, recreating from scratch would have been my alternate goto strategy, and I bet that does often result in a more refined sound. However, it seems it is not necessary to do an entire rebuild of the preset. Any minor modification and save to the preset seems to fix the issue. However a save alone is not sufficient, you must change a parameter setting first.

WARNING, WARNING, WARNING!!! Saving a preset that gets the rebuilding message can prevent the editor from coming up if it is already selected on the Helix when you try to start the editor. It can also crash the editor when you select the affected preset while the editor is already running. I think Klangmaler's question about the status of this bug(?) has turned out to be incredibly significant. Please read the bug I am encountering below before attempting to save/fix any of the presets that are getting the "rebuilding" message. I think the "rebuilding" message is actually a real bug and one that causes serious problems with the editor if you save the affected preset. This certainly does not appear to just be a caching issue as the engineering team explained it. If the affected preset is saved it then becomes a genuine bug and has significant impact! I did however find a simple workaround that still allows you to get rid of the rebuild message and not impact the editor. The workaround is at the bottom of this post. I have already saved all of my "rebuild" message affected presets. If anyone still has any could they please run the test below on them with ones they have not "fixed" by saving to see if they also crash the editor or prevent it from coming up. I am also curious if the same behavior occurs on Mac PCs. Mine is Windows 10. Firmware 1.12.0 Editor 1.12.0 OS: Windows 10 Bug: Presets that have been saved to prevent the "rebuilding preset #" message when you boot the Helix can not only crash the editor when selected, they can also actually prevent the editor from starting up if the affected preset is already selected on the Helix when you start the Editor. Test Procedure: Save one of the presets causing the "rebuild preset" message upon boot such that it no longer appears on bootup. Restart the Helix. Select the preset that you "fixed" with a save. Now try to start the Helix Editor. The Helix editor will not start at all if you have the "fixed" preset selected on the Helix when you try to start the Editor. Select any of your unaffected presets and restart the Editor and it should start up correctly. I also found that if you start the Helix editor successfully with any of your other presets, and then switch to one of the saved presets you were getting the "rebuild" message on, it will consistently crash the editor. I can also replicate the crashing editor issue by simply copying the "fixed" preset to any other preset location. If I select the newly saved preset the Editor will not start. If I start the editor on a working preset and switch to the copy of the problem preset it will crash the editor. UPDATE: I noticed that if you modify any parameter on the "fixed" preset no matter how minutely and save it again. The crashing behavior both on startup and when you switch to the preset is fixed. Se here is my conclusion. There is a workaround for now but this is definitely a strange bug which I hope gets addressed. Workaround: If you fix any of these presets affected by the "rebuilding..." message by saving them (which causes the rebuilding message to go away) make sure you edit at least one parameter on one of the blocks and save the preset again. It does not matter how small the change is. This will prevent the editor from either not starting or crashing when that preset is selected.

Here is an interesting bug, I am now thinking that the "rebuilding preset #???" message on reboot is not so benign and needs to be addressed. Firmware 1.12.0 Editor 1.12.0 OS: Windows 10 Bug: Presets that have been saved to prevent the "rebuilding preset #" message when you boot the Helix can not only crash the editor when selected, they can also actually prevent the editor from starting up if the affected preset is already selected on the Helix when you try to start the Editor. Test Procedure: Save one of the presets causing the "rebuild preset" message upon boot such that it no longer appears on bootup. Restart the Helix. Select the preset that you "fixed" with a save. Now try to start the Helix Editor. The Helix Editor will not start at all if you have the "fixed" preset selected on the Helix when you try to start the Editor. Select any of your unaffected presets and then try to star the Editor and it will start right up. I also found that if you start the Helix editor successfully with any of your other presets, and then switch to one of the saved presets you were getting the "rebuild" message on, it will consistently crash the editor. I can also replicate the crashing editor issue by simply copying the "fixed" preset to any other preset location. If I select the newly saved preset the Editor will not start. If I start the editor on a working preset and switch to the copy of the problem preset it will crash the editor. UPDATE: I noticed that if you modify any parameter on the "fixed" preset no matter how minutely and save it a second time. The Editor crashing behavior both on editor startup and when you switch to the preset is fixed. Se here is my conclusion. There is a workaround for now but this is definitely a strange bug which I hope gets addressed. Workaround: If you fix any of these presets affected by the "rebuilding..." message by saving them (which causes the rebuilding message to go away) make sure you edit at least one parameter on one of the blocks and save the preset again. It does not matter how small the change is. This will prevent the editor from either not starting or crashing when that preset is selected. Here is the link for the Excel sheet that will help you find the setlist, bank, and footswitch that corresponds to the number you are seeing in the "rebuilding ..." message: http://line6.com/support/topic/20454-grid-for-getting-rid-of-the-preset-rebuild-messages-on-boot-in-latest-firmware-1120/?hl=grid

Yes.

Sometimes the sun shades they sell for people to leave on their dashboards when they park their cars in summer sun can be rigged to work ok. Here is one that might work with a metal band, but not so much for a folk acoustic act :D http://www.amazon.com/Universal-Reflective-Windshield-SUNSHADE-Reversible/dp/B0125DPF3Q/ref=sr_1_1?ie=UTF8&qid=1463361084&sr=8-1&keywords=Universal+24x58+inch+Reflective+Slanted+SKULL

Good one Duncann, thanks! This combination should be added to HelixHelp.com.

Very cool! I would say that in some sense this qualifies as a "hook" to executing undo, and at least is an ingenious way to leverage a method already baked into the code of implementing it, although L6 certainly might approach it differently if they wanted a more nuanced or faster and potentially more transparent method for multi-level undo. It appears to be a good example of safely using high level commands in exactly the same manner the Helix currently saves and loads a preset and would not seem to require any modification to the Helix's existing codeline and only minor changes to the editor. Unless there was a bug in the implementation it should not be any more dangerous or inaccurate than saving or loading a preset is right now. Not saying this is necessarily how Undo should be implemented, simply agreeing that it is low hanging fruit that would certainly get the ball rolling.

Great way to use the looper and editor! I will definitely be adopting this one. Surprised I hadn't thought to do that already as that is how I often edit presets directly on the Helix.

Glad to hear it!