tommasi

Thanks, I saw that in HX Stomp, didn't know it worked for the HX effects too. Will try that!

Most modern modelers supporting external EXP pedals allow you to engage the pedal without a toe switch. Typically, it activates as soon as you rock it, it deactivates when you leave it at toe or heel for a short, sub-second period. It seems to me this isn't possible with the HX Effects, which leaves me tap dancing to engage/disengage the wah. Am I wrong and there's a way, or what? Thanks!

Yes, it's true (though I wish you'd stop mentioning Windows or Unix...:) DSPs work like GPUs: you preload them with the a code pipeline they need to run. When they don't run it, cycles are wasted, but you can't switch code in or out onreal-time. Changing patch loads the code into the dsp, activating effects just switches a processing block on or off.

...nor can a thread span 2 cores on a SMP system, no matter what the thread is doing (be it audio processing, video processing, or defragging your hard drive). The architectures are mostly different because DSPs are not general purpose and have strict real-time requirements. That does not mean OS theory does not apply to them (as it applies to all embedded system, certainly not just DSPs) -- it is however a fact that an embedded system does not have all the resources available to a desktop OS (not that I was suggesting running Windows on a Helix!) Absolutely! That's what an OS does, resource allocation, and that is why it is all the more difficult with real-time (or near real-time) requirements like the Helix. I realize I sounded as if I was criticizing the way the Helix is engineered: I didn't mean to at all -- I was just making the point that it is theoretically possible and desirable, but that it is not necessarily feasible without overengineering, raising costs, prices and all things related. As a fairly steady Line6 returning customer, I don't think a bad engineering choice was made apart from leaving the on/off button out of the HD line. :) This was indeed the right choice, because now people at least have the ability to allocate resources manually to take advantage of both DSPs in a relatively, if not absolutely, transparent way. Joining the two paths in software is what I was missing from the X3 line.

This is true only in a situation (which is the present one) where you might use ALL THREE of them together. Bypassed processing blocks "eat" virtual resources only because they could be engaged at some point, and the modeler needs to know it can handle them in case. But switching amp channels means only one of them is active at any given time, so that would still be 40% in any case. The advantage over the present situation is that if you use the helix in stompbox mode, now you cannot effectively switch patches to switch channels (you'd lose all the engaged "stomp" to the new patch default), nor can you switch between channels easily, because, as you said, you need to have both of them in a patch, effectively throwing away about 40% processing power (unless you use both channels at once, in which case you have no other option). Still, it's true that that is commonplace, but with a specifically targeted implementation there'd be no DSP overhead, and I bet sooner or later someone will do it, advertising is as "multichannel amp simulation".

Actually having one "super path" does not automatically imply restriction. It implies, however, dynamic (at patch design time) resource allocation between the 2 DSPs to optimize the processing power consumed by the blocks added. From a software architecture standpoint, processing resources should be ideally virtualized -- you never tell your computer which processor (or core) to run a process or a thread on, the OS takes care of that for you. This ideal solution, however, means that the operating system is more complex, and virtualization of the resources adds a little overhead. There is little argument: a virtualized processing resource pool would be "better" from a patch programming standpoint. You'd never have to move bloks from one path to the other finding the optimal solution that accommodates them all within the available resource. It would however make the operating system cost more, be more complex (and therefore bug-prone), and it would probably "eat" away a little processing power (though not necessarily), it would certainly use more memory. I never really cared much for the "dual path" approach, as I mostly use "complex" single paths, but I always found the compromise acceptable considering that the alternative would have been an SMP OS. That would only make sense, I think, if these devices ran a full fledged OS like (embedded) windows, android (not being realtime it would be a challenge), or similar -- a significant change in how Line6 operates at the moment. I know a few keyboards that work that way. All in all, making things "right" at this stage would, I speculate, introduce many more headscratches than leaving the static DSP to path association. I believe things will change eventually in the future (not for the helix), but for the time being it seems like a perfectly working setting.

The question is very interesting beyond the "mere" amp modeling scenario, and more into an epistemological one. I believe in older days "amp sim" had a more holistic approach. I don't care WHY something sounds the way it sounds, I just want to recreate its sound. Hence, you'd record the amp as a whole, and made sure the signal transformation from input to recorded output was well approximated (fitted) by your model. I like the holistic approach, maybe because I come from artificial intelligence, and we gave up trying to make something "intelligent" a long time ago, trading for something that "behaves intelligently". The holistic approach has a few disadvantages -- namely, that parameters are hard to implement: it's easy to create a model for an amp on a specific setting, recorded by a specific mic in a specific position, it's difficult to create a generic model that varies along those parameters accurately. On the other hand, this "holistic" approach is based on minimal (if not zero) knowledge of what we're modeling: we need to know absolutely nothing of the amp. This is still very much in use -- think of IR -- that's exactly how that works. I cannot model a "space" or a cabinet, for the physical variables are impossible or very hard to master and take into account, so I just see how it reacts to an impulse. Or, think of the profiling of an amp that the Kemper does, that's the main idea behind it. At any rate, it seems that amp modeling moved more towards the "reverse engineering" and modeling components -- alas, from my perspective, losing the snobbish ivory-tower approach of "I don't care how that works. that's for electricians". I believe the first time I heard Line6 mentioning something along those lines was for the HD line. It amazes me that this approach actually pays off -- given how an amp is a very complex system, trying to reproduce it as a whole, even approximately, would seem to have a better chance at capturing its essence than decomposing it into bits whose sum might diverge significantly from the actual thing. So, not only am I wildly off topic, I am also wrong.

If you can leave both inputs connected, the above answer nails it. Otherwise, a small 4ch mixer will do!

I have used it on gigs five or six times, and never had an issue. Add about twice as many rehearsal sessions. I would say it's pretty stable -- though there have been reports of things going wrong, they seem to be fairly consistent with specific setups -- so if it doesn't give you problem at rehearsal, I'd feel pretty confident with it live.

Great tutorial. I'm curious about the IR, which is something I haven't started to dig in yet. I presume (though I might be wrong) that the stock cab models are based on IR themselves. Are 3rd party IR's like the one you use giving much better results, or is it just that they model your own preferred cab unavailable in stock?

Ah yeah, indeed. Dual cab was what I was looking for (didn't have the helix handy when the doubt stroke, and THERE IS NO SOFTWARE EDITOR...). I "converted" my patches splitting amp+cab into amp first, and dual cab much later, after stereo fx, each cab configured the same. I can't say that the difference is very noticeable, but I had a couple spare blocks in the bottom path, and the dual cab was accommodated easily, and I have now more options!

Very good point! Is there any way to apply a cabinet to a stereo signal without mixing down to mono? It will also suck up quite a bit of DSP power to have stereo cabs.

I'm almost embarrassed asking this, after being a Line6 user since the original pod. The question is simple: say you have a chorus (or even a spring reverb) fx. Normally that goes after the preamp, but before the cabinet/mic in a standard amp setting. I've always put those after an amp+cab block, in any pod, but it just dawned on me that a more "canonical" approach would be using: amp (no cab) -> fx -> cab instead of amp+cab -> fx ? I will experiment with this as soon as I can.

Absolutely. There shoud be a meter showing the signal level in and out of each block. I mean, when you select a block to change its parameters, an I/O signal meter would be extremely useful.

I added one, requesting that the global EQ page displays the EQ curve and the frequency analysis: http://line6.ideascale.com/a/dtd/DIsplay-EQ-curve-and-frequency-analysis-in-global-EQ-page/799253-23508 EDIT: I noticed that there was another submission asking, among other things, for this as well -- it's in the list as "Expanded Display for EQ and Compression Blocks"

Absolutely, though in fairness I was updating the unit, so in this case it wouldn't have made a difference... it was on a stool due to the USB cable not being long enough to reach the computer.

Yep, found those nuts for cheap and ordered a few -- both the neutrik and the cliffs will do, but they are a little different from the original ones, that have those little recesses... You know, in case of a resale... :) These will do nicely for the moment, I'm curious if anyone can locate the exact ones, if available at all.

Today while I was setting it up for the update, it fell from a foot high stool. It fell with the back connectors against a table leg. See picture: one of the little "crowns", the one around the exp3 connector, shattered and broke off. Admittedly, a fairly minor issue -- the plastic on those things is pretty weak, though. Can anybody suggest how to get a replacement? Don't even know the name for those things...

That largely depends on what other effects you plan on adding from the helix. Normally you'd have the crybaby upfront, then the pitch shifters, then tube screamer (or you could have the pitch shifters after the TS, according to taste). You could run them in front of the helix unless you need some compressors or early EQ. somewhere in there. I personally would lose the rev&delay, which can be replaced by what the helix has to offer, but in case, I'd put rev/dly and loop station at the end of the chain in an FX loop. I can't imagine any effect I'd put AFTER the loop station, but then I'm not very experimental.

As others mentioned, there might be many things involved. Get yourself acquainted with the fletcher-munson curve: at high volumes, bass and high frequencies tend to be percieved more prominently. Normally you can compensate for this in 2 ways: you enhance bass and high frequencies when at low volumes, so as to "mimic" the perception you get at higher volumes (i.e. the "loudness" switch found in many stereos) you tame bassand high frequencies when at high volumes. It is a little bit trial and error. That is way it is beneficial to tweak a tone at the level you normally want it played back.

I find my problem in a live setting is often the taming of bass frequencies. Even with lows almost off in the helix amp block, they are often a little overwhelming in a live setting for me, and for most rooms with poor acoustics that's very bad. Most of the times I just apply some low cut at the board and I'm good to go, but I pined for a global, post-everything eq ever since the POD XT -- was very happy when they added that to the HD. The Helix one is great -- it would be awesome if it displayed FFT analysis. Or, even better, if it could compensate for the room via a mic connected to the XLR in, as some system does, that would be way way cool. Anyway, yes, low cut around 150Hz is what I use the most.

It *is* a blend of the two, and a v. useful one esp. when you don't have to control very many effects per patch.

In stomp mode, the helix performs like a pedalboard. The most common configuration is to have a number of pedals configured, and normally 1 amp -- you then switch effects on and off by using the footswitches as you would with a traditional pedalboard. In preset mode you change the patch entirely, which reconfigures the "virtual" pedalboard (and/or the amp). Clearly, the two blend at extremes: in stomp mode you could turn amps on or off, of you could have 2 separate patches that only differ for an active stompbox in preset mode. The main application differences the way I see it are these: if you want to emulate a single amp + stomps setup, go for stompbox mode. That's what I do. By configuring 10 pedals, I have 2^10 sound configurations available in 1 patch (though many might be useless). If you want to change amp and effects (including the settings) altogether, rather than turn single effects on or off, go for preset mode. I do not like preset mode all that much especially because leveling patch volumes is always a lot of work. If you play a tribute/cover and are trying to recreate tones faithfully, preset mode is a must.

Will the software be accompanied with a dedicated hardware joystick that turns by itself thereby messing up your patch? If it doesn't, how could it be up to par with the physical interface! Just kidding. Editing on the helix is easy. That does not mean that on a computer the same task can't be made easier, and think of those using the reamp feature, for example -- they have no reason to reach for the unit while they work. That thing is supposed to stay on the floor. Also, but that's just a bonus, if the editor works without a unit connected, people could download it, try it out, and see (if not hear) what the helix could do for them if they bought one...