Running out of DSP with 2 Amps...

[haller88]

Got a question and I am afraid the answer is not going to be good...

 

I am using a great stereo output effects box through my FX loop that sounds awesome in front of the amp/cab so I would like to create two paths to maximize DSP usage. I create a Path 2A and Path 2B. I am assuming that when people say that the DSP are used for Path 1 and 2 -> they really mean Path 2A and 2B? I get close to being able to manage DSP except I find I would like a reverb unit at the end of ther signal path -> I always run out of DSP if I put the reverb at the end of the chain even if I remove mostly everything before it. I can put the reverb early in the path but this sounds poor instead of later in the chain. The other thing I would like to do then is to move the one amp/cab combination early in the chain so that I could move the reverb later in the food chain but I run out of DSP doing some logical moves. It really appears as though we are quite limited in what we can move where so that I could have a decent signal chain with my stereo effect early in the chain.

 

Does anyone have an great tricks for squeezing as much as possible from the DSP?

 

Is there a Path 1 I don't know about?

 

- I am pretty close to abandoning this but it seems very whacked out that I can't this to work with the money the Helix cost etc... 

[c00lkatz]

You have path 1 and path 2. These are your 2 main paths. Each path can be split up. Path 1 becomes path 1A and path 1B. This represents one processor. The lower path below the dashed line in the middle of the screen is path 2, which can be split up into path 2A and path 2B. This represents the other processor. If you're running out of DSP in path 1, then move some things to path 2 and route path 1 into path 2.

 

For example if you have 2 amps in path 1 (either 1A and/or 1B) and want to add a reverb but don't have enough DSP left in path 1, then route the output of path 1 into path 2 and place your reverb on path 2.

 

You should post a screenshot of your patch so we may better see what it is you're trying to accomplish.

[haller88]

I attached a screenshot of where I am in the patch. It would work if I could move the verb to the end of the signal path but it seems to be an impossibility.

 

I think the main issue is using IR in the signal path. If I switch to Line 6 cabs -> it seems like I have a better shot and will try that but I think I have reached the limitation... 

 

[haller88]

Now I am perplexed -> it appears that Path 2 has a dramatically lower amount of DSP! I put one set of cabs on Path 1 and one on Path 2. I can load up a number of effects and a reverb block on Path 1 but can only have the amp/cab and some digital delays and soem other lower level block on Path 2. I deleted all of the blocks except for the amp/cab and I still can't move the reverb to Path 2!

 

I included another screenshot - help!

[evh0u812]

Just out of interest you cant 'move' the reverb from one path to the other. You have to cut and paste it.  

[malhavok]

it appears that Path 2 has a dramatically lower amount of DSP!

 

 

This is incorrect. Path 2 has more DSP than path 1 due to DSP 1 having the responsibility to also run the Helix OS. Not all amp models use the same amount of DSP (nor do each speaker, mic, or fx block). The actual DSP cycles available are quite high, but the practical number of blocks you can use is often quite limited (especially when using multiple amps). I have successfully made three and four amp patches so I know it is possible to squeeze lots out of the unit. You have to get very creative in your routing and fx choices.

[phil_m]

Third party IRs use more DSP than the built-in cabs, especially if you're using the 2048 sample versions. Some amp models use more DSP than others. My suspicion is that the IRs and the amps are just using a lot of resources.

[haller88]

evh0u812 - I did attempt to copy and paste in addition to dragging (it would be nice if dragging worked from a usability standpoint!

 

malhavok - that is quite interesting and may point out that there is something in the protocol that is odd! I could have one chorus, two delays and two compressors along with an amp and IR on path two and under no circumstances be able to move the verb to the second path. I then deleted everything on the second path and put just an amp, a Line 6 cabinet only on the second path and still could move the verb to the second path...

 

phil_m - I was using a 2048 IR -> see the previous comment - I went to no IR and nothing on the second path and still couldn't do anything...

 

My conclusion is that there is probably some bug in the code for the second path and how it manages DSP. I had Path 1 loaded up and had no issues except being able to copy an amp into Path 1. For now, unless someone comes up with a silver bullet - I am assuming defeat due to memory management issues beyond my ability to understand routing. It would be awesome to see how much memory each block takes and total memory per path to be able to debug this issue. Maybe Line 6 has a debug display where I could figure this one out. Another frustration on a unit that has great sound...

[phil_m]

evh0u812 - I did attempt to copy and paste in addition to dragging (it would be nice if dragging worked from a usability standpoint!

 

malhavok - that is quite interesting and may point out that there is something in the protocol that is odd! I could have one chorus, two delays and two compressors along with an amp and IR on path two and under no circumstances be able to move the verb to the second path. I then deleted everything on the second path and put just an amp, a Line 6 cabinet only on the second path and still could move the verb to the second path...

 

phil_m - I was using a 2048 IR -> see the previous comment - I went to no IR and nothing on the second path and still couldn't do anything...

 

My conclusion is that there is probably some bug in the code for the second path and how it manages DSP. I had Path 1 loaded up and had no issues except being able to copy an amp into Path 1. For now, unless someone comes up with a silver bullet - I am assuming defeat due to memory management issues beyond my ability to understand routing. It would be awesome to see how much memory each block takes and total memory per path to be able to debug this issue. Maybe Line 6 has a debug display where I could figure this one out. Another frustration on a unit that has great sound...

Does this happen on the unit itself as well as with the editor? Have you tried just doing it on the unit while not connected to the editor?

[jbuhajla]

evh0u812 - I did attempt to copy and paste in addition to dragging (it would be nice if dragging worked from a usability standpoint!

 

malhavok - that is quite interesting and may point out that there is something in the protocol that is odd! I could have one chorus, two delays and two compressors along with an amp and IR on path two and under no circumstances be able to move the verb to the second path. I then deleted everything on the second path and put just an amp, a Line 6 cabinet only on the second path and still could move the verb to the second path...

 

phil_m - I was using a 2048 IR -> see the previous comment - I went to no IR and nothing on the second path and still couldn't do anything...

 

My conclusion is that there is probably some bug in the code for the second path and how it manages DSP. I had Path 1 loaded up and had no issues except being able to copy an amp into Path 1. For now, unless someone comes up with a silver bullet - I am assuming defeat due to memory management issues beyond my ability to understand routing. It would be awesome to see how much memory each block takes and total memory per path to be able to debug this issue. Maybe Line 6 has a debug display where I could figure this one out. Another frustration on a unit that has great sound...

Try starting another patch from scratch with your new way of splitting it up. One time I started a patch that got too DSP heavy and tried deleting blocks to free some up. For some reason, the block choices were still "greyed out" and could not be selected. I started a new patch from scratch and all was good. 

[hideout]

This is incorrect. Path 2 has more DSP than path 1 due to DSP 1 having the responsibility to also run the Helix OS.

If that's the case, then since most users will for the most part be using Path1 first because it's right there and on top, why did Little ne6 not assign the OS to the second DSP in Path 2? This would leave a lot more room for the effects blocks in Path 1 would it not?

[haller88]

Well after taking Uber Guru suggestions to just do it on the editor itself (without the computer plugged in via the USB cable) I did have some better luck. The main thing that helped me out was seeing the error message when I tried to do something illegal (like have too many controllers on one block to copy and past iot or running out of DSP), I still can't believe the second run has more DSP - based on my current experience I would have guessed it the opposite.

 

The two bottom lines are:

 

1. Make clearer error message show in the pc based editor in the future (at least what you see on the onboard editor)

 

2. The Helix for the money should have additional DSP!

 

Well - that's all for now - at least I am moving forward with the Helix again!

[NerdOfTheYear]

 

2. The Helix for the money should have additional DSP!

 

I mean, the Helix is running the same two SHARC DSP that the Axe-Fx II is running. There's a lot of processing power in there, it's just that not all effects are made equally. This is includes not all amps using the same amount of DSP. If your only running one instrument (guitar) thru the Helix, then there is ample processing power if you think about where in the chain you place your DSP-intensive blocks.

 

As an example, when I'm building a patch with the intention of using multiple amps, I make sure my amp blocks are on Path 1A and 1B, and my IR/Cabs and reverbs are on path 2A + 2B. I've also started blending my IRs in MixIR2 so that I can have 1 2048 IR to use for both amps. That and a reverb fits nicely on the DSP.

[Digital_Igloo]

This is incorrect. Path 2 has more DSP than path 1 due to DSP 1 having the responsibility to also run the Helix OS.

Nope. Path 1 and Path 2 have nearly the exact same amount of DSP. Depending on your Input blocks' gates or Global EQ, one might have a tiny bit more than the other (likely no more than a 2% delta), but there's no "running the Helix OS" on either DSP.

 

You might be thinking of Helix's two MCUs, where one deals with running Helix's day-to-day behind-the-scenes tasks and the other is dedicated to UI.

 

The Helix for the money should have additional DSP!

Soo... a third SHARC? TigerSHARCs? Either one would add considerably to how much you paid for Helix.

 

If another box appears to have "ample DSP," it's because the developers crippled their box's flexibility and block allocation. Helix could also appear to have unlimited DSP if we restricted you to one amp, one cab, one reverb, one distortion, two delays, two mods... which is what other boxes do. Instead, we let you put whatever you want wherever you want, until you run out of DSP. If that gives one "DSP anxiety," oh well—with great power comes great responsibility.

 

Here's the best analogy I can come up with: The Archibald kids down the street get $20 a week for allowance, and they're pretty content because it's consistent. The Lewis kids get anywhere from $40-60 a week, depending on how much homework they do. Dave Lewis did his homework and got $60. His brother Billy didn't and he got $40... and was then upset because he really wanted that $50 video game.

 

So yes, we could make it so Helix feels like it has "more DSP." We redesign the whole thing so you only get one amp, one cab/IR, and eight effects, all distortions and dynamics are mono, all cabs are single, and we'll never make better-sounding (more DSP-intensive), say, delays, because they may not fit the pre-allocated chunk of DSP/memory reserved for delays. All right, kids, that's it! You only get $20 a week now!

 

I mean, the Helix is running the same two SHARC DSP that the Axe-Fx II is running. There's a lot of processing power in there, it's just that not all effects are made equally. This is includes not all amps using the same amount of DSP. If your only running one instrument (guitar) thru the Helix, then there is ample processing power if you think about where in the chain you place your DSP-intensive blocks.

 

As an example, when I'm building a patch with the intention of using multiple amps, I make sure my amp blocks are on Path 1A and 1B, and my IR/Cabs and reverbs are on path 2A + 2B. I've also started blending my IRs in MixIR2 so that I can have 1 2048 IR to use for both amps. That and a reverb fits nicely on the DSP.

 

Helix has the same DSPs as Fractal's AX8 (2x 450MHz ADSP-21469 SHARCs), not their AxeFX II XL+ (2x 600MHz TigerSHARCs). TigerSHARCs would've pushed Helix to well over $2000.

 

Anyone interested should also check out 8 TEMPLATES > 01B Parallel Spans. It's a dual Amp+Cab preset with one on each path/DSP with plenty of room for pre and post effects.

[HonestOpinion]

Nope. Path 1 and Path 2 have nearly the exact same amount of DSP. Depending on your Input blocks' gates or Global EQ, one might have a tiny bit more than the other (likely no more than a 2% delta), but there's no "running the Helix OS" on either DSP.

 

You might be thinking of Helix's two MCUs, where one deals with running Helix's day-to-day behind-the-scenes tasks and the other is dedicated to UI.

 

Soo... a third SHARC? TigerSHARCs? Either one would add considerably to how much you paid for Helix.

 

If another box appears to have "ample DSP," it's because the developers crippled their box's flexibility and block allocation. Helix could also appear to have unlimited DSP if we restricted you to one amp, one cab, one reverb, one distortion, two delays, two mods... which is what other boxes do. Instead, we let you put whatever you want wherever you want, until you run out of DSP. If that gives one "DSP anxiety," oh well—with great power comes great responsibility.

 

Here's the best analogy I can come up with: The Archibald kids down the street get $20 a week for allowance, and they're pretty content because it's consistent. The Lewis kids get anywhere from $40-60 a week, depending on how much homework they do. Dave Lewis did his homework and got $60. His brother Billy didn't and he got $40... and was then upset because he really wanted that $50 video game.

 

So yes, we could make it so Helix feels like it has "more DSP." We redesign the whole thing so you only get one amp, one cab/IR, and eight effects, all distortions and dynamics are mono, all cabs are single, and we'll never make better-sounding (more DSP-intensive), say, delays, because they may not fit the pre-allocated chunk of DSP/memory reserved for delays. All right, kids, that's it! You only get $20 a week now!

 

 

Helix has the same DSPs as Fractal's AX8 (2x 450MHz ADSP-21469 SHARCs), not their AxeFX II XL+ (2x 600MHz TigerSHARCs). TigerSHARCs would've pushed Helix to well over $2000.

 

Anyone interested should also check out 8 TEMPLATES > 01B Parallel Spans. It's a dual Amp+Cab preset with one on each path/DSP with plenty of room for pre and post effects.

 

I have always been a huge fan of the way Line6 decided to implement its DSP by not having as set number of preassigned 'slots' for each amp/effect category and instead allowing the user maximum flexibility. To me it was a thousand times 'YES' the right decision. This post is of particular interest to me right now. I am having a conversation on another thread about whether it would be possible on the Helix to populate but not activate all the blocks in a preset and then select and activate subsets of them that come in below the DSP limit for assignment to snapshots or multiple stomps. Not exactly an apples to apples situation as doing this could potentially have a user trying to go to a configuration during a performance that exceeded the DSP limit but I think the same principle of providing maximum flexibility applies to some extent. Would it be possible to even do this on the Helix? I understand if you can't or don't want to answer this question.

[Digital_Igloo]

I am having a conversation on another thread about whether it would be possible on the Helix to populate but not activate all the blocks in a preset and then select and activate subsets of them that come in below the DSP limit for assignment to snapshots or multiple stomps. Not exactly an apples to apples situation as doing this could potentially have a user trying to go to a configuration during a performance that exceeded the DSP limit but I think the same principle of providing maximum flexibility applies to some extent. Would it be possible to even do this on the Helix? I understand if you can't or don't want to answer this question.

If I understand the request correctly, it sounds like you're looking for something between a preset and a snapshot.

 

When you switch presets, the audible gap comes from unloading the DSP and reloading new blocks. The reason snapshots don't have a gap is because models aren't being unloaded from/loaded to DSP; everything's in there at once, waiting to be enabled/bypassed.

[silverhead]

If understand the request correctly, it sounds like you're looking for something between a preset and a snapshot.

 

When you switch presets, the audible gap comes from unloading the DSP and reloading new blocks. The reason snapshots don't have a gap is because models aren't being unloaded from/loaded to DSP; everything's in there at once, waiting to be enabled/bypassed.

So I think that implies that what HonestOpinion is contemplating is, from a technical perspective, no different than using multiple presets.

 

In other words, having any amp/FX block defined but not 'active' in a preset is equivalent to having two presets, one with the block inactive and one with it active. The lag involved comes from the 'loading/activating' that is required in both cases. The fact that the block exists in the same preset or in another preset is irrelevant.

 

In other words, the existing Snapshot ability takes the concept as far is it can go technically without introducing a lag/gap in the sound.

[HonestOpinion]

If understand the request correctly, it sounds like you're looking for something between a preset and a snapshot.

 

When you switch presets, the audible gap comes from unloading the DSP and reloading new blocks. The reason snapshots don't have a gap is because models aren't being unloaded from/loaded to DSP; everything's in there at once, waiting to be enabled/bypassed.

That essentially sums it up and makes perfect sense. If all blocks have to be preloaded to avoid switching latency and allow trails, and inactive blocks do not use less DSP than active blocks when preloaded, then there is no advantage to allowing 32 blocks to be assigned, even if many are inactive, they will exceed the DSP limit. If you allowed 32 blocks that exceeded the DSP limit (but were not all activated) in a preset they would not gain the advantage of low latency as you would still have to load them into the DSP when a subset of them was activated just as you do with a current preset. You might as well just switch presets. Thanks very much for the answer and it puts this debate firmly to rest!

[HonestOpinion]

So I think that implies that what HonestOpinion is contemplating is, from a technical perspective, no different than using multiple presets.

 

 

Agreed! ^^^ This in a nutshell..  :)

[Digital_Igloo]

In other words, the existing Snapshot ability takes the concept as far is it can go technically without introducing a lag/gap in the sound.

There are still a few things we could do (one of which would be really cool if we can pull it off) but they're complicated and time-consuming to get right.

[NerdOfTheYear]

There are still a few things we could do (one of which would be really cool if we can pull it off) but they're complicated and time-consuming to get right.

Don't tease me like this, I'm already far too excited for 2017 based on the vague comments you've made about what's to come.

[MonkeyXT]

... tasty morsel to nibble on.

 

Thanks for the clarification, and the pointer toward possible new expansion for the future.

[malhavok]

You might be thinking of Helix's two MCUs, where one deals with running Helix's day-to-day behind-the-scenes tasks and the other is dedicated to UI.

 

 

It's likely a giant game of telephone. I have seen that stated multiple times by many people over on the FB group. It has been circulating as common advice since before I even got Helix. I'll be sure to correct the conversation any time I see it come up again.

[haller88]

In response to middle comment from Line 6 - I agree that we would always want more memory so it sounds like we have as much memory as the budget would allow. Perhaps the flexibility in mixing up the blocks and stereo versus mono etc almost gets us into trouble. I do appreciate the flexibility and I would agree that the Helix is potentially the most flexible unit I have come across (I go back to very old Digitech units through the POD through more Digitech to the HD500 and have finally landed with the Helix.

 

A couple of observations and I will close this out...

 

1. It appears that probably building a multiple path patch from scratch might be preferable than taking an already optimized single path patch and modifying it to a dual path. It appears that the Helix isn't always great about reallocating memory once it has been initially setup. I have had much better luck starting from scratch or nearly from scratch than modifying an existing patch.

 

2. When having a block copying issue - always revert to doing the editing on the device - the error messages are key to adjusting and moving things around...

 

3. It would be cool to see the memory block size for us adjustment geeks so that we could optimize what is on each path and the order etc - my guess is that this would be too much information for many but it would really help me with some of the patch edits...

 

After all of the responses - I think I learned a few more things about the Helix that will help me down the line - thanks!!!

[Digital_Igloo]

1. It appears that probably building a multiple path patch from scratch might be preferable than taking an already optimized single path patch and modifying it to a dual path. It appears that the Helix isn't always great about reallocating memory once it has been initially setup. I have had much better luck starting from scratch or nearly from scratch than modifying an existing patch.

 

DSP allocation in Helix is pretty straightforward—every time you add a new block, the DSP filter updates and grays out any models that won't fit on that particular path. When you joystick to the other path, the model list is reflected by a different DSP filter.

 

Whether you alter an existing preset or start one from scratch, it shouldn't matter. If something's behaving oddly, definitely let CS know.

3. It would be cool to see the memory block size for us adjustment geeks so that we could optimize what is on each path and the order etc - my guess is that this would be too much information for many but it would really help me with some of the patch edits...

Pre-production versions of the firmware displayed usage per path/DSP in percentages (0.1% resolution), just so we could test the filters. Generally, I'd prefer to not make DSP usage visible, as suddenly everyone obsesses over the numbers instead of... having fun making music. Then someone makes a big Excel spreadsheet, and a billion questions pop up like "Why is model X 2.3% bigger than model Y when it has one less tube?" <shudder>

 

DSP anxiety is a very real thing and part of good UI design is purposeful obfuscation. We're not trying to hide anything as much as we're trying to simplify the process of making tones.

 

If we ever did add DSP meters, it'd have to be because there was overwhelming demand for it. Even so, we'd probably hide it on the Global Settings page or something; I'd never want it constantly staring at anyone from the Home screen.

[duncann]

 

DSP allocation in Helix is pretty straightforward—every time you add a new block, the DSP filter updates and grays out any models that won't fit on that particular path. When you joystick to the other path, the model list is reflected by a different DSP filter.

 

Whether you alter an existing preset or start one from scratch, it shouldn't matter. If something's behaving oddly, definitely let CS know.

Pre-production versions of the firmware displayed usage per path/DSP in percentages (0.1% resolution), just so we could test the filters. Generally, I'd prefer to not make DSP usage visible, as suddenly everyone obsesses over the numbers instead of... having fun making music. Then someone makes a big Excel spreadsheet, and a billion questions pop up like "Why is model X 2.3% bigger than model Y when it has one less tube?" <shudder>

 

DSP anxiety is a very real thing and part of good UI design is purposeful obfuscation. We're not trying to hide anything as much as we're trying to simplify the process of making tones.

 

If we ever did add DSP meters, it'd have to be because there was overwhelming demand for it. Even so, we'd probably hide it on the Global Settings page or something; I'd never want it constantly staring at anyone from the Home screen.

 

 

Similar to how some folks view the behavior of the tuner since it was redone, how about making a DSP meter that's jumpy, and possibly even introduce some ambiguous inaccuracy.