Jump to content
Sign in to follow this  
invidiaboy

several blocks amp in a preset

Recommended Posts

Hello,

 

I bought an Helix two weeks ago and I'm really happy with it!

 

I'm encountering a problem: I don't manage to add another block amp / amp+cab / cab in a preset (see attached file), every model is writing in red in the helix editor, why?

 

Thanks for your response.

 

Cheers,

Fred

post-2435903-0-29368000-1481491648_thumb.jpg

Share this post


Link to post
Share on other sites

Red items in the selection block mean that you are approaching the DSP limit. These elements cannot be selected because they would exceed the available remaining DSP capacity.

 

To get more DSP you can use the lower signal path, Path 2. Change the output of your Output block at the end of Path 1. Direct it to Path 2 and your DSP capacity for the preset is doubled.

Share this post


Link to post
Share on other sites

THe answer above is correct, but I'd have to ask why you would be wanting to add an amp to a patch that already has an amp and cab?

If you are trying to mix 2 amps, you need to use the lower path,  You would also need to be feeding that amp somewhere before the other amp in its own path - it would not be logical to feed one amp into another - and is very unlikely to produce a good sound.

Think about it like real gear - do what would make sense with real gear - the virtual modelling gives pretty much exactly what you would expect from real gear.

There is tons of DSP for almost every sound once you learn how to set up a patch - read the manual - look at some YouTube videos on building patches.

Share this post


Link to post
Share on other sites

THe answer above is correct, but I'd have to ask why you would be wanting to add an amp to a patch that already has an amp and cab?

If you are trying to mix 2 amps, you need to use the lower path,  You would also need to be feeding that amp somewhere before the other amp in its own path - it would not be logical to feed one amp into another - and is very unlikely to produce a good sound.

Think about it like real gear - do what would make sense with real gear - the virtual modelling gives pretty much exactly what you would expect from real gear.

There is tons of DSP for almost every sound once you learn how to set up a patch - read the manual - look at some YouTube videos on building patches.

 

Although some people have achieved some interesting results feeding one amp into another a more common reason to have multiple amps in a preset is to switch between them. One comes on while the others are off. It does often require some creative juggling of effects or even minimal effects depending on which amps you select. Some of them are more DSP intensive. One use of multiple amps is when using snapshots or assigning multiple amps to a single footswitch; you can turn one amp on while simultaneously turning the other(s) off. I often have this kind of setup where there I may use three different amp models, one for each 'channel' of the amp. The 'Matchstick' and 'Cali (Boogie)' amp models are an example of this. By putting all three 'Matchstick' models/channels in one preset you create an entire virtual 'Matchstick' amp within one preset. Other times I mix & match different models for clean, crunch, and lead.

 

If I had a suggested change to make in reference to DSP it would be to allow as many blocks (max of 32) as can fit on the four paths. Instead of calculating the DSP for all blocks I would just have the Helix calculate DSP for activated blocks. When the DSP limit was reached simply don't allow any additional blocks to be activated. This would add a whole new realm of possibilities for multiple footswitch assignments and snapshots and would allow for all sorts of permutations within a preset that cannot be achieved right now because DSP is calculated as if all blocks are active. There may be good technical reasons why the DSP is being calculated this way and it might well be confusing to people to only calculate active blocks. Users might not understand at first why a block was not activating (DSP limit reached) but once they learned the rules of operation it would provide a great deal of flexibility in preset design.

Share this post


Link to post
Share on other sites

Yes, I also have a few patches with 2 amps, for that drastically different sound from pristine clean to serious grunt, although I mostly do that with overdrives and EQ.

But they are, let's say "advanced" patches.  And then you are clearly juggling DSP.  Not something I'd be thinking suitable for someone who is still getting their head round basic DSP problems.  I assume when you use 2 amps you have one on each path?  I'd personally be doing that as a default for a 2 amp rig whether a stereo both on or as a switching amp thing.  

I do agree with the basic idea you put out there about DSP equal to the total of what is being used not in waiting - but maybe that's a technical limitation?  You know how you get a slight gap when you change patches?  Maybe they all need to be essentially live to avoid that?

Share this post


Link to post
Share on other sites

Just a thought - if the Helix had allowed for calculation of active blocks only, I would expect a lag to be introduced as Helix 'dumped' the one model in favour of the other into active handling...

I don't for a moment actually know how this would work, but that's my instinct talking.

Share this post


Link to post
Share on other sites

Just a thought - if the Helix had allowed for calculation of active blocks only, I would expect a lag to be introduced as Helix 'dumped' the one model in favour of the other into active handling...

I don't for a moment actually know how this would work, but that's my instinct talking.

You could be right on this point. This could well be true depending on how and if blocks are cached or which data is pre-loaded/pre-fetched in some way in the DSP chip. I don't think we know enough about how Line6 uses a preset in tandem with the small amount of memory available on the DSP chip to determine how much or which data they require pre-loaded into the DSP. The literature on DSP chips does say they are optimized for fast access to external memory but I don't know if that is fast enough to not introduce significant latency if they had to access blocks from memory external to the DSP. Even if all/part of the block data does require being pre-loaded to the DSP to prevent latency, for all we know there could be enough memory on the DSP to load the necessary data for all 32 blocks. As usual I find myself completely in the dark on these finer technical points without Line6 chiming in and shedding some additional light on the subject. I find it difficult to believe that the programmers at Line6 didn't already consider this approach (allowing all 32 blocks to be selected but not all activated) and reject it for sound technical reasons but you never know unless they explain their rationale.

Share this post


Link to post
Share on other sites

I'd be curious as well; Makes me wonder - how much data is involved in a complex amp model of HX quality?

And how does that expand into active memory in order to 'report for work' in the realm of the DSP.

Fascinating stuff really - it's the man behind the curtain.

But I imagine it's as simple as the good folks at Line 6 working from a reasonable assumption; that Helix has to be prepared to have ALL blocks in a given preset active at once (sort of like 'worst case scenario' thinking).

I can understand that - it would be hard to anticipate what someone would want on stand-by for swap-out only.

 

In order to ground myself in my expectations, I need only picture creating a PODhd preset with some complexity, including working in a second amp; I ran up against the DSP wall time and again, as it was made with capabilities which the DSP couldn't support - the PODhd500X addressed that, but without Line 6 being able to pack that into the bean format, I waited patiently for the next step in their evolution (and I'd developed a bunch of HD presets which covered my needs handily, even if I was pushing the envelope for more =]).

 

I've been able to pull a LOT out of Helix presets, especially by comparison as above =]

Share this post


Link to post
Share on other sites

Just a thought - if the Helix had allowed for calculation of active blocks only, I would expect a lag to be introduced as Helix 'dumped' the one model in favour of the other into active handling...

I don't for a moment actually know how this would work, but that's my instinct talking.

i think this is correct. Early on (about a year ago) there were very active discussions about lag between presets. Snapshots mostly solved most users issues. Line 6 folks chimed in stating that for an effect to turn on instantly it is always running reguardless of on off state, consuming DSP.

  • Upvote 1

Share this post


Link to post
Share on other sites

Also, I'd much rather know when I build a preset that it's going to work, instead of finding out when I try to turn on certain combinations of blocks that I can't do that.

Share this post


Link to post
Share on other sites

i think this is correct. Early on (about a year ago) there were very active discussions about lag between presets. Snapshots mostly solved most users issues. Line 6 folks chimed in stating that for an effect to turn on instantly it is always running reguardless of on off state, consuming DSP.

 

I'm not surprised to hear this. If you find the quote directly from Line6 indicating any information on this, please post a link. I would love to see what they said.

Share this post


Link to post
Share on other sites

Also, I'd much rather know when I build a preset that it's going to work, instead of finding out when I try to turn on certain combinations of blocks that I can't do that.

 

I agree that I would want to know my combinations would work. This is just the kind of thing users would be concerned about. A simple 'Out of DSP' type message when you hit too greedy a block combination would be sufficient warning, but the benefit of the flexibility to dial up different combinations within a preset would be immense. You would test your switches ahead of time to make sure your combination of block assignments were working. I don't really see this as a showstopper. Testing snapshots would be particularly easy.

Share this post


Link to post
Share on other sites

If you can afford the fraction of a second lag in between loading presets, just switch presets. If you are attempting multiple amps using snapshots, then you have to get creative. Split up your amps and cabs between the upper and lower paths, and pick just the effects that you want to use. You will run out of DSP pretty quickly if you are running two amps and two different cabs. 

 

Download some patches from Customtone to see how others are spreading out their DSP usage. 

Share this post


Link to post
Share on other sites

Previous to snapshots I was setting each amp and its cab/cab son a separate path.  With snapshots I started to try different set ups and have been doing well by placing two amps on the top path and letting the bottom path handle the cabs and plenty of effects in post (I basically run overdrive as my only pre effect).  I realized I actually like to use one cab rather than always switching between fully separate A/B rigs.  Its more like the channel switching on amps that I am used to.  If you want a drastic change you can always switch mic and placement parameters with snapshots too.  

  • Upvote 1

Share this post


Link to post
Share on other sites

Or switch to a different IR if you're using them, that's just a parameter change.

Share this post


Link to post
Share on other sites

Attempting to calculate DSP usage based on active blocks only sounds like a good idea, but could have a very negative impact. Essentially it would make the patch non-deterministic. That is, you could create the patch, with all the blocks, but it would be somewhat unpredictable which combinations of active blocks might run out of DSP and not function in a live situation. That would not be a good thing.

Share this post


Link to post
Share on other sites

Attempting to calculate DSP usage based on active blocks only sounds like a good idea, but could have a very negative impact. Essentially it would make the patch non-deterministic. That is, you could create the patch, with all the blocks, but it would be somewhat unpredictable which combinations of active blocks might run out of DSP and not function in a live situation. That would not be a good thing.

 

I can see this as a valid concern but easily addressed, particularly for people who use only snapshots. If you are only using snapshots each one of them could be clicked through before-hand to make sure all your combinations work. If you are using stomps as well then you could also test which ones could be active together ahead of time. I don't see this as being dramatically more arduous than going to add an amp/cab or effect while designing a preset and finding everything grayed out and then having to go back and juggle and carefully choose what you are going to put in your preset. Perhaps a bit more hassle but a whole lot of flexibility in return. It would be nice to have a percent (%) readout anyway on the Helix to see how close you are getting on maxing out the DSP. That would provide a visual indicator as you got close to the edge. Just spitballin' here, not a crusade of any kind. As I stated previously there may be technical reasons this can't be done anyway.

Share this post


Link to post
Share on other sites

Its really a question of risk during configuration/setup vs. risk during a performance. Testing all possible combinations would require some discipline. I doubt Line 6 would want to deal with potential unexpected issues that come up during performance. 

 

There are certainly work arounds too, using different patches. It means you'd have to arrange patch changes where the delay isn't an issue. 

 

Bottom line is its a reasonable idea, but maybe not a priority for Line 6 or many users.

Share this post


Link to post
Share on other sites

Its really a question of risk during configuration/setup vs. risk during a performance. Testing all possible combinations would require some discipline. I doubt Line 6 would want to deal with potential unexpected issues that come up during performance. 

 

There are certainly work arounds too, using different patches. It means you'd have to arrange patch changes where the delay isn't an issue. 

 

Bottom line is its a reasonable idea, but maybe not a priority for Line 6 or many users.

 

I'm not sure what you mean by "Line6 not wanting to deal with issues that come up during a performance". There will always be issues in a performance if a user is unaware of how their equipment operates. I don't think that is necessarily a good reason not to make a device more flexible although I suppose there is a point of diminishing returns where you are confusing more users than helping them.

 

There is still latency between presets and trails don't work between presets so I don't think using multiple presets is an ideal alternative to what I am proposing (being able to populate all blocks but not have all active). If they could lower the latency between presets and allow trails to operate between them I would agree the feature I am proposing would have substantially less appeal although I could still see it being useful. It would be a nice capability to have this added flexibility on the Helix but the current state of affairs is certainly not a showstopper. The Helix is plenty powerful and flexible now. I would have to say that not only are you probably correct it is not a priority for many users but it is not even a priority for me. Still, I think it would be a great way to leverage snapshots and the low latency and the spillover capability that exists already within a preset by providing a whole lot more options of what could be done within a single preset.

 

By making every block available, even if you could not use them all at the same time, you would be able to populate a preset with a significant number of permutations of amps and effects. Any combination of these would be usable as long as you did not exceed the DSP limit. I think many, especially anyone currently using snapshots, might ultimately come to appreciate how powerful this feature could be, and I could see it being useful for those who use multiple assignments on stomps as well. Again though, the point may be moot if it is not technically feasible given the current hardware.

 

Think of the potential if you could have the 3 OSC synth, a couple of Auto-Wahs, several choruses, several overdirives/distortions, several delays and reverbs, multiple wah models, and assorted other effects all set up in one preset. Not to be used all at the same time but assigned in different combinations to snapshots available with the benefits that come from operating within a single preset (low latency between switches, trails).

Share this post


Link to post
Share on other sites

Really hope we don't have to find out during a show or rehearsal or jam whether each particular combination of switches can actually be used.

 

I currently run in 4 snaps + 4 stomps mode. Switching modes reveals another 4 stomps. By my count, there are 40,320 combinations of 8 stomp switches, times 4 snapshots. Not going to test them all, sorry.

 

In software development, the need to test a zillion scenario multipliers is indisputably your enemy. Having Helix precalculate all that, preventing you from blindsiding yourself down the the road, is IMO wonderful.

Share this post


Link to post
Share on other sites

Really hope we don't have to find out during a show or rehearsal or jam whether each particular combination of switches can actually be used.

 

I currently run in 4 snaps + 4 stomps mode. Switching modes reveals another 4 stomps. By my count, there are 40,320 combinations of 8 stomp switches, times 4 snapshots. Not going to test them all, sorry.

 

In software development, the need to test a zillion scenario multipliers is indisputably your enemy. Having Helix precalculate all that, preventing you from blindsiding yourself down the the road, is IMO wonderful.

 

A rehearsal or practice seems like it would be a prefect place to find out what works and what doesn't if you haven't already discovered that practicing on your own. Testing all 40,320 combinations you cite is to say the least a highly unlikely scenario. Just a wee bit of exaggeration there. Nobody is concerned about their '40,000+' configurations. I hear the concern about being blindsided during performance and it is a legitimate challenge to address. There are ways to mitigate that with DSP usage indicators and there would be nothing stopping you from getting a healthy number of configurations tested and ready to go ahead of time; much as you do when you design a preset with snapshots now. 

Share this post


Link to post
Share on other sites

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

 

 

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.

....

 

DI has clarified that this feature proposal has been resolved as not having any advantages due to the fact that low latency and trails are advantages yielded by pre-loading all blocks into DSP. Unless they figure out a way to preload inactive blocks that uses less DSP (may not even be possible) there is functionally no difference between putting 32 blocks in one preset (not preloaded into DSP) and just switching presets. I respectfully retract my idea until someone figures a way around the inactive DSP loading issue, or eternity, whichever come first.  ;)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...