About history
In recent history, I’ve constantly extended and improved my Stateful Saturation approach and within ThrillseekerVBL I’ve managed to introduce authentic analog style sounding distortion right into VST land, which is what I’ve always had in my mind and dreamed of. And there’s so much and overwhelming feedback on that – thank you sooo much!
Best of both worlds
Since quite a while, I’ve dreamed about a brand new series of plug-ins which will combine the strength of both worlds: analog modeling on the one side but pure digital techniques on the other – incorporating techniques such as look-ahead, FIR filtering or even stuff that comes from the digital image processing domain, such as HDR (High Dynamic Range) processing.
First encounter: SlickHDR
High Dynamic Range (HDR) processing is something pretty much new in the audio domain. While there are lots of theories and implementations available about HDR imaging, this is quite new and sparingly adopted in the audio domain. SlickHDR is going to be a very first approach in applying high dynamic range processing to audio within a VST compatible plug-in.
Variety Of Sound 
Cool man! VBL sounds awesome indeed!!!
Please, if possible, start the new plugins with 64 bit VST support! It’s very difficult to maintain both x86 and x64 hosts, plugins, etc. at the same time. However, your plugins are “must-have”s, so I keep both x86 nd x64 stuff.
Can’t wait to hear more news from this Slick series!
I could not agree more. I’m trying to eliminate all 32-bit plugs nowadays but not easy.
Sounds mighty interesting, and coming from you, I’d expect it to be something I would need but didn’t know I needed, until now … 😉
Mind dropping a hint in what direction this will take off, dynamics, EQ, nonlinearities, time-based FX or something entirely different ?
but what is high dynamic range processing in audio?
For imaging, high dynamic range involves higher per-sample resolution (dynamic range). For example, storing per-channel sample values using floating point values as opposed to integers in order to extend the dynamic range from (for example) 2^24 to either 2^32 or 2^64 depending on the choice in floating point type used. For audio, I’m guessing Bootsy intends to process waveform data using floating point operations internally, as opposed to using the 24-bit samples the VST API provides directly. If that’s the case, I wonder what the dithering considerations will be. I’m also wondering if there would be benefits to creating a single-plugin version of the entire plugin suite, so that the inter-plugin communication could be done via HDR as well, allowing chained plugins to fully benefit from HDR.
Either that or I’m totally wrong and it’s more like this — http://designingsound.org/2013/06/finding-your-way-with-high-dynamic-range-audio-in-wwise/ 🙂
@morfi: Pretty much like HDR processing in photography, but with audio:
http://en.wikipedia.org/wiki/Dynamic_range_compression
http://designingsound.org/2013/06/finding-your-way-with-high-dynamic-range-audio-in-wwise/
I do not know but hope to find it out via this link…
is the idea to have the same sonic effect on both low and high level audio? Could be good.
I though that HDR is achieved through a higher bit depth. isn´t there 32 bit float processing as standard for years now?
Neat!!!
Isn’t parallel compression just that? I mean, when you think about how those HDR images are created from non-HDR images!
This is called “pseudo/fake HDR” so 😉
Real HDR images are created by using multiple exposure stacked shots, creating a non-visible image in very high range (like 64bits float) and applying a tone mapping after to recreate a visible image (like a 24bits JPEG).
HDR word is even used for “Exposure Fusion” inside recent cameras…but it is not HDR.
Real HDR need a big computer to process.
To summarize : there is “fake HDR” from a single non HDR shot, “exposure fusion” witch create a final tone mapped picture without creating an HDR 64bits file (faster than HDR) and “real HDR” witch use an intermediate big HDR 64bits file and apply tone mapping afterward. (slower than the two other solutions).
Bootsy,
You are a genius! Can’t wait for Slick. I use Thrillseeker just about everyday!
Please make a de-eeser
Please port your plugs to OSX. Us Mac users are sad and lonely being left out in the cold…
i was thinking about parallelcompression as an example for that too.
but afaik there are special algorithms for combining the two ( sometimes three) pictures which represent the different light levels, they are not just mixed together, but kind of weighted in different areas.
but pictures are (mostly) made from static scenes, whereas audio is dynamic. a millisecond of audio could be seen as mostly static, so you extract lowlevel and highlevelparts from that and mix it in a special way?? just a thought … 🙂
yeah, the magic lies in the mixing and the so-called tone-mapping
thats the moment where Stateful Saturation chimes in since it does not look only at one sample but has a sort of memory. It all comes together right now …
sounds great!!! it is more like i think influencing dynamic ranges should be like. i experimented with working on the same instrument on several copied tracks, each one with a different compression/expansion treatment. but it is a tricky thing, that definitely has its limits.
looking forward …
Very exciting! I’m curious in what form this approach will manifest itself.
That sounds incredible. I’m a user of your modules since the Nasty Series days. Are you considering leaving the Synthmaker path in order to make your plugins more accessible to other platforms (32 + 64 bit, Win + Mac)? From my impression the WDL-OL framework is pretty well suited for that task (renders to all major formats). Klanghelm,LVC-Audio and the Kirnu Appregiator (among others) uses WDL-OL too!
Maybe this is the right moment for such a move: new plugin series based on a new approach + new framework = complete Varietyofsound takeover!
What will be the sonic equivalent of the light-probe then? 🙂
This is exciting stuff. Just to see someone thinking along these lines and experimenting with it.
I know that when I started using HDRI stuff in my 3D artwork, it really did just lift it all a level.
There are a lot of questions and a lot of contradictions here, but for now, I just look forward to seeing what this is all about.
I wish you loads of luck and enjoyment in this latest pursuit, but I have previously studied this HDR use and am not even remotely interested in plugins equipped with such. I most definitely don’t need one more factor to twiddle around with. I note that most of the newest plugins today process superbly without this. If I could ask for anything in the near future from VOS, it would be plugins taken away from SynthEdit, perhaps coded exclusively in something such as C++, a 0/-18dB input option on ALL plugins in order to fix that persistent and unresolved issue in some of these VST, and last but certainly not least a show of some intention to move to 64-bit. Fortunately, I have not been one of the many who experience the frequent crash issues of using VOS, but in all, I’d prefer to see a full and general overhaul of the plugin line rather than the embracing of this clearly dodgy HDR technology. And just a side note, since the internal processing of plugins got mention — most of my collection already do theirs in 64 internally, so this part is not something ‘broke’ that needs fixing.
me wants teasers
Interesting. Cant wait to check it out. All the best.
Cheers.
Have you encountered the ruby compatibility errors in Flowstone? (assuming you’ve gone to that development platform.)
no – I’m waiting for full 64bit support and then move on to Flowstone …