CHOW Tape Model by Jatin Chowdhury

[MyLoFy]

Finally, I noticed this morning that CHOW Tape has been downloaded over 5,000 times! As someone who still primarily makes plugins for my own personal use and enjoyment, I never imagined anywhere near this level of interest (especially since I've done basically zero "marketing"). Thanks to all of you for continually providing encouragement, inspiration, and indispensible feedback. I'm expecting to be a bit busier with my day job in the coming weeks so I'm not sure when the next updates will come, but I'm excited to keep working on this plugin and more!

Hey, thanks for your effort, that plugin works really well on the master bus to round off the high end smoothly. And there is even an LV2 version!

[sengoku]

Yes, builds for the water bottles project are coming soon! Most of my other projects have builds available, but if there are others that you want builds for, just let me know.

Speaking of the water bottles project, some colleagues and I will be presenting our work on water bottle modelling at the 2020 DAFx conference next week. This year the DAFx conference will be all online and free for anyone to attend, so for anyone interested in some of the latest audio DSP research, this is a great resource. I'll also be presenting a more technical paper on nonlinear filters, and there's a ton of other presentations that look super interesting. A full list of presentations is currently on the DAFx website.

thank you sir

https://github.com/jatinchowdhury18/DrumFixer looks interesting too, if you have time. i guess the drum model is saved with the DAW session?

and yeah i'll check out dafx, i did some dsp in uni ages ago so i've always kept an interest in that side of things too, but the math is quite a way past me

[chowdsp]

https://github.com/jatinchowdhury18/DrumFixer looks interesting too, if you have time. i guess the drum model is saved with the DAW session?

Builds for the DrumFixer plugin are available in the "Bin/" folder (see here). And yes, all the information the plugin needs should be saved with the rest of the DAW session (I've only tested this in Ableton, but I'd imagine it should work mostly across the board).

and yeah i'll check out dafx, i did some dsp in uni ages ago so i've always kept an interest in that side of things too, but the math is quite a way past me

No worries, honestly a lot of the math is beyond me as well . That said, I typically find the presentations a little bit easier to digest than the actual papers. I'm hoping the presentation videos will be made available so people can access them after the conference as well...

Thanks,
Jatin

[crickey13]

I thought I'd just drop by to say you're awesome, Jatin, thanks for the Chow Tape Model. Awesome stuff.

[sinkmusic]

It's a nice effect indeed, thank you for creating, sharing and uptading it.
Is there any chance to add some parameters to set the tape compression occuring?

[Clearscreen]

I love what this plugin does! Thanks for making it! Apart from the tape emu I find myself using the Flutter part as an effect on guitar pretty regularly.
Is there any chance of being able to turn OpenGL off (if that's whats happening?)? It taxes my old laptop just that shade too much. I've set up a workaround with all parameters assigned to a container, but the plugin interface opens by default on the gpu and doesn't stop that when the interface is closed?
Either way, thanks again - great plugin!

[chowdsp]

Is there any chance to add some parameters to set the tape compression occuring?

Hmm, are you referring to the dynamic range compression that comes from the actual tape magnetisation, or the companding/de-companding that some tape machines have to help with noise reduction? The current saturation control does compress the dynamic range of the signal (of course adding a lot of distortion in the process), although it may not be very noticeable, since I apply a makeup gain after the fact. In the current model, I don't have any companding/de-companding happening (maybe someday...).

Is there any chance of being able to turn OpenGL off (if that's whats happening?)? It taxes my old laptop just that shade too much. I've set up a workaround with all parameters assigned to a container, but the plugin interface opens by default on the gpu and doesn't stop that when the interface is closed?

It should be possible make a build with OpenGL turned off, although this could cause problems on Windows. That said, once you close the plugin GUI, the OpenGL context should be destroyed accordingly, though I suppose it depends on how your DAW handles things. I'd rather not add to the list of builds that I currently have to make for every release, so if possible I'd prefer to find another solution. Out of curiosity, what OS and DAW are you using? Feel free to message me, and we can try to work something out!

[sinkmusic]

Hi, ChowDSP,
Thank you for your answer.

I was referring referring to the dynamic range compression that comes from the actual tape magnetisation (I like to use ToneBoosters Ferox, and it features as dedicated knob for the compression part of the signal processing).
I will listen more carefully to the compression already occuring with saturation.

Companding/decompanding would be something interesting also (as well as pre/de-emphasis), but your plugin is already nice as it is

[Clearscreen]

Is there any chance of being able to turn OpenGL off (if that's whats happening?)? It taxes my old laptop just that shade too much. I've set up a workaround with all parameters assigned to a container, but the plugin interface opens by default on the gpu and doesn't stop that when the interface is closed?

It should be possible make a build with OpenGL turned off, although this could cause problems on Windows. That said, once you close the plugin GUI, the OpenGL context should be destroyed accordingly, though I suppose it depends on how your DAW handles things. I'd rather not add to the list of builds that I currently have to make for every release, so if possible I'd prefer to find another solution. Out of curiosity, what OS and DAW are you using? Feel free to message me, and we can try to work something out!

I'm using Bitwig under win10 - I was sort of thinking along the lines of the softube plugins where there's a toggle for enabling/disabling openGL.

BUT....

After thinking about closing the plugin destroying the OpenGl context - turns out I wasn't waiting long enough to see that happen! It does happen, just not instantaneously like I'd assumed - DOH!!! Essentially if I load the preset that contains the plugin, then close the interface the GPU usage eventually falls off after about 12 seconds - sorry to have bothered you with this! I'll go back to using it

[gentleclockdivider]

Did something change with the saturation model ?
I remember from previous versions when input,sat and drive where set to max , I could give it some serious input gain without clipping
Not so anymore

[chowdsp]

After thinking about closing the plugin destroying the OpenGl context - turns out I wasn't waiting long enough to see that happen! It does happen, just not instantaneously like I'd assumed - DOH!!! Essentially if I load the preset that contains the plugin, then close the interface the GPU usage eventually falls off after about 12 seconds - sorry to have bothered you with this! I'll go back to using it

No worries! It's always interesting to me how different DAWs call plugin code in strange and unique ways. I definitely didn't understand the nuances of why until I tried making my own DAW (and there's still a lot that I don't understand). Definitely makes like as a plugin developer somewhat frustrating... In this case, my only guess that Bitwig hides the plugin editor when you close it, but doesn't destroy it immediately, so there's no lag in case you want to re-open it immediately after.

Did something change with the saturation model ?
I remember from previous versions when input,sat and drive where set to max , I could give it some serious input gain without clipping
Not so anymore

Hmm, the saturation algorithm hasn't changed much since version 1... which version(s) are you comparing too? The only thing I can think of is that I introduced a little bit of internal clipping to avoid instabilities at extreme input gains (this was a few releases ago, maybe v2.3?), but that should only start making a difference at +18 dB or more... maybe I could relax that constraint a little bit, especially at higher oversampling rates, and higher-order ODE solvers.

[TIMT]

After thinking about closing the plugin destroying the OpenGl context - turns out I wasn't waiting long enough to see that happen! It does happen, just not instantaneously like I'd assumed - DOH!!! Essentially if I load the preset that contains the plugin, then close the interface the GPU usage eventually falls off after about 12 seconds - sorry to have bothered you with this! I'll go back to using it

No worries! It's always interesting to me how different DAWs call plugin code in strange and unique ways. I definitely didn't understand the nuances of why until I tried making my own DAW (and there's still a lot that I don't understand). Definitely makes like as a plugin developer somewhat frustrating... In this case, my only guess that Bitwig hides the plugin editor when you close it, but doesn't destroy it immediately, so there's no lag in case you want to re-open it immediately after.

Did something change with the saturation model ?
I remember from previous versions when input,sat and drive where set to max , I could give it some serious input gain without clipping
Not so anymore

Hmm, the saturation algorithm hasn't changed much since version 1... which version(s) are you comparing too? The only thing I can think of is that I introduced a little bit of internal clipping to avoid instabilities at extreme input gains (this was a few releases ago, maybe v2.3?), but that should only start making a difference at +18 dB or more... maybe I could relax that constraint a little bit, especially at higher oversampling rates, and higher-order ODE solvers.

Could you perhaps at least make it optional?i really hate the way developers do this personally.i don't want anybody deciding for me whether or not my output should be constricted/clamped.i'd take overloads over clipping and i don't imagine i am in the minority either.i'm discovering a surprising number of developers do this as well unfortunately since contacting them.

[chowdsp]

Could you perhaps at least make it optional?i really hate the way developers do this personally.i don't want anybody deciding for me whether or not my output should be constricted/clamped.i'd take overloads over clipping and i don't imagine i am in the minority either.i'm discovering a surprising number of developers do this as well unfortunately since contacting them.

First, just to clarify, I'm not clamping the output, just clamping the input before it goes to the hysteresis algorithm.

I get that this can be frustrating (as a plugin user myself). I think it's important as a programmer to program "defensively" in that you never know how people will use your plugin, and I really don't want my plugins to go unstable. Even though most modern DAWs and interfaces have safegaurds against this kind of thing, it is still possible to damage a user's speakers or hearing when a plugin output "blows up", and I'd like to avoid this type of damage at all costs. Further, with this plugin in particular, going unstable typically means the plugin needs to be entirely re-initialized, not just disabled/enabled, meaning any settings the user had saved will be lost. Finally, I think that for every user who "knows what they're doing" and wants maximum control, there's one or two other users who "don't know what they're doing" and will crank up the input the first time using the plugin, see it go unstable, think "ah, it must be broken, screw it", and then never use the plugin again.

I think my ideal solution would be to fine-tune the input range for each ODE solver so that the clipping only occurs when your input is on the very edge of causing the plugin to go unstable, so you only hear clipping in situations where the plugin would otherwise go unstable. That said, I could maybe get behind an "unsafe mode" that lets users turn off any input limiting...

I'm still putting together a list of features and bugs to work on for the next release, so I'll have to think about this a bit more. I've been a bit busy lately, with work and life things, so I'm not sure when I'll get around to implementing these updates, but hopefully soon!

[chowdsp]

Hey folks,

Still working on a couple features and bugs for the next release, but I've added a new feature that I was hoping I could get some help with testing.

Basically, I've added "mix groups" so if you're using CHOW Tape on multiple channels in your mix, you can synchronize parameters between plugin instances. For more information on this feature, see here. I was hoping to get some feedback on this feature before including it in an official release. Specifically, I'm looking for:

1. Does the plugin crash on your system? I've only been able to test this feature on a Windows machine, and only in a couple of DAWs. I can definitely forsee some issues on other DAWs/systems.

2. Bugs, or any aspects of the feature that appear to be working incorrectly/incosistently.

3. If there's some difference between how you expect the feature to work, and how it appears to be working. This may require either a change in the documentation, or a change how the feature is implemented.

To try the feature, download the version 2.5.99 from GitHub. Since this version is different from the latest official release (2.5.0), the plugin will ask you if you want to update, which you can ignore for now. If you find a bug, please report either on this thread, or on GitHub (GitHub is preferred).

Thanks,
Jatin

[sengoku]

Hi, sorry I'm very slow at testing. Just got around to looking at the water bottle synth which is really cool, but I have a couple of ideas which might be not too difficult to implement. Is this the right place for it? Should I start a new thread? Or should I make a GitHub issue?

I'll get around to checking out the new tape machine soon, I promise.