How is this DSP limited?

[willjrock]

Ive often felt there were occasions where Helix was limiting my choices even tho there was plenty of DSP left. IIRC i was getting 3 or 4 cabs to a path. I feel like it must have changed in an update along the way. I dont often use the native cabs so i can remember exactly, but helix is in fact reducing my options when there is more than enough DSP available, and im betting its the same for everyone.

So why when running this configuration 

 

 

 

why are we unable to select two dual cabinets or even one more single cab, when more than enough DSP still exists?.......and then some.

 

 

 

 

am i correct in remembering that Line 6 said that "our options are only dsp limited"?

 

At the very least one should be able to load TWO DUAL cabinets per path.

 

 

 

 

 

 

 

 

[silverhead]

.

 

.

 

 

why are we unable to select two dual cabinets or even one more single cab, when more than enough DSP still exists?.......and then some.

 

....

 

What makes you say that more than enough DSP still exists in this situation? My interpretation is that there is insufficient DSP remaining in Path 1, and that's why the selections are greyed out. I suspect you could add other less DSP intensive FX blocks in the Stomp/Mod/Del categories.

 

Remember that there's a whole other DSP processor available in Path 2.

[willjrock]

What makes you say that more then enough DSP still exists in this situation? My interpretation is that there is insufficient DSP remaining, and that's why the selections are greyed out.

Well i think its pretty common knowledge that IRs use more DSP that native cabinets, correct? In that same patch, I AM allowed to make choices that are more DSP intensive than native cabs. Look!

 

 

and even after loading two more IRs, i can still load fx on top of that.

[silverhead]

But you're talking about two dual cabinets; I guess they are very DSP intensive. Maybe you can use 4 IRs in a single path, maybe not - try it.

 

Anyway, it is what it is. Not sure what, if anything, you're asking for here.

[datacommando]

why are we unable to select two dual cabinets or even one more single cab, when more than enough DSP still exists?.......and then some.

Well, I just checked what your screen shots show and indeed, Helix has no more steam to add any more cabs.

That is the nature of the beast, and page 19 of the Owners Manual - Rev D give a run down of the rules governing the number and type of blocks you can add to a preset. It also gives tips for optimising DSP and an example of Super Serial paths. Super Serial is also included as a Template file in Helix in slot 01D.

Long time forum user "Honest Opinion" would be the go to guy for questions about DSP usage. He also uploaded a template file to CustomTone to help out.

http://line6.com/customtone/tone/1460280/

There was also a big discussion on here back in Feb 2016 which even has input from Digital Igloo on this subject.

http://line6.com/support/topic/18520-why-2-separate-dedicated-processing-paths-or-pools/

Hope this helps.

[willjrock]

Well for one i was lead to believe that options were only limited to DSP and/or  amount of block spaces available.

 

On top of that i vaguely remember being able to load 2 dual cabs in an earlier firmware. Thats whats causing most of my confusion.

 

...and lastly ive seen countless post telling users that they were out of DSP when that is clearly not always the case.

 

Not to mention the manual saying those choices are grey out because of insufficient DSP, and again not always the case.

 

I dont see a reason to not be able to load two dual cabs blocks.

[willjrock]

Well, I just checked what your screen shots show and indeed, Helix has no more steam to add any more cabs.

That is the nature of the beast, and page 19 of the Owners Manual - Rev D give a run down of the rules governing the number and type of blocks you can add to a preset. It also gives tips for optimising DSP and an example of Super Serial paths. Super Serial is also included as a Template file in Helix in slot 01D.

Long time forum user "Honest Opinion" would be the go to guy for questions about DSP usage. He also uploaded a template file to CustomTone to help out.

http://line6.com/customtone/tone/1460280/

There was also a big discussion on here back in Feb 2016 which even has input from Digital Igloo on this subject.

http://line6.com/support/topic/18520-why-2-separate-dedicated-processing-paths-or-pools/

Hope this helps.

Thanks DC. Appreciate the information. I'LL have a look.  Though id like to reiterate that it is not a matter of DSP 

It also gives tips for optimising DSP and an example of Super Serial paths.

 

[silverhead]

Well for one i was lead to believe that options were only limited to DSP and/or  amount of block spaces available.

 

On top of that i vaguely remember being able to load 2 dual cabs in an earlier firmware. Thats whats causing most of my confusion.

 

...and lastly ive seen countless post telling users that they were out of DSP when that is clearly not always the case.

 

Not to mention the manual saying those choices are grey out because of insufficient DSP, and again not always the case.

 

I dont see a reason to not be able to load two dual cabs blocks.

You're right - the options are limited by DSP and available block spaces. I'm not sure how this situation suggests otherwise. The manual is right - that's why the options are greyed out.

 

There may be some confusion about the meaning of options being greyed out. It does NOT mean that that you are absolutely out of DSP. It means there is insufficient remaining DSP for some DSP-intensive options like dual cabs, hence they are greyed out. The more DSP you use, the less DSP-consuming blocks you can add. But at any time the amount of remaining DSP IS sufficient for other options, and they remain available (not greyed out). It is virtually impossible to completely use 100% of available DSP. But the closer you get, the fewer remaining options you have until finally the remaining DSP is insufficient to add anything else - even the least DSP-consuming FX block - and then everything is greyed out.

 

So as you proceed to add blocks to presets, the most DSP-intensive blocks such as dual cabs are greyed out first. The last to be greyed out are the least DSP-intensive blocks.

 

The reason you are not able to load two dual cab blocks in your example IS that there is insufficient DSP.

[willjrock]

You're right - the options are limited by DSP and available block spaces. I'm not sure how this situation suggests otherwise. The manual is right - that's why the options are greyed out.

 

Because IRs use more DSP than native cabs. The patch allows a user to add two more IRs and multiple fx, yet it wont allow even one more native cab?  I shouldnt need to keep explaining this.

 

The reason you are not able to load two dual cab blocks in your example IS that there is insufficient DSP.

 

This is not true operating under the assumption that IRs use more DSP than helix native cabinets, which has been repeatedly expressed here, among other places.  Worst case scenario you should be able to load 3 native cabs per path.

 

Amp block >dual cab block>and another single cab block - on "Path A"  - which will not load -  equates to less DSP than 

 

Amp block> dual cab block >2048 IR ir block - which WILL load.

[willjrock]

@zooey

 

@HonestOpinion

 

Just interested to hear you guys take.

[Verne-Bunsen]

I'm pretty certain that Helix enforces a limit to the number of cabs you can have on a path regardless of actual DSP consumption. 2 Helix cabs or 1 dual cab, 2 1024 IRs or 1 2048 IR. This has been my experience consistently for the 14 months I've had Helix. I've had four cabs in a patch, but to do so you've got to use a dual cab on 1A, split upstream of it and run 1B down to 2A then split and run parallel cabs on 2A and 2B.

[datacommando]

On 5/14/2017 at 3:08 PM, willjrock said:

Well for one i was lead to believe that options were only limited to DSP and/or  amount of block spaces available.

 

On top of that i vaguely remember being able to load 2 dual cabs in an earlier firmware. Thats whats causing most of my confusion.

 

...and lastly ive seen countless post telling users that they were out of DSP when that is clearly not always the case.

 

Not to mention the manual saying those choices are grey out because of insufficient DSP, and again not always the case.

 

I dont see a reason to not be able to load two dual cabs blocks.

 

Will,

I don't know how you were lead to believe "that options were only limited to DSP and/or  amount of block spaces available."

I went back and looked at the very first issue of the "Helix 2.0 Owners Manual - Rev A - English" and then at the latest version, "Helix 2.0 Owners Manual - Rev D - English".

You correctly could remember being able to load 2 Dual Cabs in earlier Firmware, but that has always been the limit.

 

 

 

[willjrock]

I'm pretty certain that Helix enforces a limit to the number of cabs you can have on a path regardless of actual DSP consumption. 2 Helix cabs or 1 dual cab, 2 1024 IRs or 1 2048 IR. This has been my experience consistently for the 14 months I've had Helix. I've had four cabs in a patch, but to do so you've got to use a dual cab on 1A, split upstream of it and run 1B down to 2A then split and run parallel cabs on 2A and 2B.

Thanks appreciate your input.  That jars my memory free a bit :)

[willjrock]

Will,

I don't know how you were lead to believe "that options were only limited to DSP and/or  amount of block spaces available."

I went back and looked at the very first issue of the "Helix 2.0 Owners Manual - Rev A - English" and then at the latest version, "Helix 2.0 Owners Manual - Rev D - English".

You correctly could remember being able to load 2 Dual Cabs in earlier Firmware, but that has always been the limit.

See pics for clarification.

Nice find. Ok maybe im not remembering correctly, which i knew was entirely possible. My recollection was 4 cabs per path.....but now i am simply interested to understand why these selections arent applicable, since there is adequate DSP.  Just wondering.  From the cheap seats it seems like such a simple thing to implement. It sure would be nice to have the flexibility. I dont expect it to come to fruition. Esp since its been that way from the beginning. Just trying to understand that if its not being dictated by DSP then what? I know its not spite :P

[silverhead]

I'm pretty certain that Helix enforces a limit to the number of cabs you can have on a path regardless of actual DSP consumption. 2 Helix cabs or 1 dual cab, 2 1024 IRs or 1 2048 IR. This has been my experience consistently for the 14 months I've had Helix. I've had four cabs in a patch, but to do so you've got to use a dual cab on 1A, split upstream of it and run 1B down to 2A then split and run parallel cabs on 2A and 2B.

 

 

Will,

I don't know how you were lead to believe "that options were only limited to DSP and/or  amount of block spaces available."

I went back and looked at the very first issue of the "Helix 2.0 Owners Manual - Rev A - English" and then at the latest version, "Helix 2.0 Owners Manual - Rev D - English".

You correctly could remember being able to load 2 Dual Cabs in earlier Firmware, but that has always been the limit.

See pics for clarification.

 

 I stand corrected. Thanks for the info guys. It wasn't my intention to promulgate false info.

 

@willjrock - my apologies for any confusion I caused.

[datacommando]

 I stand corrected. Thanks for the info guys. It wasn't my intention to promulgate false info.

 

@willjrock - my apologies for any confusion I caused.

 

I don't think you need to be corrected.

Your observation about DSP allocation (as you proceed to add blocks to presets, the most DSP-intensive blocks such as dual cabs are greyed out first) were most accurate.

Always grateful for your knowledge and input, silverhead.

[willjrock]

 I stand corrected. Thanks for the info guys. It wasn't my intention to promulgate false info.

 

@willjrock - my apologies for any confusion I caused.

No, no. Your info was vital here for me. You were plenty correct in saying only two cabs could be loaded...but dammm why?  :P

[willjrock]

 I stand corrected. Thanks for the info guys. It wasn't my intention to promulgate false info.

 

@willjrock - my apologies for any confusion I caused.

......and then what would it take to employ? It would add greater flexibility and if there is minimal effort involved it seems like a no brainer IMO. Again, not knowing whats involved, seems like such a simple implementation. Nothing more than a choice. Thats why im puzzled.

[silverhead]

You're right - the options are limited by DSP and available block spaces. I'm not sure how this situation suggests otherwise. ...

 

....

 

The reason you are not able to load two dual cab blocks in your example IS that there is insufficient DSP.

These two of my statements are what needed correction. Apparently there IS a limit, regardless of DSP, of two cabs per path. That's what I wasn't aware of. Thanks again for the clarification.

 

Glad my observation about the mechanics of adding blocks, remaining DSP, and greyed out blocks was helpful.

[jeremyn]

There are hardware acceleration modules in the DSP that may be used by some blocks such as IRs and cabs. Once those modules are being used to capacity, no more can be used. This is orthogonal to general DSP processing. So this limit is probably not arbitrary, but related to DSP resources that don't sit on a linear single dimensional scale of 'DSP usage'.

[mdmayfield]

There are hardware acceleration modules in the DSP that may be used by some blocks such as IRs and cabs. Once those modules are being used to capacity, no more can be used. This is orthogonal to general DSP processing. So this limit is probably not arbitrary, but related to DSP resources that don't sit on a linear single dimensional scale of 'DSP usage'.

 

 

That's really interesting, and the first I've heard of it in context of the Helix. Where did you find that out?

[HonestOpinion]

datacommando, on 14 May 2017 - 09:50 AM, said:

Well, I just checked what your screen shots show and indeed, Helix has no more steam to add any more cabs.

That is the nature of the beast, and page 19 of the Owners Manual - Rev D give a run down of the rules governing the number and type of blocks you can add to a preset. It also gives tips for optimising DSP and an example of Super Serial paths. Super Serial is also included as a Template file in Helix in slot 01D.

Long time forum user "Honest Opinion" would be the go to guy for questions about DSP usage. He also uploaded a template file to CustomTone to help out.

http://line6.com/customtone/tone/1460280/

There was also a big discussion on here back in Feb 2016 which even has input from Digital Igloo on this subject.

http://line6.com/support/topic/18520-why-2-separate-dedicated-processing-paths-or-pools/

Hope this helps.

 

Thanks for the kind words but you guys seem to have this sussed this out pretty well. There do seem to be some rules that have been imposed by the Helix firmware rather than the apparent capacity of the DSP although it may well be that they are somehow informed or dictated by the Helix's DSP capacity, architecture, firmware, or hardware in some way that is not obvious to us.

 

There appear to be special rules regarding 2048 IRs and Helix dual cabs. You cannot add either a 1024 or a 2048 IR to a path with a 2048 IR already present nor can you add a dual or single cab to a path with a dual cab already present. You can however, for example, have (1)2048 IR / (2)1024 IRs + (1)Helix dual cab / (2)Helix single cabs on the same path. It seems you can mix and match cabs and IRs to get combinations that would appear to consume the same amount of DSP that would be consumed by for instance two Helix dual cabs on the same path(which is prohibited). This would seem, at least on the face of it, like a limitation or rules imposed by the firmware rather than the available DSP but I dare not assume too much as to the arcane machinations of the Helix alchemists.

 

 

Current max combinations of IRs/Cabs allowed on a single path in the 2.21 firmware

• One 2048 IR [No additional IRs, neither 1024 nor 2048, are allowed on a path that already contains a 2048 IR. You can add (1) Helix Dual cab or (2) Helix single cabs to a path with (1) 2048 IR.]
• One Helix dual cab [No additional Helix cabs, dual or single can be added to a path that already has a Helix dual cab. You can add (1) 2048 IR or (2) 1024 IRs]
• (2) 1024 IRs [a third 1024 IR is not allowed although additional Helix cabs are]
• (2) Helix single cabs [a third Helix cab is not allowed although additional IRs are]
• (1) 2048 IR + either (2) Helix single cabs or (1) Helix dual cab
• (2) 1024 IRs + either (2) Helix single cabs or (1) Helix dual cab

[Verne-Bunsen]

There are hardware acceleration modules in the DSP that may be used by some blocks such as IRs and cabs. Once those modules are being used to capacity, no more can be used. This is orthogonal to general DSP processing. So this limit is probably not arbitrary, but related to DSP resources that don't sit on a linear single dimensional scale of 'DSP usage'.

I'm pretty sure I remember Geordie La Forge saying this exact thing when Picard was inquiring about reconfiguring the forward phaser array...

[datacommando]

... but I dare not assume too much as to the arcane machinations of the Helix alchemists.

  

As ever, great observation and comments, HO.

 

I'm pretty sure I remember Geordie La Forge saying this exact thing when Picard was inquiring about reconfiguring the forward phaser array...

Verne, surely not Geordie, but Scottie said it to Jim. The dude used orthogonal, arbitrary, and linear single dimensional scale all in a single post. Beam me up! Where did I leave those dilithium crystals?

[jeremyn]

That's really interesting, and the first I've heard of it in context of the Helix. Where did you find that out?

I have no idea how the code has been written in the Helix, and I haven't ever coded for this series of Sharc. But, when creating certain complex DSP code segments it is sometimes useful to dedicate a section with hand coded 'modules' to use hardware as efficiently as possible. This usually involves preallocated methods of sharing L2 and L3 cache memory, and in some cases dedicated acceleration hardware that would cause too much latency if 'overloaded'.

 

I'm basically trying to say that 'DSP' isn't one giant pool of resource that can be used symmetrically for any purpose. It is composed of a number of orthogonal resources such as various types of memory, DMA engines, processing blocks, accelerators, etc. And not all functions (IRs, cabs, EQ, delay, reverb, synths, etc) use any/all blocks equally. So it is possible that one resource module is depleted by one set of Helix blocks and not by others.

[datacommando]

I'm basically trying to say that 'DSP' isn't one giant pool of resource that can be used symmetrically for any purpose. It is composed of a number of orthogonal resources such as various types of memory, DMA engines, processing blocks, accelerators, etc. And not all functions (IRs, cabs, EQ, delay, reverb, synths, etc) use any/all blocks equally. So it is possible that one resource module is depleted by one set of Helix blocks and not by others.

Wow! That has hurt my brain and I'll bet right about now "willjrock" is thinking that he wished he never asked how it all works! Careful what you wish for kiddies. Ho Lee Sheet!

 

Outstanding comments, jnysen!

[willjrock]

I have no idea how the code has been written in the Helix, and I haven't ever coded for this series of Sharc. But, when creating certain complex DSP code segments it is sometimes useful to dedicate a section with hand coded 'modules' to use hardware as efficiently as possible. This usually involves preallocated methods of sharing L2 and L3 cache memory, and in some cases dedicated acceleration hardware that would cause too much latency if 'overloaded'.

 

I'm basically trying to say that 'DSP' isn't one giant pool of resource that can be used symmetrically for any purpose. It is composed of a number of orthogonal resources such as various types of memory, DMA engines, processing blocks, accelerators, etc. And not all functions (IRs, cabs, EQ, delay, reverb, synths, etc) use any/all blocks equally. So it is possible that one resource module is depleted by one set of Helix blocks and not by others.

Thanks a ton! Couldnt have hoped for any better synopsis. Suddenly, it makes perfect sense.

 

right about now "willjrock" is thinking that he wished he never asked

 

I admit, i had to look up orthogonal :) ....and read the posts a couple of times :P ......but i definitely appreciate having the deeper reasoning explained here.

 

 

Thanks for the kind words but you guys seem to have this sussed this out pretty well. There do seem to be some rules that have been imposed by the Helix firmware rather than the apparent capacity of the DSP although it may well be that they are somehow informed or dictated by the Helix's DSP capacity, architecture, firmware, or hardware in some way that is not obvious to us.

 

There appear to be special rules regarding 2048 IRs and Helix dual cabs. You cannot add either a 1024 or a 2048 IR to a path with a 2048 IR already present nor can you add a dual or single cab to a path with a dual cab already present. You can however, for example, have (1)2048 IR/(2) 1024 IRs + (1) Helix dual cab/(2) Helix single cabs on the same path. It seems you can mix and match cabs and IRs to get combinations that would appear to consume the same amount of DSP that would be consumed by for instance two Helix dual cabs on the same path(which is prohibited). This would seem, at least on the face of it, like a limitation or rules imposed by the firmware rather than the available DSP but I dare not assume too much as to the arcane machinations of the Helix alchemists.

 

 

Current max combinations of IRs/Cabs allowed on a single path in the 2.21 firmware

• One 2048 IR [No additional IRs, neither 1024 or 2048, are allowed on a path that already contains a 2048 IR. You can add (1) Helix Dual cab or (2) Helix single cabs to a path with (1) 2048 IR.]
• One Helix dual cab [No additional Helix cabs, dual or single can be added to a path that already has a Helix dual cab. You can add (1) 2048 IR or (2) 1024 IRs]
• (2) 1024 IRs [a third 1024 IR is not allowed although additional Helix cabs are]
• (2) Helix single cabs [a third Helix cab is not allowed although additional IRs are]
• (1) 2048 IR + (2) Helix single cabs or (1) Helix dual cab
• (2) 1024 IRs + (2) Helix single cabs or (1) Helix dual cab

 

 

 

Thank you for taking a second here, with your always valued input. 

[HonestOpinion]

I have no idea how the code has been written in the Helix, and I haven't ever coded for this series of Sharc. But, when creating certain complex DSP code segments it is sometimes useful to dedicate a section with hand coded 'modules' to use hardware as efficiently as possible. This usually involves preallocated methods of sharing L2 and L3 cache memory, and in some cases dedicated acceleration hardware that would cause too much latency if 'overloaded'.

 

I'm basically trying to say that 'DSP' isn't one giant pool of resource that can be used symmetrically for any purpose. It is composed of a number of orthogonal resources such as various types of memory, DMA engines, processing blocks, accelerators, etc. And not all functions (IRs, cabs, EQ, delay, reverb, synths, etc) use any/all blocks equally. So it is possible that one resource module is depleted by one set of Helix blocks and not by others.

 

 

Wow! That has hurt my brain and I'll bet right about now "willjrock" is thinking that he wished he never asked how it all works! Careful what you wish for kiddies. Ho Lee Sheet!

 

Outstanding comments, jnysen!

 

Wow, no kidding datacommando, that is one impressive post by jnysen and potentially sheds a bit of high level light on why the max cab/IR combination rules operate the way they do!

[jeremyn]

Sorry for the overly technical posts, as an electronics & signal processing engineer I do a lot of DSP programming on other platforms. There are so many variables when designing efficient DSP code that it is actually quite difficult to do things like putting up a single 'DSP indicator' bar. Putting up multiple bars would likely just confuse users.

 

I can see why people get confused about these things. Here's some more relevant technical info for those interested:

 

On a desktop running DAW plugins, the operating system abstracts all the hardware interface complexity which means code is written more generically. This causes adding extra plugins to progressively load up the processor until eventually it can't keep up, and you get clicks/pops. Latencies are also higher, which means the overheads can be minimised when breaking up tasks into bigger chunks that might take 5ms+ to run per 'time slice'. Whereas, the Helix is aiming for minimal latency and can't afford the overhead of chopping in and out of a memory intensive 'process' without wasting processing time with an extremely short 'time slice'.

 

For example in a 1 second period, a desktop machine with a 5ms time slice would copy in/out of cache memory 200 times. Whereas a low latency platform would need an extremely short time slice of 0.1ms of faster, which would end up with 10000 copies in/out per second. To avoid this whole issue, DSP code is usually implemented with a 'round robin' processing loop that calls various sub-tasks that all must return in a defined amount of time, and are precoded to only use a certain subset of resources to avoid copying things in and out of 'fast' memory. I've run systems that had sub-sub-tasks that shared a block of 'fast' memory for higher latency operations (eg. long tail reverbs) that can be 'chunked' into larger timed blocks (eg. 10ms chunks). But, even that is complicated and can cause hard to predict resource starvation. A lot of fun can be had in this area, but it gets really complicated and people can easily get confused when the end functionality seems exactly the same as a DAW, even though it has a completely different implementation under the hood.

 

I'm excited to see what Line 6 have done for the Helix Native application. There are likely to be a lot of external similarities with a lot of differences under the hood, as a desktop and a DSP platform are usually optimised very differently.

[HonestOpinion]

...

That is the nature of the beast, and page 19 of the Owners Manual - Rev D give a run down of the rules governing the number and type of blocks you can add to a preset. It also gives tips for optimising DSP and an example of Super Serial paths. Super Serial is also included as a Template file in Helix in slot 01D.

...

At the risk of being redundant I just wanted to list the rules from the Helix manual that datacommando referenced along side the ones I posted as they complement each other and the ones from the manual are written quite clearly (thank you Helix documentation person). The ones I posted are in essence a superset of the ones from the manual as they paraphrase the manual (unintentionally, thanks dc, I had not looked at those in a long time) but also include the current limits on combining cabs and IRs. I suppose you could infer those combinations from the Helix manual although they are not listed explicitly but I came to them the long way, through experimentation.

 

Off-topic note: I laughed when I saw the point in the Helix documentation regarding only having one looper. I tried a while back to do an experiment with one looper block at the beginning of the signal chain and one at the end. No go, no matter how little other DSP the preset was using! I did eventually figure out that there was a one looper per preset limit but just remembering that from the manual would have been easier, RTFM.

 

From the Helix manual:

Amp+Cab, Amp, or Preamp blocks Any combination, up to four (two per path)

Cab blocks (includes Amp+Cab blocks) Up to four (two per path; Cab > Dual blocks are considered two)

Impulse Response blocks Up to four 1024-point IRs (two per path) or two 2048-point IRs (one per path)

Looper block: One

 

 

Current max combinations of IRs/Cabs allowed on a single path in the 2.21 firmware

• One 2048 IR [No additional IRs, neither 1024 nor 2048, are allowed on a path that already contains a 2048 IR. You can add (1) Helix Dual cab or (2) Helix single cabs to a path with (1) 2048 IR.]
• One Helix dual cab [No additional Helix cabs, dual or single can be added to a path that already has a Helix dual cab. You can add (1) 2048 IR or (2) 1024 IRs]
• (2) 1024 IRs [a third 1024 IR is not allowed although additional Helix cabs are]
• (2) Helix single cabs [a third Helix cab is not allowed although additional IRs are]
• (1) 2048 IR + either (2) Helix single cabs or (1) Helix dual cab
• (2) 1024 IRs + either (2) Helix single cabs or (1) Helix dual cab

[willjrock]

Sorry for the overly technical posts, as an electronics & signal processing engineer I do a lot of DSP programming on other platforms. There are so many variables when designing efficient DSP code that it is actually quite difficult to do things like putting up a single 'DSP indicator' bar. Putting up multiple bars would likely just confuse users.

 

I can see why people get confused about these things. Here's some more relevant technical info for those interested:

 

On a desktop running DAW plugins, the operating system abstracts all the hardware interface complexity which means code is written more generically. This causes adding extra plugins to progressively load up the processor until eventually it can't keep up, and you get clicks/pops. Latencies are also higher, which means the overheads can be minimised when breaking up tasks into bigger chunks that might take 5ms+ to run per 'time slice'. Whereas, the Helix is aiming for minimal latency and can't afford the overhead of chopping in and out of a memory intensive 'process' without wasting processing time with an extremely short 'time slice'.

 

For example in a 1 second period, a desktop machine with a 5ms time slice would copy in/out of cache memory 200 times. Whereas a low latency platform would need an extremely short time slice of 0.1ms of faster, which would end up with 10000 copies in/out per second. To avoid this whole issue, DSP code is usually implemented with a 'round robin' processing loop that calls various sub-tasks that all must return in a defined amount of time, and are precoded to only use a certain subset of resources to avoid copying things in and out of 'fast' memory. I've run systems that had sub-sub-tasks that shared a block of 'fast' memory for higher latency operations (eg. long tail reverbs) that can be 'chunked' into larger timed blocks (eg. 10ms chunks). But, even that is complicated and can cause hard to predict resource starvation. A lot of fun can be had in this area, but it gets really complicated and people can easily get confused when the end functionality seems exactly the same as a DAW, even though it has a completely different implementation under the hood.

 

I'm excited to see what Line 6 have done for the Helix Native application. There are likely to be a lot of external similarities with a lot of differences under the hood, as a desktop and a DSP platform are usually optimised very differently.

I hope you'll jump in on my next thread. It may seem elementary to you, and is out of the coding realm, but i think with your background you'll be able to provide valuable insight. Thanks again here.

[datacommando]

At the risk of being redundant I just wanted to list the rules from the Helix manual that datacommando referenced along side the ones I posted as they complement each other and the ones from the manual are written quite clearly (thank you Helix documentation person).

Helix documentation person - AFAIK that would be Eric, (Digital Igloo).

 

And, if Eric spots this thread, maybe he will sign up "jnysen" to the Line 6 team - someone with an extensive knowledge of DSP stuff, it seems.

[HonestOpinion]

Helix documentation person - AFAIK that would be Eric, (Digital Igloo).

 

And, if Eric spots this thread, maybe he will sign up "jnysen" to the Line 6 team - someone with an extensive knowledge of DSP stuff, it seems.

 

Thanks, I didn't realize DI did the documentation, he is excellent at it and that is a rare skill! Something tells me jnysen could have his pick of tech jobs, I am just happy we have him as a resource on the forum and I concur with willjrock, please chime in any time. I learned a lot about DSP thanks to this topic, glad it was posted.

[datacommando]

Thanks, I didn't realize DI did the documentation, he is excellent at it and that is a rare skill! Something tells me jnysen could have his pick of tech jobs, I am just happy we have him as a resource on the forum and I concur with willjrock, please chime in any time. I learned a lot about DSP thanks to this topic, glad it was posted.

Oops!

Clarifiacation required!

IIRC, DI was actually a co-author of the Helix Owners Manual.

Sorry for any confusion caused.

[Zaiten]

what about multiple harmonizers, pitch-shifters and octavers, how many does the Helix DSP handle simultaneously spread on all four chain paths? how many along with an amp/cab/IR? 

[zooey]

Specific DSP amounts used by each block aren't listed. Helix just won't let you add blocks there's not room for.