HonestOpinion

^^^ What phil_m ( I :) ) said! I have one of these set up on every preset for a completely transparent boost and it is assigned to a stomp footswitch. Assigning Output block to footswitch for boost Select Output block Bring up 'Controller Assign' screen Select 'Level' under the 'Parameter' knob (knob 1) Select the footswitch or controller you want to assign the boost to under the 'Controller' parameter (knob 2) Set the 'Min' parameter to the same level you use for your Output block's normal volume and the 'Max' parameter to the volume bump you want for your boost. Usually 3-4db more than the 'Min' parameter. Save the preset

One method I like using is assigning the Output block at the very end of the signal chain to a footswitch and setting up a 3db or 4db boost on it. This is the best method for ensuring a clean boost if you are looking for one that does not drive any effect or amp blocks differently but simply raises the volume. It also does not require an additional block. As Cody_smith pointed out there are other methods for placing the boost further upstream that will interact with the amp or other effects and drive them harder. Lots of flexibility and choices for a boost on the Helix, just depends on what you are looking for.

Cool, hope it helps. The 'Flash Memory' file should be right below the 'Helix' file in the L6 download section if you sorted on 'Helix' and your OS version. Once you get the Updater talking to the Helix you should be able to point to your local copy of the 'Flash Memory' file and execute the firmware update. Make sure you get the same version of the firmware ('Flash Memory') file that matches the version of the 'Helix' app you downloaded. The latest one is 2.11 and you want to make sure that is the version for both files.

When you say the Updater does not do anything does that mean that when you fire it up it is not showing the Helix and the firmware version along with the graphic in the initial Updater screen? If that is the case it usually means that the Windows driver either has not been installed, did not install properly or you are having problems with the USB connection to the Helix. Make sure you install the 'Helix' app first which will install the Editor, Updater, and the critical driver. If you already did that and the Updater is still not seeing the Helix I recommend uninstalling the Helix software and reinstalling it. If the Updater is still not seeing the Helix you should try every available USB port on your computer or even another computer. Once the Updater is communicating properly you will see your Helix and current firmware version on the initial screen. Clicking on that will allow you to either download the firmware from Line6 or to point to the firmware file on your local machine (which sounds like the best way for you to go). Note: You probably already know this (but in the interest of being thorough as you are attempting a manual upgrade) the 'Helix' app file which has the Editor, Updater, and driver is a separate file from the firmware which is titled 'Flash Memory' on the L6 Downloads site. You will need both files ('Helix', 'Flash Memory') to do a local/manual firmware upgrade.

The A/D converters may all be the same but just wanted to point out in addition to the 'Guitar' input I believe the 'Aux' input is also different in that it has a different impedance(10KiloOhms) than the loop return inputs. What is the input impedance on the loop returns?

I have noticed after any load of presets to the Helix the next reboot always displays a message showing the presets rebuilding. Before editing a freshly loaded preset or investigating to make sure it is working properly I think it is best practice to restart the Helix first. Whether it is restoring your backups, loading something from CustomTone, or a custom preset pack you have purchased, you need to allow the rebuild process to complete by restarting the Helix.

I hear you on the "opaque" thing. Takes a minute or three to wrap your head around how it operates but well worth the effort given its flexibility and the amount of time it saves over doing things manually. I would really like to see L6 increase the size of the namespace for IRs as well as improve their ease of management by not requiring them to go into a specific slot. There are conversations however elsewhere that detail those issues.

Without creating a second delay/reverb block, I think right now that is the only alternative that makes sense if you are switching the parameters for the delay/reverb between snapshots. If you are not then you have the option of leaving trails on. I look forward to Line6 giving us the option to both have trails on and also switch parameters without glitching. Thanks for catching this issue!

Agreed, the discussion regarding DSP preallocation was resolved by DI in that other topic you are referring to. If the second block is required the DSP definitely has to be allocated beforehand when the trails/parameters option is selected, whether the Helix creates a second copy of a block automatically behind the scenes or the user does it explicitly. Ultimately I just don't want to make too many assumptions about what is required to make this work. Just want to lay out what the ideal scenario would be and let Line6 hopefully take it from there. Ideal scenario is trails and parameter changes work on the same block. Minimum of fuss and user intervention that way.

Select volume block (or whatever block you are interested in modifying) Go to 'Controller Assign' screen Modify the value for the 'Controller' parameter to the footswitch or alternate assignment you prefer. You can change other parameters here as well.

We definitely start with the basic premise you laid out earlier that switching to a new snapshot has to immediately make the new delay settings available if the block is already active or alternatively when the block is activated. The desired objective would be to enable the use of both trails and parameter changes on the same block without glitching between snapshot changes. Perhaps in the digital domain, when switching to another snapshot with the same delay block activated, momentarily, and for the duration of the trails completing, there are in essence two delay blocks active. One with the old settings processing the trails from the final note/chord before the snapshot switch and then the delay block with the new settings kicking in as those final trail bits are processed. Even if this means that in programming terms there has to be two versions of the same delay block active for a moment in time that does not necessarily translate to a user having to gin up two separate delay blocks. That processing can be done behind the scenes for the user. If it requires two actual copies of the same delay block the DSP would have to be allotted ahead of time when trails are first set on for a block. We know that from recent discussions on other topics regarding how all blocks within a preset, active or not, are loaded into the DSP as soon as a preset is selected. It would seem that there was some magic in the way Line6 programmed trails that did not double the DSP requirements when trails are turned on. I have never had a preset give me an out of DSP message due to turning on the trails feature. I am assuming they trails are coded in such a way, optimized, swapped out to memory, whatever. such that the DSP cost did not double. Perhaps that 'magic' is simply not possible if you also change the parameters while using trails. The block may need all/certain parameters to remain absolutely unchanged from snapshot to snapshot to function properly. This makes the snapshot operation of blocks with trails different from all other blocks, above and beyond their ability to provide trails. Perhaps Line6 will figure a way to make trails work properly with parameter changes on the same block but for now that does not appear to be the case. Even if they do it may come at the cost of additional DSP (in essence a second virtual block copy). So in summation... I was sort of under the impression that the whole intention of trails functionality in addition to the obvious sound benefit was to perform the trails functionality transparently for the user without the need for an additional copy of the delay/reverb block created by the user. The ability to assign parameters to snapshots seemed to be an elegant way to change them between snapshots instead of creating and switching to another copy of the same effect block and the attendant additional cost in DSP. Perhaps however enabling trails and also changing parameters is not possible without pre-instantiating two copies of a block. The second 'copy' block could be instantiated automatically behind the scenes by the Helix when trails are set on but only when a parameter change option is explicitly set by the user. If a second virtual block copy is ultimately what is required then I can see adding an additional parameter like 'Enable Parameter Switching' for use when the user want to change parameter settings between snapshots on blocks with trails. That way the firmware is not wasting the DSP on an internal second copy of a block with trails when its parameters are not being changed between snapshots. The second copy would not be required in that scenario. I was hoping that there might be a better alternative than a 'two block solution' to get both trails and parameter changes to operate on one block simultaneously but perhaps there is not.

Regarding what happens when you put an effect block after a delay/reverb block I understand your reasoning. Not silly at all, the same thought occurred to me ("the operation being similar to an analog pedalboard") at least as it regards putting effects after a pedal with trails. However it also occurred to me that we are in the digital realm and people around here justifiably and fairly regularly point out that all the rules don't need to be the same. We can make improvements on limitations imposed by analog rigs. I would agree though that not putting any blocks after your delay/reverb blocks with trails or alternate routing is the easiest way to address that issue without having to enhance the trails functionality. The glitch between snapshots however is not analogous to analog pedalboard behavior. This is the issue that I would be more keen to see addressed in such a way that having different settings on the delay/reverb blocks in a subsequent snapshot does not cause a glitch in the trails from the prior snapshot, whether the delay/reverb block is bypassed or active in the subsequent snapshot. Note: I ordinarily do not put effect blocks after the delay/reverb blocks. The only reason I noticed the reprocessing 'feature' on trails is because I was forced to experiment with a second delay block placed after the first in an effort to prevent the glitch in the trails caused by switching snapshots.

If you don't go the Variax route or maybe even if you want to add additional control to the Variax this device seems pretty nifty as well. Not quite sure how it could be interfaced to the Helix though. I assume you would just connect it via the MIDI input. You could also use it in addition to the Helix to control a DAW. http://www.sweetwater.com/store/detail/GuitarWing?adpos=1o1&creative=55280653081&device=c&matchtype=&network=g&product_id=GuitarWing&gclid=CPbAx4_DhNECFcxXDQodaAkK5A

You can also rename snapshots from the Editor by clicking on the camera icon in the upper left hand corner. You will see 'Rename' in the pulldown menu.

The Helix forum's resident genius and mad scientist roscoe5 back in the lab. Very cool things you have been working on lately. The info from the Fractal community was quite detailed and made for an interesting if somewhat overwhelming read. Please keep us posted as you find new and improved ways to EQ and leverage IRs and native Helix amps/cabs. Thanks for all your hard work on this stuff and also for posting your results! :)

I hear you, you have to selectively delete parts of the entire file name to keep the pertinent information in the title. I am a Windows user and found a freeware utility that will bulk rename files, delete or insert text, etc., as well as numbering them sequentially. I can't vouch for whether or not it has spyware or viruses but so far so good (at least as far as I know). You can find it here: http://download.cnet.com/Bulk-Rename-Utility/3000-2248_4-10174242.html

Nice elegant solution! That would take care of many problem scenarios as long as you do not have effect blocks coming on that are after the trailed delay/reverb blocks in a subsequent snapshot. It also does not solve the problem of going to a snapshot where trails are on but the parameters change on the delay/reverb block and the delay/reverb block is activated in both snapshots.

Hmm, upon closer examination of the OP's original post and experimenting with it myself you are absolutely correct. I guess another way to address this then (if you have the DSP available) is to set up a second delay/reverb for the alternate settings; this works as I tried it, although only if the second delay/reverb block is bypassed in the second snapshot when you switch. The first matching delay/reverbs block keep the trails consistent between snapshots and the second is for your alternate settings. I think I may have noticed a second bug/feature here with trails. The trails from a snapshot are not only being affected if there are different parameters on another snapshot but actually being reprocessed by other blocks. I put a second delay block after the first one I was using to run experiments with trails. If I switch snapshots and the second delay is activated (it was bypassed in the first snapstho) It appears to be processing the trails from the first snapshot and adding a delay to them. My understanding of trails is that they should not be processed by the blocks from a subsequent snapshot. They are simply the trailing remainder of the last snapshot. I am hoping someone else can confirm this. It appears if I add a second delay block to the second snapshot so that the 1st delay block=active and the 2nd delay block=bypassed in the first snapshot. My second snapshot has the 1st delay block=bypassed and the 2nd delay block=active. They both have 'Trails' activated. Perhaps I am getting confused but it appears that when you switch from the first snapshot, to the second one, the trails from the first snapshot are actually getting delayed again by the second delay block on the second snapshot. To test this I set the two delay blocks up with different delay 'Time's and set the 'Feedback' and 'Mix' levels up high to make sure I could hear them. This behavior becomes really obvious if you put a distortion block after the delay block. Bypass it on the first snapshot and activate it on the second snapshot. Make the first snapshot a clean sound with a long delay and high feedback and mix level so you can easily hear the repeats several times (make sure trails are on). When you switch to the second block your trails are now distorted. I would expect the trails from the clean first snapshot to remain clean and not be processed as distorted by the distortion block that is now on. I suppose this is not a problem as long as you don't have any blocks that become active after a snapshot change that are after your trailed delay/reverb in the signal chain. Is this the same behavior other people are hearing? Ideally it seems the behavior would be that the trails to finish being processed only by the parameters from the first snapshot regardless of the parameters for the second. In essence the trails from the first snapshot need to be in memory as a separate entity that can complete independently of whatever is being switched to and played in the subsequent snapshot. Almost as if the trails were in a looper (played once without being looped) at the end of a signal chain, unaffected by what comes before them in the signal chain of the second snapshot. If people need a choice as to how trails work perhaps an additional global or per preset setting for the trails behavior might be another option. The question is whether the Helix can be given the capacity to allow the trails' delayed signal to complete without changing from one snapshot to another regardless of which blocks are activated or which set of parameters changes, while simultaneously allowing the blocks activated and new parameters to take over anything played after the snapshot switch. Such that for example the last delay from your clean rhythm is trailing as you kick in your lead. Or such that my trailing delay does not audibly glitch or have its settings modified or reprocessed and delayed again by switching to a subsequent snapshot. The same thing applies when I switch back from a lead snapshot to a clean rhythm snapshot. I don't want my last trailing lead delay (played in my lead snapshot) to all of a sudden become clean instead of distorted because the distortion block is not activated in my clean snapshot. That is my most typical scenario for how I would like my trails to operate. IMHO this is genuine problem or at least a lack of flexibility with how trails have been implemented and I hope it gets addressed at some point.

I wonder if you would still get trails but not the glitch if you assign the 'Mix' parameter to snapshots ('Trails' activated) and simply leave the delay/reverb activated when you switch snapshots but change the 'Mix' to 0% so that it is not affecting your snapshot, instead of bypassing the block.

Deus ex machina... :)

This is not happening for me either on the Helix itself or the Editor screen. Did you do the global FS 9&10 reset? If so and it is misbehaving it might be worth re-flashing the firmware.

It might be too vague or not meaningful enough and a whole lot of work but sometimes for IRs I almost wish the creators would assign a 1-10 scale for certain parameters and describe frequency range, frequency response, where for instance there was a mid hump or cut, etc... Sort of like what guitar pickup sellers like Dimarzio do on their websites. They give you ratings for certain fixed parameters like bass, mid, treble on a scale of 1-10 as well as a further description of the pickup. http://www.dimarzio.com/pickups/humbuckers/high-power/imperium-bridge

LOL, so you're saying I should have said "That is so 1950's, 60's, 70's, and 80's". You are correct sir, If you buy gear from any of these eras you should not sit around waiting for a software update. We are basically all on the same page here, most everybody enjoys a new update chock full o' new features they have been hoping/advocating for(barring those who run into upgrade issues). Anyone who doesn't is welcome to cling to their principles and stay with the very first firmware version 'cos by golly they didn't buy the Helix expecting any updates. MIDI clock sync on a high end modeler is a perfectly reasonable expectation/request but if it is something you absolutely must have you are definitely taking your chances with a device that will probably but may never get it. Didn't mean to start a skirmish and cause people to take sides here. I bought the Helix with high hopes as to what it would evolve into and that gamble, at least as it regards the feature set has been richly rewarded. I would just caution people, which is what I think zooey was trying to do, against buying a Helix for a specific wish-list item that may never materialize. I am just saying the situation surrounding firmware updates and what some people view as critical features often seems to me to be a bit more nuanced than a one-liner ("Never buy gear for what you hope it'll do in the future.") even if it has become somewhat accepted as conventional wisdom. Who says we need to be conventional? We're musicians dammit! ;)

I can see why some people, especially those using external expression pedals, would prefer not to have defaults. Maybe they could add a global setting for the volume and wah defaults to add flexibility. Personally I like having defaults for the volume and wah as I set them up in pretty much every preset. It is a timesaver not to have to go in and set up the assignments every time. It just would been more intuitive IMHO to make the volume be 'EXP 1' and the wah 'EXP 2'. It is an exceptionally minor issue to me however.

DI has been uncharacteristically specific of late (thanks DI) but even those tidbits are few and far between. I think most people have anticipated for quite a while that updated reverbs would come to the Helix at some point as the current versions were not designed for the HX technology and were ported from the HD effects. It is admittedly very reassuring to hear DI announce that they are either being worked on are in the plans. There are some bread crumbs dropped now and then but for the most part new firmware releases are comprised almost entirely of features that have not been announced. Even on the rare occasion when specifics are announced ahead of time the release date is usually either not announced or rather vague. So as I said, if you need a feature now, chances are they are not going to mention the exact one you are looking for unless you get lucky. Even if they do you usually cannot be certain as to when it will arrive. Even when it does arrive it may have bugs that need to be resolved. So if your timetable is right now for a feature you simply must have, buy a device that already has it. That is what I have observed so far and that is how I adjust any expectations. For example, it has been announced that there is more to come in 2017 but for the most part neither the specifics nor even what 'season' the delivery will occur in have been announced (at least I have not seen it).