Reverb 'Emphasis' feature

Would you like to see this 'Reverb Emphasis' feature implemented?

  • Yes, this would make the AFX's Reverb even more flexible and versatile!

    Votes: 0 0.0%

  • Total voters
    6

Radley

Experienced
I feel it would be an excellent addition to the Reverb block to have two new advanced parameters:

Emphasis Frequency (50z up to 8k?)
Emphasis Boost/Cut (plus or minus 12db)

This would provide a very basic, fairly wide EQ Boost or Cut (applied only the wet signal), to facilitate adding a particular sheen, warmth, or character to the Reverb according to each particular patch's needs, and to also simplify mimicking other popular reverb response curves. The existing low & high pass filters work very well, but they cannot tailor the important middle frequencies like this simple EQ could. Currently, to duplicate this effect without these extra parameters requires a fair amount of extra work (and blocks).
 
You can do this, just put the reverb in parallel, set mix to 100% and control the reverb level with level.

Put an EQ in the same parallel chain that the reverb lives, voila, EQed reverb.
 
Maybe not from the devil, but CPU power is a limited resource. For me as a standard user who is quite happy with the sounds the reverb has as it is, this would be a fringe effect and really not worth any extra CPU load. I don't see using it all that much, or perhaps ever.

Otherwise, of course, it's not a bad idea for those who could use it.
 
Beefcake said:
Maybe not from the devil, but CPU power is a limited resource. For me as a standard user who is quite happy with the sounds the reverb has as it is, this would be a fringe effect and really not worth any extra CPU load. I don't see using it all that much, or perhaps ever.

Otherwise, of course, it's not a bad idea for those who could use it.

Thanks guys for voting & for your input. I'm still trying to find the balance between convenience and CPU power - doesn't using parallel routing and adding an EQ use more resources than adding the two advanced parameters? ( Just asking)
 
Radley said:
Beefcake said:
Maybe not from the devil, but CPU power is a limited resource. For me as a standard user who is quite happy with the sounds the reverb has as it is, this would be a fringe effect and really not worth any extra CPU load. I don't see using it all that much, or perhaps ever.

Otherwise, of course, it's not a bad idea for those who could use it.

Thanks guys for voting & for your input. I'm still trying to find the balance between convenience and CPU power - doesn't using parallel routing and adding an EQ use more resources than adding the two advanced parameters? ( Just asking)

Yes. But, if it is in the block itself it will consume resources for those that don't use as well. I doubt it would take much cpu useage to include it. I dont know about memory, which is in very short supply on the standard.
 
javajunkie said:
Radley said:
Beefcake said:
Maybe not from the devil, but CPU power is a limited resource. For me as a standard user who is quite happy with the sounds the reverb has as it is, this would be a fringe effect and really not worth any extra CPU load. I don't see using it all that much, or perhaps ever.

Otherwise, of course, it's not a bad idea for those who could use it.

Thanks guys for voting & for your input. I'm still trying to find the balance between convenience and CPU power - doesn't using parallel routing and adding an EQ use more resources than adding the two advanced parameters? ( Just asking)

Yes. But, if it is in the block itself it will consume resources for those that don't use as well. I doubt it would take much cpu useage to include it. I dont know about memory, which is in very short supply on the standard.

I don't see how it could ever consume more resources than a filter block - probably less, since it doesn't need a separate block to 'house' it.
 
Perhaps the AFX should go with a similar concept as another quality multieffect I have used: Have at least two, maybe three different reverb algorithms (blocks), going from the lowest CPU demands (and sonics) to the highest - these would also differ in the number of available parameters. IE: if you just need a bit of ambience or a very short verb, the lower CPU algo would work fine, and leave you with more CPU 'horsepower' for other effects. It's either that or increase the CPU horsepower, because when people pay this much, they don't want to feel limited in what they can do with it.
 
A peaking filter (which is basically what you're asking for) uses a bit less than 1% of CPU, and it's very easy to add one, so it's hard for me to consider its absence from the reverb a real "limitation".
 
chase said:
A peaking filter (which is basically what you're asking for) uses a bit less than 1% of CPU, and it's very easy to add one, so it's hard for me to consider its absence from the reverb a real "limitation".

Don't be offended, but this logic seems a bit strange - why is it more efficient to create a 'workaround' than including the parameter in the reverb itself? (this parameter IS included in some excellent verbs) I'm sure with some creativity I could assemble my own AFX chorus out of clever routing etc, but why? It is much simpler and faster to just use the provided Chorus block - why is the same not true for an improved Reverb block?

~Rad~
 
Radley said:
Don't be offended, but this logic seems a bit strange - why is it more efficient to create a 'workaround' than including the parameter in the reverb itself? (this parameter IS included in some excellent verbs) I'm sure with some creativity I could assemble my own AFX chorus out of clever routing etc, but why? It is much simpler and faster to just use the provided Chorus block - why is the same not true for an improved Reverb block?

Simple answer to your question as I see it: chorus is a distinct and somewhat complex effect which would be very hard or at least labor-intensive and inconvenient for the average user to create on their own from scratch. What you propose is not. But for me, this is completely beside the point.

My only objection is to general feature creep: if Cliff started adding similar rarely used (at least by me) options to all blocks, my patches might soon need 5 or 15 or 25% more CPU to run due to "enhancements" I don't need, and my poor Standard doesn't have that to spare in many patches.

After all, what block wouldn't be more flexible with it's own internal EQ? Some people might wish to have additional pre- and post-EQ's in the amp and cab blocks. I could certainly see how that might be convenient in some cases. I could also see each of those blocks taking "only" another 0,9% more of my Axe's CPU, and I don't want that, because I don't need EQ for amps and cabs in every patch.

As we all surely realize, it's a careful balance and for my money, Cliff got the granularity pretty much right in the Axe as it is, and the proposed addition would probably hurt my Axe's performance with next to no added usability to me. Hence my negative vote.
 
Radley said:
javajunkie said:
Radley said:
Thanks guys for voting & for your input. I'm still trying to find the balance between convenience and CPU power - doesn't using parallel routing and adding an EQ use more resources than adding the two advanced parameters? ( Just asking)

Yes. But, if it is in the block itself it will consume resources for those that don't use as well. I doubt it would take much cpu useage to include it. I dont know about memory, which is in very short supply on the standard.

I don't see how it could ever consume more resources than a filter block - probably less, since it doesn't need a separate block to 'house' it.

Yes, I agreed with you there. What I was saying is that it consumes resources for those that DONT want to use it whether the want it or not. Adding an EQ block only adds additional resources for ones that DO want to use it.
 
Thanks for the responses guys - well said. This is the type of discussion I was hoping to start in another (ill fated) thread. The more I & others understand the why, the more the 'what is' makes sense.

Beefcake - what did you think of the idea of different Verb algos with different CPU demands?

Please Note: These are simply ideas, not an attempt to change everything to a few people's liking. I don't want to see anyone 'cheated' out of an ounce of CPU power, and I understand the additional concerns of non-Ultra users.
 
I agree with Beefcake.

I didn't say anything about it being "more efficient", just that it was easy. When balancing the user-gain from adding another EQ band to the reverb (slightly quicker than adding a filter block, slightly smaller CPU hit than adding a separate block) vs. the user-cost (heavier reverb whether you want it or not, Cliff has to pay attention to this rather than something else), I'm on the side that feels the cost outweighs the gain.

I'm not opposed to the idea of having different quality reverb algorithms available - the cab block has three modes, for instance, and some of the other blocks use different CPU depending on the mode they're in, so I wouldn't mind being able to select a "deluxe reverb" - and if Cliff added a mid-EQ to the reverb that didn't change the CPU load I wouldn't complain. I'm not at all opposed to the Axe changing - it's improved by leaps and bounds since I got mine, and I was already happy with it - but it's important to remember that all these changes are coming from the efforts of one person, and any improvement he makes comes at the expense of some other potential improvement he could be making. Given that, it just doesn't make sense to me personally to ask him to put that effort into adding a mid-EQ: something that I can already do, and do easily.

Edited to add: If there's something else that people feel is lacking about the reverb (I'm not one of them), and they point it out, and Cliff agrees and adds a higher-quality reverb option, great (this process already happened with the diffusion parameter in the Ultra).

(The main thing that I want him to add is a compare feature!)
 
Radley said:
Perhaps the AFX should go with a similar concept as another quality multieffect I have used: Have at least two, maybe three different reverb algorithms (blocks), going from the lowest CPU demands (and sonics) to the highest - these would also differ in the number of available parameters. IE: if you just need a bit of ambience or a very short verb, the lower CPU algo would work fine, and leave you with more CPU 'horsepower' for other effects. It's either that or increase the CPU horsepower, because when people pay this much, they don't want to feel limited in what they can do with it.

Just how much would your UNlimited unit cost? Everything has it's limits and I am sure you would be the 1st one to point them out.
 
Radley said:
Thanks for the responses guys - well said. This is the type of discussion I was hoping to start in another (ill fated) thread. The more I & others understand the why, the more the 'what is' makes sense.

Beefcake - what did you think of the idea of different Verb algos with different CPU demands?

Please Note: These are simply ideas, not an attempt to change everything to a few people's liking. I don't want to see anyone 'cheated' out of an ounce of CPU power, and I understand the additional concerns of non-Ultra users.

CPU is not the only limitation or the most scarce resource. Memory to store the parameters block are at a premium, the standard is already "over-stuffed". How Cliff managed to put in what he did in the standard since he announced it was just about full is amazing. That being said, memory is a very precious resource on both the standard and ultra. Several of the new parameters are ultra only because they wouldn't fit in the standard.
 
Stratman68 said:
Just how much would your UNlimited unit cost? Everything has it's limits and I am sure you would be the 1st one to point them out.

It wouldn't cost any more - there would just be 2 or 3 different reverb blocks to chose from. Obviously if it has to cost more, it's probably not a usable idea.

JavaJ. - thanks for the additional info & explanation.
 
Back
Top Bottom