Implementation is important... you need to be able to create a chain, for one.

Also, what about DSP plugs, like UA? Can they operate within the shell or is there always an "exit" required beforehand?

Why focusing on a chain? Not all plugins in a chain alias or distort and therefore don't need oversampling. It's more CPU efficient to oversample only those plugins that need it.

The more I think about it the more I realise - if not implemented directly in the DAW then what I want is a pair of processors I can place at point A and point B. The one at point A upsamples. The one at point B downsamples. Then you can place them on either end of a single plugin or a chain.

What I do not want is a container. I want to be able to immediately see, and open, any plugin that is being oversampled, without having to open a container.

Edit: most often I'll be wanting to do it with a single plugin, though. It's rare I'll have a chain of plugins requiring oversampling. Where I do have a chain of nonlinear plugins I've almost always chosen them because they already do internal oversampling or are otherwise minimising aliasing to below the -120dB point.

Well, that is also what I thought would be best in my original post. I don’t like containers, either.

However, if that’s the only way it can be implemented from a practical standpoint, then it makes sense to be able to chain multiple plug-ins within the shell. True, some don’t need it at all; but some plug-ins might see some benefit or you can turn off the plug-in‘a OS (not all implementations are great) and use the OS in the chain... I think it’s up to the user to string plug-ins in whatever way they see fit.

I could see a chain where there is a saturator adding a lot of harmonics followed by a compressor doing the same, followed by an EQ that could benefit from some de-cramping. Maybe even another saturation follows that.

Who knows; but if it is inconvenient to address all those individually, then I think a chain would simply be a practical feature of convenience.

Of course, you might hit a place where it makes more sense to run the session at a higher rate... fine. But, personally, I’m looking at the projects I’m mixing right now at 48k and can see a few select tracks where I would love this OS option without converting the whole session. Not everything I’m doing and the plug-ins I’m using would benefit across the board. Do I need OS on my kick, bass, toms, elec guitars? No... but my lead vocal, drum overheads and strings? Yeah, I would like that.

Again, we already have DDMF Metaplugin that does this... and it can string multiple plug-ins, so that’s not a stretch. My original post was really asking can we do this in a more elegant and simple way that doesn’t feel like we’re in the Logic Environment or some esoteric modular synth. I’d ideally like an implementation like Perception or LM MatchGain, but I’m digressing.

All your concerns can be addressed by the solution of a paired plugin in the form of A(upsampler)->device(s)->B(downsampler) without hiding plugins in a container.

Great. That’s exactly what I want. That’s why I keep mentioning the way Perception and LM GainMatch work. Exactly like that. Is it possible and practical?

Can someone make it, please?

Our plugin concepts specifically try to avoid having to resample input to output.
It's far cleaner and more effective to run each nonlinearity at its optimal rate, antialiasing only (!) the distortion it produces.

That's probably a reason why our resampling seems to work so well: For the most part, the signal passes input to output untouched, i.e. without being resampled.

The main problem with aliasing appears in the control signals, where it literally breaks the intended/promoted/promised function of a plugin. Say, a 0.2ms compression attack acting more like a random generator than a smoothing filter. This is aliasing. You often can't really solve this problem by simply increasing the overall I/O samplerate, it would require rates in the MHz range just to antialias a hard knee compressor theshold (= a clipper acting on the detected signal). This enormous bandwidth in turn provokes other issues with audio down the line (like unnecessary build up of inaudible HF content and IMD).

It's not that easy. Antialiasing is so much more that simply changing the samplerate. I can well understand the envy for experimentation, but DIY oversampling isn't that effective, it is costly and bottlenecks the original bandwidth.

I knew this but had forgotten. Thanks for the reminder.

Does this mean that containers like Metaplugin which are input to output resampling aren't really helping much? Or just that the amount they can help is limited but using such naive oversampling still has some benefit - though not as much as is commonly advertised/expected. If there is some reasonable benefit, does it compare well to running the entire project at that higher rate?

I've been good/lucky in mostly choosing (nonlinear) plugins which have clearly been coded by people (including TDR) who've thought about this carefully and through whatever method produced very clean output. I only have maybe 2 or 3 plugins which produce a notable amount of unwanted noise (as viewed in a spectrum analyser.) And I'm honestly not sure how audible it is since I'm not using more than one or two instances in a single project and everything else is quite clean.

Tried and tested all of them.
Liked and using - none.

I was thinking about this as well, but I am not sure that it would work.

My own understanding is admittedly not very deep yet, but I don't think this would work because a DAW still knows the sample rate that a project is running at and it needs to pass blocks of audio from one plugin to another. Maybe the DAW would not behave well if it is configured to be running a project at say 48kHz but this bookending up/down sampling chain has src-ed it to 192kHz?

Hopefully one of the smart people will comment on this so we know if it is possible.

This is a good point. I'm not sure what the DAW would do with the audio passing between the bookends and the device(s) you want upsampled.

If the bookend plugin was a native DAW device it would probably work since they could present it visually as two bookend plugins but internally it would be a container.

I'm also concerned about what Fabien wrote and hoping he finds the time to reply to my questions. I've considered buying Metaplugin before but if in addition to the container issue there's also minimal benefit then I'll stick to my current strategy of not buying a plugin until I've tested it for aliasing as well as evaluated the developer's attitude(s) toward the subject. Developers like TDR and Cytomic who take an approach to anti-aliasing which attempts to understand the complexities and deal with it in a non-naive manner will win most of my business from now on.

The Fuse stuff produces less audible distortion and color. Just has to be gainstaged into correctly. Trim massively and check the VU meters. You’re going to need to use trims before and after a lot of them. You don’t want to be clipping the input, post drive, and output meters on the V376 for example. You have three meters to monitor and you don’t even want to be hot on them because they’re VU meters so averaged over 50ms or so. -10 vu peaks. People need to treat plugins like they’re analog gear. 99% of analog gear sounds awful driven into the red and most sound bad with hot signal levels that don’t activate clipping indicators. Only Fuse plugin that does sound good in the red are the RCA pre (very nice grit), TCS-68 pre knob, and Flywheel barely hitting it and you don’t want the TCS-68 light to be going off all the time.

My biggest issue with this is finding the companies that are taking the same approach as Tokyo Dawn for me to fill out my kit.

The best I can do is aliasing tests really, but it gets annoying over time as honestly it’s a complete bloodbath, even at 96k.

Even seemingly great devs will have bizarre holes in their product range that alias while the rest of their plugins are on point.

Thanks. That hard knee point makes a lot of sense to why the SSL Style plugin compressors just don’t behave right. Even the Glue only behaves well on 1ms and slower attacks, 8x or 16x oversampling. The others are pretty hopeless. Even an 1176 knee doesn’t seem to work digitally. The emulations are really bad. DMG and UAD go nuts too often, Waves CLA 76 and Black Rooster VLA FET are clicky, Brainworx Purple 77 sounds like a clipper, and Overloud 76 can turn drums into a potato. In contrast, PSP Fetpressor, Goodhertz Faraday Limiter, and your Molot GE don’t try to be an 1176 at all and work wonderfully for real work.

There aren’t any. Stop clipping.

SlickEQ is the only Tokyo Dawn product with flexible tone anyway. The color on the others is inexistent or very imposing to the point where it will just make many things sound worse. Molot GE can do a lot more than the original but the heavy tone makes it usable on fewer things.

I have plenty in my setup that make the cut, so I’m not hurting. Just would like shiny new options that follow better practices.

I actually have decent hearing, thus I’m not down for ruining my mixes, so not taking your advice anytime soon.

Have fun with yours in the Matrix

Heavy tone? I replaced most of compressors with Molot GE just because it works better and more versatile... though, i cant stand the original version except on snare.

All of my THIS.

Fabien is so correct here. I do quite a bit of music in the analog domain and capture it at 96k, so I do find reason to resample. What do I use for that? A little program called Brick (pretty sure there are Windows equivalents) that doesn't run as a plugin, but as a standalone app. Why? Because it's using such a wide window to generate its brickwall filter that it can run twenty times slower than realtime on a relatively recent iMac Pro.

There are no half measures for resampling. You either hang on to the cleaner, rawer directness of the original sample rate, or you bring out the big guns and SRC properly… and you're not going to be able to do that all through your mix. Anytime people are using oversampling to fight aliasing, they're trading off one problem for another and throwing mass quantities of rather low quality digital filters all over what they do.

It's really not that easy. It's very likely that for normal audio the sound's gonna be subjectively better done the way Fabien does it: passing it through untouched. I recently did a plugin that bypasses itself when the lowpass filter's set to 'as high a pitch as possible': it's not just Fabien addressing digital this way. When I say 'bypasses itself' I don't mean 'multiply by 1.0' or 'the filter parameters end up producing no change in the frequency response', I mean 'if this condition is observed then we copy the input data word to the output directly' (while still running the EQ calculations, so we can go back to filtering without a glitch)

That one might well go on the 2-buss and I considered it important to not screw that up. If you oversampled it, it would break that particular functionality by making it impossible to pass through the data untouched.

I've also got a hard clipper algorithm (in several relevant plugins) that softens the onset AND exit from clipping on only already-clipped samples, explicitly to alter the high frequency behavior of hard clipping and break it up a bit. Since it's departing from what is 'accurate', it softens the grind more than you'd get from even the most perfectly oversampled hard clipping. If you unthinkingly oversampled that plugin 'to make it better', even with the most perfect oversampling, you'd be breaking the behavior that makes it produce the desired darkening of the hard-clipped sound.

Never assume that oversampling 'naive' plugins will always make them better. Firstly, some plugins aren't as naive as you think they are, and secondly not all sample rate conversions are created equal. You could simply be throwing in a double set of bad digital EQ for your trouble, in which case it'll only be better if you're trying to hard-clip an already very bright signal, producing so much aliasing against a treble-heavy signal that anything would be an improvement

Exactly, the saturation is so tunable that it’s very easy to shape into something usable for almost anything.

And where that doesn’t work, oversampled saturation (likely in parallel) can take its place, and then be ran into kotelnikov if needed.

A good combo for me is Voxengo’s vast collection of oversampled plugins along with Tokyo Dawn’s lineup, some fabfilters (the ones that don’t alias) and Toneboosters, which has really stepped it up lately.

I don’t like the new one on snare. Old one was best on snare, other individual drums, and vocals for me. The new one is a lot better on busses to make them sit but it has a very imposing burgundy color that I don’t like on most material.

I've seen comparisons of various downsampling algorithms and indeed some are far worse than others. And some are exceptionally good and at least on my machine (hardly top of the range) easily operate at faster than realtime without massive CPU load (when processing an input file - I am assuming this makes them efficient enough for realtime use.)

I'm fairly well convinced that TDR and Cytomic are using high quality filters for their oversampling.

I absolutely believe that what TDR does is the ideal. Oversampling parts of the audio that don't need it should be avoided if possible. The parts that they are oversampling, though, I believe sound better that way than passed through as is. Else why are they bothering?

I'm still unclear, though, on whether something like Metaplugin is doing more harm than good. I'm leaning toward staying away from it since I don't know the quality of its filters. Keeping use of my plugins which show nastier aliasing to a minimum (as in don't chain a bunch of them together) and perhaps completely replacing them (I don't use them much anymore anyway, not because of aliasing but because I've now got other devices which do similar things and I find more flexible. But sometimes I want that particular sound.)

This is quite interesting. Would this still work when running the whole session at a higher rate (by setting the DAW to that rate?) Or would that also break what it's trying to do?

Thanks for your input. I always find it interesting to read what you have to say.

The one that true-bypasses would be fine at a higher sample rate. I should point out that the problem with oversampling it (other than it's a filter, why oversample that?) is that if it's bypassed, you're doing two SRCs for no reason whatever. It doesn't 'break' the bypass somehow, it's just that you're damaging your audio for no reason.

The other one, the clipper that interacts with the clipped samples to soften them, would work correctly at the higher sample rate but would shift the 'treble softening' effect upwards as much as two octaves (for 48k to 192k). That would mean that the 'turn hard aliasing into a different sort of effect' would still be functional, but likely much less noticeable. In other words at high sample rates the hard clipping would sound 'harder' but would retain the effect. Oversampling to do this would just disarm the effect's ability to work without giving better time resolution for the effect to work on, so there would be no significant gains regarding aliasing. (the effect manipulates the time between the last nonclipped sample and the first clipped sample, so at high rates it still takes effect but oversampling just blurs this without adding new information)

Normally you don't care as much about the exact onset of clipping, because oversampling is more about introducing additional 'room' between the highest harmonic and Nyquist: Fabien's point still holds because if you're doing infinitely hard clipping there is no amount of room that will give you an absence of aliasing. It's only soft-clipping that gives you harmonics introduced low-first, in order, and lets you completely avoid aliasing within a given frequency band. All my clippers or compressors that sound good in digital have either soft clipping or controlled attacks that are much, much slower than 'infinitely fast attack' like a limiter might have.

It's not his mixes that sound to harsh, it's yours that sound too dull.

I just ran this compressor (model 5000) through analyser and I cannot understand why harmonics on 2k/4k/6k jump up and down in volume all the time (+/- 10 db)? Also, there seems to be some noise in low freq area...big bump which also dances all the time. So, any explanation whats going on with hamornics and weird LF noise?

Overall, this plugin sounds really fine and screenshot is taken at 88.2 khz/no oversampling.

"We also added a “TransX” input/output transformer option. When engaged, the TransX adds transformer coloration to the circuit, this brings a pleasing analog solid-state style saturation to the sound. The more the input gain, the more the drive."

Harmonics jump up and down with TransX on and off and it doesnt change the LF "noise" build up. So, my questions still stay.

does the 'model 5000' have a ByPass button ? where ?

I think there is none.

Ultrasonic by airwindows may help with aliasing issues.. http://www.airwindows.com/?s=ultrasonic


& here is a tool to help analyze..
https://www.bertomaudio.com/eqca.html

One of several options: first there was Tokyo Dawn's Ultrasonic. When I say several options I mean that they do the same thing but in distinct ways with distinct trade-offs…

Tokyo Dawn's is a truncated brickwall filter so it is far steeper and phase-linear but has a stopband with characteristic notches that would go away if it was a far larger, more CPU-intense, high latency filter like non-realtime SRC filters.

Mine's not a brickwall, it's just cascaded biquad filters. As such it doesn't add latency but it's not phase-linear, so you have to be okay with some high frequency smearing not present in the Tokyo Dawn filter. On the bright side, it gives way deeper rejection up around Nyquist, because it's not a brickwall but a simple lowpass: so the higher the sample rate, the more rejection you'll get.