HonestOpinion

Just select the block you want to set a parameter to a footswitch for. Go to "Controller Assign", select the parameter you want to control, assign it to a footswitch and set the min and max parameters to the settings you want. Then save. You may well find it faster and easier to use the "Quick Controller Assign" function to do this by simply pressing on the button for the parameter you wish to control via footswitch for 2 seconds. This will jump you over to the "Controller Assign" page and essentially just execute the same procedure as above.

Excellent!

Depends on what I am doing. For preset or scribble strip naming, large changes or changes to multiple presets, changes to preset order within a setlist, bulk copies of presets from one setlist to another, or the initial building of a preset from scratch, definitely the Editor. I also prefer the editor when I am just sitting around tweaking presets on my own. For practice and gigs, footswitch assignment, final fine tuning of a preset's sound(guitar in hand for this) and I/O selections, and other activities more targeted to live performance, definitely the Helix. I have to hearken back to one of my ideas on Ideascale which was to move the amp block's "Master" volume parameter on the Helix to the first page where it could be adjusted in tandem with the "Drive" parameter, and put the "Volume" parameter on the second page. It still annoys me to have to switch pages on the Helix to get the blend of the "Master" and "Drive" parameters to my liking. For that reason I prefer to adjust the amp block with the editor where all parameters are accessible from one page. I suppose I could use the Helix footswitch edit mode to get everything in the amp block showing at one time (Nope! "Master is on the second "page" there as well). If only the Helix had one more parameter knob! Vote for it here: http://line6.ideascale.com/a/dtd/Put-Master-volume-on-the-same-page-as-the-Drive-in-amp-model/788502-23508 (Not the extra knob, although that would be nice but swapping the location of "Master" and "Volume" in the amp block pages)

Most kind of you sir, thank you! Good luck getting this resolved!

There are free tuners for the PC that you could always switch over to, just google "guitar tuners free (PC/MAC)". I have not used the free one posted below so I can't vouch for it being free of adware or spyware. http://www.nch.com.au/tuner/

No not necessarily to "Undo", but hooks to objects or code structures that would allow a simple higher level undo using stacked basic commands to be implemented, although ultimately an additional code structure or object(s) solely designed for Undo might be the best way to go.

LOL, ain't it the truth. You may notice I have been studiously avoiding jumping back in on this issue as it has been so belabored. Just thought I had to respond to your post to keep hope alive. ;)

How do we know the hooks are not in the firmware already?

I would not argue that this may perhaps be good design. However, having a hidden lower layer in a multi-tiered application in no way precludes having hooks to it that allow something along the order of what BobTheDog is proposing. Business logic is often embedded in an object layer with objects that have simple command structures for manipulating them. The lower level operations in the object are opaque to the end user, may be vastly more complex, and do the heavy lifting and things like enforcing data integrity and business logic, but those objects can be easily invoked and manipulated with simple commands from the upper layer. Many applications and of course operating systems work this way, otherwise every time you wanted to do any simple operation like moving a file you would be flipping bits one by one. My one caveat to BobTheDog would be advising restraint in actually making code level recommendations to L6 regarding implementation on too granular or specific a level. We simply do not have enough information on their architecture and code. However, ultimately in more general terms, I think he is on the right track.

I hope you are mistaken about this. The Helix would really benefit from scenes and what you are calling "complexity" is an inevitable consequence of making a top-notch MFX. Line6 has already demonstrated they are the best in the business at taking complex electronics processes and making them user friendly. They clearly have the best design team in the business when it comes to this! IMHO, no device on the market even comes close to the Helix when it comes to the UI, however, I don't believe they need to sacrifice critical functionality for simplicity. I would also hate to see "complexity" become a code word for not tackling the tougher challenges (not that they haven't tackled many of them already). There are still a couple of things that need to happen on the Helix to make it more user friendly for the gigging musician, and scenes, or assignment of the same block/parameter to multiple footswitches, are foremost amongst them.

I highly recommend against importing bundles, I strictly use them as backups in the event of a catastrophic failure of my other backups. When you restore a bundle you restore the Factory lists in addition to the User lists. This means any additions or changes to the Factory lists in the latest firmware get overwritten with an older version. I copy the factory presets I want to tweak to User lists. Backup your User setlists one by one (any that have presets) and restore them individually with a Setlist import. Given the issue you are encountering, I would also export all of my presets individually, you can do this by highlighting them all and hitting the "Export" link. I would then restore them in bulk in the same manner using the "Import" link, perhaps excluding the one(s) that are not loading properly. This will enable you to hopefully get most of them loaded assuming that the bulk of them are not having the same issue. Make sure you have the list/slot you want to restore to highlighted in the Edtior, hit the "Import" link and then highlight the presets you want to load in the Windows File Explorer. You can then upload the problem presets to the forum or Line6 customer service for perhaps some additional support regarding why they are not loading. Once you have things straightened out, going forward, at least for now, importing and exporting setlists individually is a good backup/upgrade strategy; and also taking a bundle backup as well as individual exports just in case never hurts either. Btw, assuming you have not stumbled across a bug with a particular block/parameter, you may well be hitting an incompatibility between whatever version of the editor and firmware you backed up with versus what you are trying to restore with. That is what the issue appears to be.

Speaking of IRs that may be useful for a DAW but not so much for the Helix, check this site out. It has IRs in multiple formats for natural and man-made structures including one which it claims is the longest echo of any man-made structure. http://www.openairlib.net/auralizationdb

Great to see this make its appearance in the editor!

hear! hear!

Voted for both ideas!

When I go for "hubris" I definitely strive for the "heights". Otherwise you denigrate your hubris to mere arrogance or conceit. :D

Definitely not holding my breath on this one. And if its remote control, why isn't it wireless (just kiddin')? B)

In the database world we would simply encapsulate all levels of the undo within a single uncommited transaction, potentially with multiple savepoints. Hitting save would constitute the commit and undo would be a rollback. But yes, I can see where at least initially implementing "Undo" functionality and still being able to dynamically hear the results of your action on the Helix would be a bit of a programming exercise but nothing that can't be pulled off. You may have to implement some messaging to the user for certain actions that cannot be undone such as you see in other applications. I would think an initial simple implementation would be at least to have the parameters for a block be stored in an undo/redo stack for A/B comparison purposes. More complex undo actions could come in later implementations.

A well written synopsis and I agree with most of the points you are making, particularly regarding the range of user hardware and software platforms that beta testing provides and the emphasis on bug fixes. I am simply stating that an ideal beta test takes into account critical feature requests and UI usability issues as well; even if as you say, it takes version 2.0,3.0 or 35.0 to deliver them. I do have to disagree on a couple of points, given the number of users already out here for the Helix, the best and most common of their suggestions are probably a very good representation of the wider user base. Also feature changes and enhancements based on user feedback are "dangerous" seems like a bit of hyperbole. I have designed software and made numerous and sometimes substantial modfications according to user feedback during the beta period. Granted there can be unanticipated bugs caused by new features/changes but that is all part of a beta process which can be as fluid or as static as the developers deem appropriate and have time and resources for. Of course the product did not come up in a vacuum although a different or larger design team might have changed a couple of the underlying premises used in the design. Some things that perhaps could have been, or will be done differently -- I think in a commendable effort to keep consistency between the software for various L6 products they have perpetuated a design paradigm of using bars for everything instead of using them in combination with other UI elements like dropdown menus and switches. This may expedite development, be visually pleasing and make it easier to position screen elements but IMHO, I believe it degrades the user experience for binary options like on/off and particularly for multiple choice text fields . I also believe the bars are too wide in places preventing all of the parameters for a block from being displayed on one screen without scrolling. I hope L6 modifies this visual paradigm in their software at some point in the future with an eye towards utility as well as consistency. In an effort, at least initially, to emulate the current functionality of the Helix perhaps some opportunities to add features to the editor have been missed or delayed(? still too early to tell), such as scenes or undo capability and a host of other functions that would make the editor more than a "remote control" and actually add new features and functionality that may not or cannot exist on the device itself. These features may well be coming later and some have already appeared. I believe the main screen of the editor should show more useful information like the specific names of the various blocks in the signal chain rather than requiring clicking on or hovering over them, but that is not the focus of the point I am making, the underlying design principle is that although the editor screens and feature set need to follow the Helix to some extent for consistency and ease of use they don't need to mimic them to the point of inheriting limitations imposed by the physical hardware of the Helix such as the smaller screen or switch/knob contortions that might be required for certain operations. PC software has its own inherent limitations but also offers some advantages that can be exploited to do things that would be difficult or impossible directly on the Helix. The design team will probably exploit these alternate capabilities the Editor offers even more in future versions. Anyway it is way too easy for us to be armchair quarterbacks when we only have a fraction of the facts and I am sure much of what the user base suggests was already discussed by the designers. One advantage is that the beta feedback informs the designers as to which features and changes are most important to its users. Those user priorities are information you don't necessarily have during the initial design phases. Regardless, it is still too close to the release date for me to get mired down in anything other than to express my admiration and appreciation for the editor. It is a great tool and I am elated to have it! Line6 has every reason to be proud of their accomplishment. I think it can only get better in future iterations but it is already fantastic, easy to use, and aesthetically pleasing and ultimately, there are so many things other than the editor that are of way more importance to me.

Yes, surprised this bug keeps kicking around from version to version, this should be easy for them to remedy in future firmware. Thankfully it is an extremely low impact issue.

Although it's nowhere near the top of my list it seems like an undo function might take us one step closer to an offline editor, grin. ;)

I am still getting the rebuild preset messages when I boot up the Helix with the latest firmware 1.12.0. A minor inconvenience but if you are obsessing over it or want to regain a few nanoseconds of your life you can use the grid I included below to tell you which setlist & preset you are seeing during the bootup process when you see a message like "rebuilding 501" and easily fix it. If you prefer, I designed the spreadsheet with a calculation box where you can just enter in the number you are seeing during the boot and the spreadsheet will return the setlist & preset number/letter. Just select & save that preset and the message for that preset should go away next time you reboot. Not a big deal but it is nice not to see those rebuilding messages any more. The preset numbers showing on bootup start at "0" so the grid does as well (L6 numbers the presets from 0-1023). There are 8 setlists on the Helix with "Factory 1" corresponding to "Setlist" 1, thru to "Templates" which corresponds to "Setlist" 8 in the grid. You will need to save the preset indicated by "Bank/FS" in the corresponding "Setlist". I am making it sound more complicated than it is, if you download the Excel sheet it will be self-explanatory. 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 while using the editor 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. Helix Preset Number To Bank Conversion (Share).xls

I noticed the same thing regarding the download. For those who have not updated yet (at least at the moment), the latest download of the "Helix" app installer under the beta (checkbox) section of the download page will update you to the latest driver, firmware, and Editor version (1.12). I found this a bit confusing when I went to do the update as the editor is officially out of beta. I have in no way given up on seeing some of the better suggestions find their way into the editor and have no problem with patiently awaiting them as Line6 rotates through top priority issues and additions to other areas of the Helix.

Absolutely not always the case! I have been a developer and beta tester for a huge range of software and soliciting recommendations for improvement and making changes to parts of the UI that users find problematic or in need of tweaking is often part of the process. Otherwise the beta process is nothing other than a QA process utilizing end users as your QA team. Not that this does not happen but it is hardly an ideal use of the resources inherent in a large user base. A beta process at its best should be a feedback process of give and take and more than just a QA exercise. The endgame should be the goal of putting out the best, most well received product possible, catered to the end users needs and requests (within reason, technical constraints, and allotted resources). Line6 did a wonderful job on the editor but implementing some suggestions that came up almost right away during the beta period would make the editor much better. Lastly I would add, if, as you suggest, the design was fixed long before the beta process, then L6 might want to consider getting more users, especially those familiar with UI design, involved in the initial process.

Great idea!