Why isn't the Matchless one model instead of 3?

[amsdenj]

It's great to have the Matchless, and similar normal/bright, etc. channels of the same amp modeled. But The Line 6 approach of using a different amp model for each one seems sub-optimal. What I'd rather see is a single amp model with additional parameters for bright on/off, channel switching, tone voicing switches, etc. Then we could create footsitch mappings to control parameters in a single amp model instead of having to switch patches to get differen settings on essentially the same amp. This makes more efficient use of patches and block memory as there's less duplication of models.

 

The motivation for this is to get more flexibility from a single patch, reducing the need for scenes and multiple patches. It simplifies using Helix live, and let's us focus more on connecting to and understanding our amp rather than jumping from model to model, never really getting to know the details of a single amp.

[glideman]

This is where scenes would probably come into play...

[HonestOpinion]

This does strike me as a superior approach and more in keeping with the way Line6 claims to be modeling the actual components of the amps. Splitting amp channels up not only pushes the user farther away from an authentic amp experience but demands way more DSP if you want to be able to switch between the channels. Depending on what else you have in your preset there may not even be enough DSP to put say the clean, crunch, and lead version of the amp in the preset. This currently would require three different preamps.

[HonestOpinion]

This is where scenes would probably come into play...

 

Yes! Scenes, when will they arrive?

[glideman]

If they do ever arrive, I would imagine it will take awhile.

[duncann]

I believe Fractal Audio treats amp channels like this as well. Seeing as how each channel is a separate model, how would any modeler out there be able to load three different amps in one patch, which is what would have to happen if all three channels are contained in "one amp". Helix can do this, but there'd be hardly any DSP left over for anything else.

[Inerzia]

Well, yes, it would be a bigger DSP load, but the power amp section would still be the same, so it would be like loading a full amp model and two preamps, and that's if they can't share any other resources among them.
Anyway, I think this approach is so different to what Helix does (and others do) that we won't, probably, be seeing it implemented any time soon.
Maybe in two or three years? And most likely not as an update for the Helix, but maybe an incentive to buy the next gen processor.

[HonestOpinion]

I believe Fractal Audio treats amp channels like this as well. Seeing as how each channel is a separate model, how would any modeler out there be able to load three different amps in one patch, which is what would have to happen if all three channels are contained in "one amp". Helix can do this, but there'd be hardly any DSP left over for anything else.

 

It does seem to be the common approach among all the modelers. Wonder why this is? Probably another limitation imposed by the current software/hardware paradigm. I am pretty sure self-contained multi channel amps will come with future modeling generations.

[mjorden]

Switching between patches is still unusable in a live situation. Frustrating. I get you can build complex patches to accomplish a lot within one patch but for a $1500 unit you shouldn't have to create workarounds.

[Digital_Igloo]

It does seem to be the common approach among all the modelers. Wonder why this is? Probably another limitation imposed by the current software/hardware paradigm. I am pretty sure self-contained multi channel amps will come with future modeling generations.

 

It's absolutely a DSP thing. If one amp channel takes up, say, 40% of a path/DSP, two amp channels might take up 60-70%, and three might push you to 80-90%. For the vast majority of people who only use one amp channel per preset, two channels they'll never use just wasted half their horsepower.

 

And for what reason? Fewer items to scroll through in the model list? Turning the model joystick is just as easy as turning some imaginary "Channel" parameter knob.

[HonestOpinion]

It's absolutely a DSP thing. If one amp channel takes up, say, 40% of a path/DSP, two amp channels might take up 60-70%, and three might push you to 80-90%. For the vast majority of people who only use one amp channel per preset, two channels they'll never use just wasted half their horsepower.

 

And for what reason? Fewer items to scroll through in the model list? Turning the model joystick is just as easy as turning some imaginary "Channel" parameter knob.

 

I guess the hope was that simply by  changing the parameters on an already loaded "multi-channel amp", you would have potentially several channels available and avoid having to flip from one preset to another.  I have no idea what the technical challenges are currently, but if the Helix amp models are based on models of the circuits, the DSP and memory changes might be minimal  as most of the modeled circuits in the amp might already be in play. I guess in a way taking the same approach to amp channel switching that some MFX take to spillover by reusing the same reverb with the same paraameters for example across presets. Except in this case you would be reusing the same modeled amp components, but within one preset. This would hopefully result in a DSP savings over the more costly current process of loading multiple preamps with redundant modeled circuitry. Being able to have a multi-channel amp in one preset would not only enable spillover and avoid the latency associated with a preset change but also be an experience more akin to a multi-channel amp in the real world. No more sorting through several amp channels in the amps models list, just load up the amp of your choice and all the channels would be available within that preset. Perhaps a more elegant and intuitive process and one that I am sure is headed our way at some point down the line. Of course, everyone also loves to mix and match amps within a preset so the current separating out of channels is perhaps a DSP savings and more beneficial when you want to mix and match. Maybe eventually when DSP and memory is cheaper and more abundant we will see both styles, the separate amp channels and also a multi-channel amp option. I just wonder if this notion of "amp circuit spillover" could be implemented sooner. I can see benefits to both approaches, separate channels and multi-channels.

[Digital_Igloo]

When memory is cheap and DSP is more powerful, we'll still be having this conversation because any headroom will forever be eaten up by more granular and even better-sounding modeling. Having extra amp channels just sitting there waiting to be enabled, eating up DSP for no reason, should never happen in embedded systems. If for whatever reason it does, that just means you're wasting horsepower that could be used for more effects or better-sounding models.

 

Computers have no problem with background usage because they sacrifice throughput latency for cycles. Crank your buffers way up and you can run an ungodly amount of amp sim channels at once. But try to play through those plugins in real time, and the latency'll kill ya.

 

On a peripherally related note, Helix will never have a global looper, because when more than half of your customers never touch the looper, it's asinine to force everyone to waste 4-7% of a DSP on it when that 7% could go toward an extra delay—or choosing a better-sounding delay model that wouldn't otherwise have enough DSP to load.

[HonestOpinion]

When memory is cheap and DSP is more powerful, we'll still be having this conversation because any headroom will forever be eaten up by more granular and even better-sounding modeling. Having extra amp channels just sitting there waiting to be enabled, eating up DSP for no reason, should never happen in embedded systems. If for whatever reason it does, that just means you're wasting horsepower that could be used for more effects or better-sounding models.

 

....

 

I know we have a different vision of the future evolution of DSP/memory (albeit you are the expert on the topic) but what about the concept of "amp circuit spillover" or in other words the elimination of redundant code and processing for multiple channels on the same amp? Is that a software solution that might potentially use less DSP and be something that could be implemented on the current hardware?

[Digital_Igloo]

I know we have a different vision of the future evolution of DSP/memory (albeit you are the expert on the topic) but what about the concept of "amp circuit spillover" or in other words the elimination of redundant code and processing for multiple channels on the same amp? Is that a software solution that might potentially use less DSP and be something that could be implemented on the current hardware?

I could possibly imagine a scenario where the user would be forced to manually load multiple channels and whatever "amp circuit spillover" could intelligently kick in. But to make multiple channels load by default (even if it's only 5% more DSP) when the majority of people only use one channel is still a waste. Any DSP waste is always frowned upon in dynamic, embedded DSP circles.

 

That said, fixed and semi-fixed DSP solutions are always wasting DSP in the interest of simplicity, ease-of-use, and ease-of-development, but in those cases, the products would almost certainly be artificially restricted to one amp channel (and likely one gate, comp, distortion, mod, delay, and reverb), so the point is moot.

[HonestOpinion]

I could possibly imagine a scenario where the user would be forced to manually load multiple channels and whatever "amp circuit spillover" could intelligently kick in. But to make multiple channels load by default (even if it's only 5% more DSP) when the majority of people only use one channel is still a waste. Any DSP waste is always frowned upon in embedded, dynamic DSP circles.

 

That said, fixed and semi-fixed DSP solutions are always wasting DSP in the interest of simplicity, ease-of-use, and ease-of-development, but in those cases, the products would almost certainly be artificially restricted to one amp channel (and likely one gate, comp, distortion, mod, delay, and reverb), so the point is moot.

Man do I get your point about simplicity and ease of use, I have often seen the best or most efficient technical approach sacrificed for those goals. If most people only use one channel then the effort certainly isn't justified, but if a significant number of people are going to try and cram multiple channels from the same amp into a preset anyway, then perhaps as you say, even if the channels are still loaded separately, there would be a way to optimize them (reduce the code and load if they are all from the same amp), or in my way of thinking just consolidate them into one amp. Anyway, I feel like a medicine man waving a sprig of witchhazel over the crops for a better harvest. I have no idea idea how you fellows over in the lab grow the Helix, just advocating for a feature that another has suggested and I would love to see. Thanks for taking the time to respond.

[glideman]

I guess the biggest issue for some is latency switching between presets.

[PeterHamm]

No spillover, just like the Axe FX II. Yes. Right decision.

 

I build patches that use every ounce of the horsepower in this unit.

I'm so glad they didn't put spillover in there, because it would have meant I would be more limited.

Honestly, the whole multi-amp channel thing can easily be accomplished with one model and a footswitch, switching between two different settings of the same model, and even adding in the Timmy or Klon or something, or an eq.

[fukuri]

Allow me to change the Variax mid flight and I'm with you

But I can't so Im stuck with multiple patches and a horrible jarring gap when I switch

[lawrence_Arps]

Switching between patches is still unusable in a live situation. Frustrating. I get you can build complex patches to accomplish a lot within one patch but for a $1500 unit you shouldn't have to create workarounds.

Switching between patches is still unusable in a live situation in some very rare and unlikely circumstances....for the vast majority of users its great!

[fukuri]

For those users it's a big deal though

And I disagree with rare and unlikely, where are you getting that from?

Have you done a poll? Do you have access to research ?

So if it works fine for you great ... Tell us so and move on

Don't presume to speak for the vast majority of users because you don't

[tommasi]

It's absolutely a DSP thing. If one amp channel takes up, say, 40% of a path/DSP, two amp channels might take up 60-70%, and three might push you to 80-90%.

 

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".

[Digital_Igloo]

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).

 

Doesn't matter; if any portion of any model is to be engaged (or "switched") seamlessly with no gap or delay, it needs to be loaded into, and therefore eat up DSP. This means any amp model elements beyond what's required for a single channel will require more DSP than that channel alone.

 

While it's true that two separate amp models—one for each channel of the same amp—may take up more DSP than a single "multichannel" model containing shared elements for both channels, we'd likely be looking at some weird new "Multichannel Amp" subcategory, containing combinations of channels so everyone can optimize their DSP usage: Channels 1 and 2, Channels 2 and 3, Channels 1 and 3, and Channels 1, 2, and 3. And then of course the people who want a Marshall and a Fender to be considered separate channels (a more common use case than channels of the same amp) within the same "Multichannel Amp" model are out of luck. In my opinion, if a feature takes longer than a paragraph to explain to your average guitarist, it's a bad user experience.

[HonestOpinion]

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".

 

 

Doesn't matter; if any portion of any model is to be engaged (or "switched") seamlessly with no gap or delay, it needs to be loaded into, and therefore eat up DSP. This means any amp model elements beyond what's required for a single channel will require more DSP than that channel alone.

 

While it's true that two separate amp models—one for each channel of the same amp—may take up more DSP than a single "multichannel" model containing shared elements for both channels, we'd likely be looking at some weird new "Multichannel Amp" subcategory, containing combinations of channels so everyone can optimize their DSP usage: Channels 1 and 2, Channels 2 and 3, Channels 1 and 3, and Channels 1, 2, and 3. And then of course the people who want a Marshall and a Fender to be considered separate channels (a more common use case than channels of the same amp) within the same "Multichannel Amp" model are out of luck. In my opinion, if a feature takes longer than a paragraph to explain to your average guitarist, it's a bad user experience.

 

One thing that has been consistently bothering me in these discussions of DSP usage has been that they do not jibe with my experience with how program execution works. In my experience with other software, when we want things to run more swiftly, we preload them into memory, not into the processor, or in this case, not into the DSP. Processor usage does not begin until a feature is actually in play and being used.  I can understand where we would require more memory to load a "mult-channel" amp but not where it would necessarily require more DSP as only the channel you have selected, just like any single channel amp model in the existing single channel architecture, would actually require processing. I understand on the Helix that essentially everything is in memory as it does not have a hard drive but often with this kind of architecture there is an area of memory, sometimes faster memory, that essentially acts as the staging area for what will be processed.

[Digital_Igloo]

One thing that has been consistently bothering me in these discussions of DSP usage has been that they do not jibe with my experience with how program execution works.

 

Embedded DSP firmware is not like UNIX/Windows software.

[PeterHamm]

...While it's true that two separate amp models—one for each channel of the same amp—may take up more DSP than a single "multichannel" model containing shared elements for both channels, we'd likely be looking at some weird new "Multichannel Amp" subcategory, containing combinations of channels so everyone can optimize their DSP usage: Channels 1 and 2, Channels 2 and 3, Channels 1 and 3, and Channels 1, 2, and 3. And then of course the people who want a Marshall and a Fender to be considered separate channels (a more common use case than channels of the same amp) within the same "Multichannel Amp" model are out of luck. In my opinion, if a feature takes longer than a paragraph to explain to your average guitarist, it's a bad user experience...

 

Incidentally, this was the way the Vox Tonelab SE worked (it was an awesome product in its day about 10 years ago). You had your signal chain, and there was a channel button for two different amps. IIRC, not at the same time, only one.

 

But...

 

I need all the processing that the Helix affords me and I come within spitting distance of maxing out the DSP on every patch. The last thing I want is to either a.) not have a Helix, because they decided to add spillover and it added 500 bucks to the price and it failed in the marketplace... or b.) to have spillover within this unit's parameters and have significantly less processing power than I have now... I don't think there is an option C.

 

And... again... the Axe FX doesn't have spillover either.

[tommasi]

Embedded DSP firmware is not like UNIX/Windows software.

[tommasi]

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.

[HonestOpinion]

...

 

While it's true that two separate amp models—one for each channel of the same amp—may take up more DSP than a single "multichannel" model containing shared elements for both channels, we'd likely be looking at some weird new "Multichannel Amp" subcategory, containing combinations of channels so everyone can optimize their DSP usage: Channels 1 and 2, Channels 2 and 3, Channels 1 and 3, and Channels 1, 2, and 3. And then of course the people who want a Marshall and a Fender to be considered separate channels (a more common use case than channels of the same amp) within the same "Multichannel Amp" model are out of luck. In my opinion, if a feature takes longer than a paragraph to explain to your average guitarist, it's a bad user experience.

 

 

...

 

I need all the processing that the Helix affords me and I come within spitting distance of maxing out the DSP on every patch. The last thing I want is to either a.) not have a Helix, because they decided to add spillover and it added 500 bucks to the price and it failed in the marketplace... or b.) to have spillover within this unit's parameters and have significantly less processing power than I have now... I don't think there is an option C.

 

And... again... the Axe FX doesn't have spillover either.

 

I agree, I do not want to sacrifice flexibility or see a significant increase in the Helix price for the sake of spillover.  I am not sure however that there is not an option "C". DI hinted in earlier posts that there may possibly be some strategies down the road to give a limited form of spillover between presets. The focus of this topic has not been inter-preset spillover however but whether or not a "multi-channel" amp could be implemented in a single preset in a way that would actually use less DSP than loading several single channels. This would be a great option if it is technically possible. Additionally, I don't think it would be confusing to users.  I can even potentially see some mix and match "multi-channel" amp options, for example a clean channel based on a Fender twin with a lead channel based on a Soldano, although  I would think mix & match multi-channel amps would use up more memory/DSP as they would have different amp circuits modeled. As always I think the Helix community provides thoughtful discussions on these issues and prevents us from running too far down the rathole. I think some of these ideas may make their way into the current Helix and some provide food for thought for future Helix generations.

[HonestOpinion]

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.

 

Thanks very much for the technical details on how DSPs operate vs. a conventional CPU/GPU. I did do some reading up on DSP operation and I see that they do indeed store the program as well as data so I can see where the analogy to a CPU is not necessarily apples to apples although comparisons probably are appropriate in some limited respects. I will absolutely keep the differences in mind in future discussions. I clearly need to get better informed on how DSP works, it is still a bit of a mystery to me.

[HonestOpinion]

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".

 

+1

[Perfect]

Switching between patches is still unusable in a live situation in some very rare and unlikely circumstances....for the vast majority of users its great!

If only. I've already found the patch switching lag to be an intrusive problem with the Helix at rehearsal and I'm sticking with gigging my older (but virtually instant patch changing) Line 6 gear for now. I came perilously close to returning the Helix because of this issue and trust that I don't end up regretting sticking with it in the expectation that Line 6 will address/improve the issue.