[FEATURE] Dry/wet control after output gain

[darwindeez]

I would love to have the wet/dry AFTER the output gain, which I feel would be more useful for getting sounds. Getting sounds out of a nice sounding tape plugin such as Le Chow 5000 usually goes like this:

1. tweak settings, listening only for tone, ignoring output level (since every tonal control affects output level). get a nice tone. get the tape to react to the source the way you want it to.
2. match output level to input level to check that the tonal change is actually a nice improvement and not just louder (important step).
3. dial in the actual desired amount of said tone using the wet/dry knob.

If the wet/dry is before the output level, I'm not able to fine tune my tonal change nearly as easily. Cool project!!

[jatinchowdhury18]

Hi @darwindeez,

Thanks for the feature request. This seems pretty reasonable. Just to make sure I'm understanding the request correctly:

The current signal flow is as follows:
Input ---> | In Gain | ----> | Processing | -----> | Dry/Wet | ----> | Out Gain | ---> Output
          |            |
          --------> | Delay | ------------

What you're asking for would be:
Input ---> | In Gain | ----> | Processing | ----> | Out Gain | -----> | Dry/Wet | ---> Output
          |                    |
          --------> | Delay | -------------------------------

(apologies for the rough diagrams)

If we were to make that change, I suppose it might also make sense to include the Input Gain as part of the "wet" processing, though I'm not sure how useful that would be given the workflow that you described.

In case you're curious, the code that implements the signal flow is here.

Thanks,
Jatin

[darwindeez]

Hey Jatin, Thank you for the diagram and for considering my suggestion! I must admit, I don't understand what that input gain difference would mean. I don't see a way that it would interfere with the workflow I described though. But that's just because I don't understand it :) Darwin

…

On Sun, Aug 16, 2020 at 1:14 PM jatinchowdhury18 ***@***.***> wrote: Hi @darwindeez <https://github.com/darwindeez>, Thanks for the feature request. This seems pretty reasonable. Just to make sure I'm understanding the request correctly: The current signal flow is as follows: Input ---> | In Gain | ----> | Processing | -----> | Dry/Wet | ----> | Out Gain | ---> Output | | --------> | Delay | ------------ What you're asking for would be: Input ---> | In Gain | ----> | Processing | ----> | Out Gain | -----> | Dry/Wet | ---> Output | | --------> | Delay | ------------------------------- If we were to make that change, I suppose it might also make sense to include the Input Gain as part of the "wet" processing, though I'm not sure how much sense that would make given the workflow that you described. In case you're curious, the code that implements the signal flow is here <https://github.com/jatinchowdhury18/AnalogTapeModel/blob/master/Plugin/Source/PluginProcessor.cpp#L209> . Thanks, Jatin — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DRFPETIBFX3P77PO2C3SBAVZVANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

Hi Darwin,

No problem! I think I'm going to go with the version that includes Input Gain as part of the "wet" processing. This signal flow looks like this:
Input ---> | In Gain | ----> | Processing | ----> | Out Gain | -----> | Dry/Wet | ---> Output
   |                           |
   --------------------------> | Delay | -------------------------------

If you want to try it out, I've made a version of the builds with this change:
CHOWTape-Win64-DryWet.zip

If you're on Mac let me know and I can generate some Mac builds for you to try.

Thanks,
Jatin

[jatinchowdhury18]

Hey @darwindeez, just wanted to check if you'd had a chance to test out the version that is shared above.

Thanks,
Jatin

[darwindeez]

oh hey, i'm on a mac actually if you would like me to test it.

…

On Fri, Aug 21, 2020 at 6:40 PM jatinchowdhury18 ***@***.***> wrote: Hey @darwindeez <https://github.com/darwindeez>, just wanted to check if you'd had a chance to test out the version that is shared above. Thanks, Jatin — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DRBBSQ4BL2MHMPHIFA3SB4HX5ANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

No problem! You can download updated Mac builds here.

[darwindeez]

awesome, thank you. the change definitely improves my workflow, but not in the way i expected. i'm not able to use the wet/dry to blend in drive/saturation due to phase cancellations that are introduced at intermediate settings. but the new wet/dry is very useful as a seamless bypass to compare the effect to the sound with no effect. if i use logic to bypass the plugin i get an annoying and distracting skip in the playback, which is typical of most plugins, and not a problem in itself. so it's an improvement to me, to have this functionality even though i wouldn't be able to use it control drive and saturation amounts in parallel. an internal bypass button would do the trick even better, but it's not important.

…

On Sat, Aug 22, 2020 at 9:17 AM jatinchowdhury18 ***@***.***> wrote: No problem! You can download updated Mac builds here <https://github.com/jatinchowdhury18/AnalogTapeModel/blob/dry-wet/Plugin/Bin/MacBuilds.zip> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DRF2C7MFSMX43DXVOQTSB7OR5ANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

Ah, thanks for that update. I had made some internal changes, and had neglected to update the dry/wet latency compensation accordingly. This should be fixed in the new builds, which you can try out here.

[darwindeez]

thank you! phase cancellation is much improved but i'm still getting a subtle loss of high frequencies on intermediate settings, as compared to 100% dry or 100% wet, regardless of oversampling, which i think may be phase related, still. the intermediate sound is now usable but it's not as bright as the 100% wet sound or the dry sound. possibly i'm losing some other frequencies to cancellations as well.

…

On Sun, Aug 23, 2020 at 1:41 PM jatinchowdhury18 ***@***.***> wrote: Ah, thanks for that update. I had made some internal changes, and had neglected to update the dry/wet latency compensation accordingly. This should be fixed in the new builds, which you can try out here <https://github.com/jatinchowdhury18/AnalogTapeModel/blob/dry-wet/Plugin/Bin/MacBuilds.zip> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DREQCLYLPY5LFMQKOY3SCFWHLANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

Okay great! I can tweak the latency compensation a tiny bit more to help alleviate the the high frequency loss. It's a little bit tricky since the hysteresis process doesn't have a constant group delay. For now I'll mark this issue as resolved, but feel free to re-open it if you have more questions/suggestions about this issue. This fix will be included in the next release (coming very soon :) ).

[darwindeez]

Hey Jatin, New STN hysteresis mode sounds good (I'm up to v2.7 of chow tape) . But I just discovered your dedicated hysteresis plugin through this thread on gearspace: https://gearspace.com/board/new-product-alert/1351320-vertigo-sound-vsm-4-a-12.html#post15466567 The plugin sounds great. I wonder if it would be possible (and of interest to you) to improve its CPU efficiency and add a post-process attenuator and maybe even a simple low frequency shelf to allow the user to compensate for the added volume and bass that the process produces. No worries if not. Just wanted to let you know that it is nice to have. It has a wonderful tonality. Cheers! Darwin

…

On Sun, Aug 23, 2020 at 6:31 PM jatinchowdhury18 ***@***.***> wrote: Okay great! I can tweak the latency compensation a tiny bit more to help alleviate the the high frequency loss. It's a little bit tricky since the hysteresis process doesn't have a constant group delay. For now I'll mark this issue as resolved, but feel free to re-open it if you have more questions/suggestions about this issue. This fix will be included in the next release (coming very soon :) ). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DRA2WWBCROWG5CLLCRDSCGYFNANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

Thanks, glad you're liking the hysteresis plugin! The current implementation is more of a "demo" implementation that was part of a research project I was working on, but it would be cool to turn it into a more fully-featured plugin. Most of my time at the moment is being spent working on a couple of other new plugins, but once I get those up and running this would be a cool project to work on next. I can let you know more as things progress!

[darwindeez]

Yeah, man that would be exciting. Just to give you the "tea" (the drama), this crazy expensive $200 plugin from Vertigo Sound called VSM-4 came out a few weeks ago and people have been discussing it on Gearspace. The VSM-4 plugin is somewhat related to a crazy expensive hardware saturation unit made by the same company called the VSM-2 (that costs $7500!). So anyway, the Vertigo VSM-4 includes a transformer emulation (as well as two tube gain stages). Someone came along and mentioned your Hysteresis plugin. Someone else put up a link to your github. Then the mods stealthily deleted the post containing the link and blocked the person who posted it from that thread. I think possibly Vertigo Sound--who was present in the thread, ushering their new product into the world of scrutinous chin-beards--did not like the idea that someone's free plugin was giving their very expensive plugin a serious run for its money and they pulled the fire alarm. Don't know if it was Vertigo or just an overzealous mod, but I just thought you should know that--sonically speaking, where it counts--your Hysteresis plugin is major league like that! 💪 They're running scared 👻

…

On Mon, May 24, 2021 at 8:18 PM jatinchowdhury18 ***@***.***> wrote: Thanks, glad you're liking the hysteresis plugin! The current implementation is more of a "demo" implementation that was part of a research project I was working on, but it would be cool to turn it into a more fully-featured plugin. Most of my time at the moment is being spent working on a couple of other new plugins, but once I get those up and running this would be a cool project to work on next. I can let you know more as things progress! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DREMI652DVRHPXZZPDDTPMCJDANCNFSM4QAVFFDQ> .

[jatinchowdhury18]

Ah interesting, thanks for sharing this context! While I doubt the Hysteresis plugin could sound exactly the same as VSM since it's not trying to model any analog hardware directly, that also means it could have the potential to be a more versatile digital effect. At the end of the day, I'm not really trying to have my plugins "compete" with anyone else's; as long as they are useful for musicians and engineers that's plenty good enough for me :).

[darwindeez]

hey jatin, i have an idea for a compressor plug-in that might be good. would you be interested in coding a compressor someday? first, what is wrong with the plug-in compressors we have now? well, even affordable hardware compressors sound better than current plug-ins. (it's a subtle but real difference, and not everyone would agree with this, but hardware still sells despite everyone working on DAWs, so that tells you something if you're not already convinced like i am.) hardware sounds better in what way(s)? hardware sounds bigger, more 3D, smoother, more alive, etc., even when properly level-matched (according to LUFS, the strictest way of level matching). so how to make a better compressor plug-in? determine the attributes--in addition to the compression itself--that a given hardware compressor adds at one specific setting (attack/release/ratio/threshold/AND input level). direct the plug-in user to apply a very specific amount of gain reduction and input level, and maybe you can use DSP to reproduce the sound of that one hardware compressor at that one setting doing that one amount of gain reduction. if my idea works, you'll be able to reproduce it accurately for the first time. every compressor plug-in says "i can do any and all amounts of gain reduction at any/all speeds and ratios." but they all lie. none of them can do any amount of compression as well as a decent hardware. we could take inspiration from the shadow hills dual vandergraph. this compressor is the lesser cousin of the $9,000 shadow hills mastering compressor. the vandergraph does not have fully variable attack and releaes times like its big brother. instead it only has four preset combinations of attack, release and ratio. you can always get a good sound from the unit, but you are simply not given total control over the settings. someone should make a compressor plug-in that acknowledges that all compressor plug-ins have failed to faithfully emulate quality hardware compression. they should take the dual vandergraph approach and say "not only will you be choosing from a few preset time constants and ratios, but you will also be limited (no pun) to a specified, targeted amount of gain reduction for each preset." outside of the target amount of gain reduction for a given preset, the plug-in can sound like ass. you're not using it correctly. but inside of that zone, we can reduce the complexity of the DSP such that we can actually capture the hitherto uncaptured magic of a hardware compressor, just without the flexibility. will it work? i don't know. but someone should try it. there is one extra limitation that we could add to the compressor: we could specify input type, if necessary. we could say that "this preset works only as intended on drums and percussive sounds." and "this preset works only as intended on vocals and bowed string instruments. and you can't adjust the attack time or the ratio or the release time or the amount of gain reduction--in addition to the type of input signal--without slipping out of the plug-in's sweet spot." maybe with all these limitations we could get a bit of truly uncompromised hardware compressor magic in the box. best, darwin 917 334 8789

…

On Mon, May 24, 2021 at 9:30 PM jatinchowdhury18 ***@***.***> wrote: Ah interesting, thanks for sharing this context! While I doubt the Hysteresis plugin could sound exactly the same as VSM since it's not trying to model any analog hardware directly, that also means it could have the potential to be a more versatile digital effect. At the end of the day, I'm not really trying to have my plugins "compete" with anyone else's; as long as they are useful for musicians and engineers that's plenty good enough for me :). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIY6DRBFTCB6SZLMFFWX3CLTPMKT3ANCNFSM4QAVFFDQ> .