Valhalla FutureVerb

[NAD]

I finally came around to try FutureVerb.

While the reverb sounds wonderful by itself and the delay isn't half bad either, the implementation as it currently is, seems to have one huge glaring flaw: I didn't find a way to control how much delay (in the "Echo->Rev" configuration*) is being fed into the reverb. That many delay modes have a drive parameter makes this shortcoming even more severe. I also guess that's why many folks seem to have a hard time getting their heads around this implementation. There is simply a crucial "Feed" (or whatever you may call it) control missing between the delay and the reverb**.

*It's basically the same issue if the reverb comes before the delay, i guess; I think it's less obvious in this case though.

**I think technically this would be another wet/dry control for whatever comes first in the chain.

I can't exactly tell from your post if you don't understand the routing or if you do understand it but just don't like it. If it's the latter please forgive my condescension.

On page 12 of this thread, @foosnark posted this handy diagram:

It's simultaneously serial and parallel.

For predelay: use Echo->Rev, turn Echo level to 0 and Reverb level to 100.

Bigger:


As far as I can tell from my own testing, this diagram is accurate. Point being, in Echo->Rev mode, the reverb is being fed a pure 100%-wet unity-gain signal directly from the delay, so the dry signal never hits the reverb directly. With 'Feedback' and echo 'Level' at 0, this provides the same functionality as traditional predelay in most reverbs, especially with the echo mode set to 'Modern'. If you wanted a mix of dry and delayed signal feeding the reverb, you would need a separate delay plugin behind FutureVerb, although that could just be another instance of FutureVerb set to pure Echo. Again, forgive me if I misunderstood you, but hopefully this might still be edifying to other forum lurkers.

[foosnark]

I think jens does understand the routing, but wants another wet/dry control inserted in front of the second effect. But yeah, it can be done with a second instance.

[_leras]

I think jens does understand the routing, but wants another wet/dry control inserted in front of the second effect. But yeah, it can be done with a second instance.

Sure, but one control would be much more convenient and allow better experimentation when dialling in sounds.

Anyway, I think this type of comment, that I agree with, are more 'would be nice if', than deal breakers or meant overly negatively.

(The actual derailing negative comments some people have posted are quite clearly OTT and somewhat deranged, going beyond just giving an opinion... and quite unnecessary imo)

[cryophonik]

FutureVerb_Signal_Flow.jpeg

Another user (hey212) posted this on GS

[Ah_Dziz]

I will agree that I'd love to see far more exposed controls. The only thing I like more than an awesome reverb algorithm, is one I can f**k up. I realize that the design of all the VDSP stuff is supposed to be straightforward and functional, but even if the extra controls were only available as automation destinations, I'd give them a fiddle.

[kraster]

Sorry, but your reply shows that you didn't really get my critique.

It's called: They disagree with you.

Not, it's not. Disagreement is fine. Giving a reply that conpletely ignores the argument you answer is not (in my book - your mileage may vary).

Huh.

How did I ignore it?

It's not as if I went on some wild tangent. I explained to you why I don't think of the current configuration is flawed in some way. Sean Costelloe has referred to the delay in the del---> rev configurations as an elaborate predelay. It's for adding colour more than anything else.

The second part of my critique was the wild assertions that the plugin had failed beta testing or that the beta testers were not up to snuff.

As for this:

"I'll be brutally honest here: it seems like the vast majority of the eight years development time went into the actual algos (and the macros controlling them) and delay/reverb marriage was a bit of an afterthough that's been implemented towards the last minute without much of a proper thought having been invested in it - which is a bit of a shame."

Literally made up scenarios that you *think* was the case and even go as far as too put a "which is a bit of a shame" at the end. As if this is somehow gospel.

Have you considered that maybe the guy who has been designing reverbs and delays for a living for the past 20 years might have put some thought into it?

[jens]

I think jens does understand the routing, but wants another wet/dry control inserted in front of the second effect. But yeah, it can be done with a second instance.

Yes, exactly.. however

1. a second instance will only work in send-mode, not as an insert

2. having to use a second instance imo anyway clearly defies the aim of easy/simple useability, which is why I previously said that fewer controls do not neccessarily equate increased simplicity

My main point is, that - simple pre-delay duties aside (modern mode with most controls turned fully down) - the delay isn*t very useable for bread and butter stuff as it is, because (even with drive at zero) the delay hammers down on the reverb like it's sole point of existance was to make it sound as terrible as possible. This becomes especially painfully obvious once you make healthy use of the drive or even more so when you use one of the pitch-shifting algos - REALLY. NOT. VERY. USEABLE. AT. ALL
(i.e. you're in Fabfilter factory-library territory pretty much immediately )

In short: for crying out loud - we're talking about one additional simple control that would increase the versatility of the plugin hundredfold.

[NAD]

FutureVerb_Signal_Flow.jpeg

Another user posted this on GS

I have to say I'm not as on board with this one, although the design is beautiful. It's a bit misleading to present some of those blocks as a discrete module with input and output. For example, while the EQ does apply filters on the output it also has an affect on internal reverb parameters. But perhaps that's being overly nitpicky, and I'd still like to recognize the effort and generosity of @hey212 for making it. Although @foosnark did it better

[v1md]

FutureVerb_Signal_Flow.jpeg

Another user posted this on GS

while the EQ does apply filters on the output it also has an affect on internal reverb parameters.

This is a good point. The HiCut knob does not act just as a lowpass filter, but effectively changes the damping of the high frequencies in the reverb. Likely, turning each of the knobs on the interface does multiple things at once. I guess this ties in with the current discussion on design choices, and I believe the dev spent quite a long time figuring this out. Limiting user access to parameters to avoid finding settings that would not sound good is a tough call, but unavoidable.

[hey212]

I have to say I'm not as on board with this one, although the design is beautiful. It's a bit misleading to present some of those blocks as a discrete module with input and output. For example, while the EQ does apply filters on the output it also has an affect on internal reverb parameters. But perhaps that's being overly nitpicky, and I'd still like to recognize the effort and generosity of @hey212 for making it. Although @foosnark did it better

That’s fair, the manual is not very clear about the order of those processes, so I left that section a bit half baked in the hopes of getting more information. The reason I posted it on GS is bc for whatever reason Sean is there and not here, so I asked him for any comments or corrections in the original post, but no luck.

Re treating the EQ as a discrete module, the filters are a discrete process, they get applied separately from the echo or reverb, so any accurate block diagram would need lines and boxes for them, but it would probably be good to add another text blurb explaining that the knobs that control the EQ filters also control some hidden parameters outside of the EQ. Another thing I’m realizing in looking at the manual again, is that even though there’s only one set of controls for the filters, there may be multiple instances of filters sharing those controls, in multiple locations in the signal path.

Sean prob didn’t bother correcting the diagram at least in part because a complete and accurate one would be significantly more complex, but if I could get a complete and accurate description of the signal flow I would happily update the diagram.

[trusampler]

Just bought this, what a beautiful collection of verbs and flexible tool to add to the previous collection. Thanks Valhalla for knocking it out of the park.

[NAD]

The reason I posted it on GS is bc for whatever reason Sean is there and not here, so I asked him for any comments or corrections in the original post, but no luck.

Yeah, I was waiting for him to comment on your diagram whether to confirm or deny, but he just wants to talk about his fuzz pedals or whatever!
I kinda get why he left us though, just look at the first five pages of this thread...

[cryophonik]

I was also hoping Sean would reply on GS to confirm/clarify hey212's diagram.

I kinda get why he left us though, just look at the first five pages of this thread...

Yeah, it's disappointing, but totally understandable, that so many developers have abandoned this forum.

[hey212]

Yeah, I was waiting for him to comment on your diagram whether to confirm or deny, but he just wants to talk about his fuzz pedals or whatever!
I kinda get why he left us though, just look at the first five pages of this thread...

Haha, he's all about fuzz pedals now. Ya, a shame he left but not hard to imagine why.

[Sampleconstruct]

E-bowed cittern with some tube distortion processed by two instances of Valhalla FutureVerb with 100% feedback resulting in a self-resonating dystopian dronescape.