I hope not! I doubt if many people are willing to pay just for CLAP, especially this early in its development and adoption. My guess is that plugin makers who want to use CLAP as an excuse to charge extra will wait until CLAP is better established and its benefits are clear. The two CLAP plugins I have so far (from U-he and Audiority) both came as part of free updates.
@RAM_845 VST is not a REAL standard. It is a monopoly. They punish developers who support VST2 because they make money from VST3 licenses. VST3 hurts developers and users by limiting how it can be used and not supporting new innovations. CLAP is a TRUE open standard, it doesn't require a license, doesn't limit how it can be used, and has already shown commitment towards supporting new innovations in updates. CLAP is very important. A CLAP plugin created today, will always be supported, as there is no profit-motivated governing body to obsolete it for something inferior/restricted.
I have to say this is a pretty nice idea. The problem with most developers are they're obsessed over re-creating 60 year old designs and workflows in a computer. "The eagles didn't have 1176s talking to each other - why would we need to have plugins talk to each other?" We need more developers like DMG, Fabfilter, Goodhertz etc who do not start with the ancient workflow and start fresh with a perspective with current needs and processing capabilities in mind.
I feel like it's vicious cycle - passion for retro plugins is whipped up by celebrating the old ways and classic albums .. which then the plugin developers cater for , which then has users thinking about the old ways and feeling the passion, which has the plugin developers making more .. meanwhile the real vintage equipment buying frenzy is also pumping it all up too.
@@natdenchfield8061maybe it’s because im old, but that is connected to anything. I like guitar music, and if you like recorded instruments, most of the classic albums are recorded in a classic way. I don’t think any of the modern Neural DSP bands will be considered timeless or classic. So I think music that we consider classic is just not going to sound good when mixed with plugins that are too perfect. So we can embrace more digital perfected music, like techno, industrial , gridmetal etc . But me personally, I like a Siamese Dream or a Powerage. Those albums will not sound good with a perfected compressor, AI eq , electronic drum kit , 8 string guitar and other perfected versions. I’m all for development, but the music will go along with that. And that is for a younger generation
@@skeletonmodel Just another little point - if one has any skill at all, the tools don't change your vision of the sound you want to create. When tape would dull the sound, people boosted treble. If ITB compression is very clean, they will add distortion elsewhere ... ? If an engineer wants the sound of analogue EQs or compressors ... they can use outboard too. Look at Mr White Sea Studio and his options .. a good engineer knows it all, outboard and plugins . As I say the rest is about taste, about artists making music for themselves - if you personally feel left behind by their tastes... that's what happens to the average consumer. Personally, I love music and I find myself appreciating new and old equally .. maybe part of not seeing myself as old? (I also appreciate the recorded sound more and more - clean plugins allow you to absolutely focus on the sound from the mic, not worried about how some piece of gear is going to ruin it, dull it or whatever)
@@natdenchfield8061 I think boosting the treble on a tape recording will bring up a little more hiss compared to digital recordings with more high end etc. I don’t think it’s skill per se, you can be a great guitar player but not sound like a trumpet. I appreciate new music as well. But if you’re going to record the first Ramones album digitally, or In Utero, it’s just not going to sound the same. You can say that’s recorded crappy but that is raw and a sound you will not get in the box. You don’t have to, new music sounds great when it sounds like new music. But I don’t think you should try to sound like the old limited recordings with non limited gear. It’s just not the same. A photograph would’ve captured the Mona Lisa in far greater detail where you can focus on the Pureness of the image. Is it therefore better? Some disagree
Agreed, theres a sea of emulation right now. It feels like they only do it because it is the easiest way to program a plug-in. A lot of plugin ideas that needs to be made but they just fail to realize it
I am nobody in this sector, only i play piano (amateur), but i appreciate you so much for your integrity, i like to see your videos for it, you are so authentic!!! My great compliments to you
Reaper can handle upsampling a whole chain of plugins like that already, and then downsampling the chain, to my knowledge. That's not solving any problems mentioned otherwise, but quite a fine thing.
A lot of the things you described are already possible, but not in plugins, but DAW features. For example in Cubase Pro you can apply an offline processing effect chain to any audio event you want. It can include any realtime plugins you have and if you tweak a parameter in the middle of the chain it will automatically re-render the interleaved audio from that effect on. The only problem is that they didn't add this feature for a whole audio track, but I'm pretty sure they could do that if they wanted to. They already have implemented the pretty similiar track freeze feature. Another thing you mentioned was the oversampling thing. Why can't a plugin tell the next plugin that they could share the same oversampler to save some resources and sound quality? Well, Reaper has a feature, where you can wrap a whole effect chain in an oversampler. And Bitwig has even more useful containers, like a mid/side-container or several multiband ones, that make it easier to use small plugins, that don't bring a lot of features themselves. So all in all I think you should just focus on DAWs instead of plugins with the things you want. DAW features can solve all these problems without a new plugin format. The job of an audio plugin is just to synthesize or process audio or MIDI and it has all the available tools and information available for doing that already.
Many have already said this but CLAP is basically the plugin standard equivalent of a standard like Vulkan for graphics. Open Source, developed and supported by multiple DAW vendors (Bitwig, Presonus) and actually makes sense from a API sense. Something to also add is the DAWProject format that Bitwig and Presonus have introduced. Another open-source standard that actually manages to do cross-daw project sharing (no more stem/file exporting!).
Somehow I cannot see DAWProject being a good thing. The way I currently see it would just stagnate the daw development and/or eventually turn every daw exactly the same, essentially just different looking skinpacks of the same daw, because everything has to be done compatible with each other. While absolutely convenient idea in the short term, I cannot see any long term good happening from it. But of course my current stance could be because I may be ignorant of some relevant information. I'm open to change my mind if you could elaborate what good this could bring?
@@anteshell I disagree dude. You wrongly think that supporting a common format will force DAWs to drop features - that is not true. If you think of it as an IMPORT format, where the user is expected that only the core aspects of the project are going to be loaded, and that some things will not sound exact, it becomes much more useful. I admit that the usefulness of a universal project file that wont sound IDENTICAL between DAWs is questionable, it's still useful because often times we just want the BONES of a project, as a starting point!
Fl Studio is about to support CLAP. In 2 years since its release 2 major DAWs adopted CLAP and there's others thinking about adopting it. I truly believe CLAP will be the future but it may take a while.
The 'proxy render' option would be cool. It is something that's already very common in the Video Editing softwares. Something that would eliminate the need to do freezing or rendering the tracks etc. Basically it would 'pre-render' the track in real time, and it would keep the effects on the tracks, turning off the plugins (until they are tweaked again). It would make working on big projects easier and faster, even on worse computers.
TLDW: Wytse argues for a modern global universal standard for plugin development, DAW implementation and hosting. This means that plugins, DAWs and instruments would be able to communicate with one another and know what kind of processing is going on across a whole project.
Another standard we need to be widely adopted is some kind of royalty-free audio networking. I wish AVB - a 12 year old standard- was more widely adopted. ADAT I/O is not enough
I worked in standardization for years, be in a completely different field. I recognize everything you say, and you are right about everything. I often felt like an alien, because you hardly ever can explain why everything can't just be connected to each other and just exchange data. Standardization is in a way always a compromise and comes with (experienced) limitations. Getting all parties agreeing takes a lot of time and is more a matter of culture, egos and diplomacy. Als everyone has to make explicit what they want and do and that turns out to very difficult. There also have to be shared goals, and you need to trust each other. By now it may be clear we are detached from the technical level (and lost the developers and programmers). The key may be the concept of plugin that should work with every DAW. The more parties will hae to work with it, the less you can do. Interesting may be de facto standards like USB. Or how MIDI came about. In a way Germans seem to be good in standardization. Let's figure out why that is. From the start I thought CLAP was a stupid name which wouldn't facilitate it's acceptance.
When you said, that VST3 was finalized in 2008 and considering, that most plugins from 5 years ago where only supporting VST2, it tells you much about the development and adoption rate issues for any standard. Specifically, an open standard always begs the questions: who is going to invest their time in the development and support? What happens, when that development and support just stops? What I wished to be part of the standards next to inter-plugin and extended plugin-DAW communication was multicore CPU usage and (with hopefully enough love of GPU audio) GPU usage. Can you do the following: Have an interview with a developer on how VST3 vs. CLAP comparison looks like and why there are so little implementations of CLAP so far (like none of the major brands in the instrument and FX business aside from u-he). Because just asking for a new, better standard doesn't say much about if the current standards already have the features and are just not implementing it as they could and should. Also, a new standard means it needs to be adopted, specifically for business economic reasons. If it takes too much time or effort, it will not be adopted. If there's already a solution, why not use that and pay a few bucks? As of now, CLAP is mostly supported by rather small, unknown devs after two years. That doesn't sound good if you want a standard to take off.
The thing with CLAP is that most of the advantages it has over VST and AU are developer focused, not user focused. There are some advantages over VST for users as well, like better performance for modern CPUs, better plugin metadata and organization, built-in per-note automation and modulation (MIDI 2.0 and "MPE on steroids"), and ofc great cross-platform support. We will probably see more user centric improvements in the future, but until CLAP has become the de-facto plugin standard, most new improvements will probably be on the developer side just to make sure that most developers follow suit.
I think, to be able to do what you want, is to rethink how tracks in DAWs work. It is not a matter of a plugin-format. But a new way of thinking on tracks. I would also like to see the use of DATA streams integrated to the tracks, for controller functions, as well a ways of encoding time-codes, to do "look ahead", even with analog outboard gear, as it could buffer time-coded streams and sync them, to allow for time aligned parallel processing. And also the ability to stream tracks through the network, to use other computers to offload, with the data streams also enabling control of remote plugins, in an integrated way. I was thinking about writing Behringer about this when they were asking about what people would like in their new DAW. Not that I think they are necessarily the ones to pull it off well. But at least they were starting off fresh, and has some money behind them. The other thing I really would like to see is something like dawproject, being adopted by the whole industry. And DAW developers to the extent possible, releasing their custom plugins as standard format plugins, that I would be fine with requiring the ownership of their DAW to get access to. I mean, if it is possible to run Ableton Devices, as plugins in any other DAW, one might be more inclined to use them, if one is on a a multi-dawset-up. Whereas one might otherwise find 3rd party plugins, just to know that one is able to run them in any daw, at any point. That would of course also be required for a true multi daw format. I think the only ones really to potentially lose out with a proper multi-daw format is pro-tools, unless they are the ones inventing it, and getting some license fees for it. For everyone else, if they lose a customer for a couple of generations of the DAW, at least when they add the features people were looking for, the reason they switched, at least then it would be easy to switch back. And many more would be willing to be multi-daw users, expanding the over all market. And if I could dream, imagine being able to send a project, that comes with project specific licenses to plugins. So anyone opening it, could download the plugins, and if they don't have a license, they can use the project specific one. Yes, there would have to be some rules to how much one can change the project, to not be able to use it as a way of sharing plugins. But it would be fantastic for so many use cases. For collaboration. Or for the audio engineer that is tasked with mixing or mastering, being able to actually open up the plugins used and correct things as the plugin level, instead for having to ask the producer to fix and re-send. I would also see other smart ways of dealing with licenses, so that one is not locked out, when forgetting to either bring the USB key, or to release a license... There could be ways of solving it, by having to later connect to the same network as the computer that had the license in the firt place, not to be locked out. Or basically, getting rid of most offline licenses, but not requiring authorization ever time it is used, but at some interval, with limited possibilities of pausing autohorization.
Thank you for advertising your ideas. And by the way, before watching this video, I had no idea about the problem of sampling filters of several plugins. I think that this can be solved inside DAW, with a special built-in container plugin that internally upsamples and has a downsampling filter on the output. And the idea with proxy rendering is also great. In fact, everything for it is already inside the software. Since, for example, I do something similar manually. I'm just doing a bounce at the bottom of the original track. Then I turn it off. This allows me to always go back a step and change something. It also saves a huge amount of resources. All you need is to simply automate this process.
I have been thinking this for a while too, so many possibilities open up when vsts have "offline access". When I started I was very surprised you couldn't just check the LUFS whenever. Fortunately music software is an area where passionate people occasionally create things that don't necessarily make sense from a business standpoint (Reaper's Winrar-like selling strategy). So I do have some hope for the future. Awesome video, totally agree.
There are open protocols developed by the Linux community called LADSPA and LV2. Any standard that is not open is doomed to fail to be consumer-friendly as we have seen it so many times across the industry. I just wish LV2 had native support for DAWs running in MacOS
What you suggest is also marred with problems. Plugins looking ahead to a render ends up in a vortex in that the render needs to bounce down other plugins other than itself to get a picture, then others do the same, but also plugins are material sensitive to what they get in a moment in time and in a sequence, it basically can’t happen, everything needs to be sequentially interpreted in the moment like it is currently. Oversampling, to some degree the solution is to use a mega high sample rate in the project instead, but not everything needs to oversample, so there’s wastage. What CLAP brings is mainly freedom from Steinberg and a slightly better interface, but the DSP approach has to be the same sequentially. The biggest problem with plugins is CPU and what they have to do in short blocks without hogging too much. Thats why emulations try to capture the best perceived characteristics of what they are based on but can never manage it all, they skim because that’s all they can do.
Regarding oversampling, maybe each plugin could declare what sample rate its input and output channels should be, e.g. a reverb plugin might request 1x the project sample rate, but a distortion would request 8x or 16x the project rate. Then the DAW would insert appropriate up- and downsampling steps between the plugins. You could even extend this concept to automation parameters by treating them as additional audio channels, possibly at sample rates below the project rate. That would allow any plugin to output automation curves to (i.e. side-chain) any other plugin.
@@edwardfanboy it doesn’t really help because then all you do is shift the oversampling multiplication back to the DAW instead, which still has to go up and down sequentially in realtime between plugins, so there’s no greater efficiency achieved. But I’m not totally disagreeing that more shouldn’t be thrown back to the DAW, but there is already enough idiosyncrasies with what DAWs supply anyway, so it could open that up further, i.e, believe it or not, some plugins are doing host adaption, i.e. if ableton do this, something else do Y, which I think is fundamentally wrong and is working around discrepancies that shouldn’t exist (but the vendor is too scared to correct because those workarounds exist). Plugin architecture is generally quite good, but fundamental digital processing issues like oversampling will always be an issue in the digital realm, but generally the pros outweigh the cons and digital can do some things better than analog and vice versa, analog isn’t a perfect flow either. Maybe quantum computing would offer a paradigm shift in the way such problems are handled. Fundamentally what is mentioned in this video has been thought about many many times before, there’s simply no simplified solutions that don’t open up other cans of worms. Nothing is ever perfect in technology, but there are some small things that could be improved. Routing is one, like Studio Ones mix engine fx, one plugin at the start of the master chain getting and affecting every channel in the mixer was a good idea but that architecture already exists in plugins (multi ins, multi outs), it is DAWs that bottleneck that option here and dictate the flow.
@@bassc The advantages to shifting oversampling back to the DAW is that you can combine or eliminate resampling steps, and that it takes effort off the plugin developer to implement high-quality resampling. For example, if you have a synth using 2x oversampling followed by a distortion using 16x oversampling, you can do one 8x upsampling step instead of downsampling inside the synth then upsampling inside the distortion. DAWs already need to be able to resample audio so they can mix sound files that were created at different sample rates.
Ideas are possible. Here's one: a plugin wrapper that lets you tab transients and make break points so you can turn regions' volumes up and down. Then the plugin wrapper lets you use another plugin like a limiter or compressor. After the compressor, the plugin automatically reverses all your volume changes, restoring the macro dynamics. The point would be to let you prep your signal to feed consistently into a compressor or limiter so the processing works more like a micogroove shaper rather than a leveler, but then gives you your dynamics back on the back end. It could do busy work for you like analyze the new waveform for the nearest transient break points (they will shift around with processing). Or even automate the frontend of the process. Its kind of like conjugation in abstract mathematics g^-1*h*g. Curious about Sound Radix Pi. It uses info from all the tracks. Is the distinction that it can't have a global view of the session data?
I’ve been playing around with Suno lately and while the bitrate sounds pretty degraded, the overall mix quality is better than what I can produce with tons of paid plugins and a few years of learning what I can. It’s crazy to me that it can create a rounded professional style mix in seconds but side chaining is the most we can do to have tracks communicate with each other.
I come from the IT environment and am a big supporter of the OpenSource community, so I also contribute to it. I mean, especially in IT, the whole world is based on OpenSource projects. But I've also noticed that this open source and standardization community in the audio sector has fallen asleep a bit. I really like your idea and this approach to change something about it
ableton will be the last DAW to support it since BITWIG is one of the co-creators. I'd assume that ableton execs do not like bitwig as it was created from ex ableton employees.
I too have often thought about look ahead processing. I never really understood the limitations of VST or other formats, I always thought that the reason it was mot available was the stubbornness of old school industry types Your video really provoked some thought for me. Thank you
I suspect the 'look ahead' wouldn't work in the way you imagine. Although computers are very powerful now, rendering audio offline actually takes a lot of resources. You can see that with the new mastering feature in Logic: when you activate it, the DAW has to pause for quite a long time while it chews through the audio. And the problem is that every time you change something in your DAW, move a single fader, turn a single dial or or add in a single new plugin, your 'look ahead' algorithm would need to be updated. Could end up being a huge extra load on the CPU. So I suspect just doing this in the background all the time may not be that feasible?
When I hit play on my daw, the audio engine starts calculating all the tracks outputs and bus outputs and mix outputs. I press stop, and then play again, and the audio engine does exactly the same calculations all over again, and gets the same result again. Why not cache each tracks render as a hi quality wav file in RAM (we all have huge amounts of RAM these days), and then simply play the sample back next time. If the track changes or a plug in adjusted, then next playback calculate it again. The load on the processor would plummet. Saving the project could give the option to save all the renders out as well if needed. Then a plugin could easily 'look head' as the wave would be sitting there ready to inspect.
Your thoughts on offline processing at 5:15 remind me of the experimental DAW Blockhead where you see the waveform of your track audio get altered in real-time as you apply FX and tweak parameters.
I've been doing so much mixing and mastering in last year mostly EDM. I have learned so much, and one of things I've learned VST's cannot replace Hardware, and you will always have limitations so you have to adapt your knowledge to VST. Many engineers and "big" producers have sold their equipment, yet I hear phasing in their tracks, and things that would never appear if they used proper hardware. I hope one day there will be good enough analog emulation that can provide same results as it did 20 years ago, even tho tracks sounded "muddier" they were way cleaner and you could hear each element of track, something that digital VST's cannot provide unfortunate.
The CLAP format looks interesting also from a licensing standpoint. It’s got a license that is friendly to both opensource as well as commercial development, unlike VST which has this awkward dual license model. Steinberg where once innovators that brought a widely adopted plugin format but they have been resting on their laurels. When they created VST, they also created ASIO to go along with it. It was all fine and dendy in the 2000’s but users needs have changed since then. Development on ASIO is completely stagnant. Not much has changed to it since 1999! Meanwhile the landscape of audio hardware has changed, USB interfaces came along and since the last couple of years also synths, grooveboxes, drum machines etc with USB audio have appeared. But there is one thing holding them back, and that’s the rather old fashioned single-device architecture of ASIO. I feel that it is stuck in the 90’s and that a new driver standard is also required that allows multiple devices to be used under one driver in a reliable way, just like how you can plug multiple things into an analogue mixer and it just works. I’d like to see along side the CLAP plugin format a new, and open audio driver model. With open standards innovation can happen that can result in new solutions that can solve today’s needs as well as anticipate future needs. Wouldn’t it be cool if there could also be a specialised, audio oriented OS that could run any DAW and Plugin that doesn’t require a locked down computer?
I think you are right and things will close up. But it will be a time to look forward to. Because it can also be offline and can REALLY have the best out of both worlds, Analog&digital: Look at UDO Super Gemini. FPGAs are the future of audio devices. Hardware feel because of like 8x real time oversampling with close to no latency- and it will sound great. But it will need a hardware device to load „logic“ onto. FPGAs can load software structures as Hardware (programmed with HDL Hardware Description Languages) and run the logic at samplerates like 25 Mhz instead of 192 Khz. And they run processes in parallel and can even be used in parallel to normal MCU based environments
Coming from a web dev background and being a hobbyist musician, would be great to see something cross-platform so no matter which platform you're using whether PC or Mac it should work. I'm curious whether the DSP for Mac and PC are somehow different which is why people develop specific to that platform or just lazy to code it. Would love to learn more about how all this works since I'm curious what are the limitations
DSP code is usually c++ which is portable enough but to be efficient it has to be built on the specific platform architecture. The bigger problem is UI and OS differences/idiosyncrasies that are unique and need to be worked out and ever changing, which is why most develop in a cross platform framework like Juce. To make something cross platform with a single build, you would need to use an interpreted language like Java, but unfortunately they are too inefficient for realtime DSP because of the realtime translation they also need to do to make it happen.
Apples and oranges. And always will be. The direction McDsp took with their APB line is the first break-through since ProTools TDM in 1995 promised a true in-the-box studio when combined with great analog summing boxes.
@@iamlittylee Because everything is in a straight line. It's still almost entirely timeline-based. That's just tape for the new age, as it true with most daws. It's really great at what it does but what it does is handle a single timeline: - There's no real arranger - which as far as I can see only Cubase and Cakewalk have (ie not Bitwig either). Other daws that have something called an arranger is really just a jumped up copy and paste, ie a slightly more convenient method of splicing tape (if it actually works properly...). An arrangement in a real arranger calls one section of music then a different one then a third one, etc. It allows multiple arranger tracks to define sections, and multiple arrangements of your songs. It allows to render straight from your arrangement without having to commit it to the timeline first. [I know the SWS Region Playlist does some of this btw.] - There's no clip launcher. (Personally I think clip launchers need the ability to save an arrangement though. Multiple different arrangements actually. The whole "live" thing is a toy for most people. But I digress.) - Digital Performer has something called "chunks". (Terrible name.) These are complete or partial pieces of music including mixing, etc, that can be included on a timeline. They could be sub parts of songs for example. That way you can arrange things how you like on your timeline both horizontally and vertically to get it how you want. And you can nest as deeply as you like. One fact one place. The only problem is that DP is a horrible daw to use in my experience but the idea is brilliant. I'm sure there must be other ways of doing this sort of non-linear temporal flow and I am always interested to see / hear about them so don't take this as a comprehensive list.
I've often wondered why oversampling isn't managed at the DAW level. It seems like a logical step towards achieving consistency in audio processing across different plugins. Having oversampling centralized within the DAW could streamline the workflow and potentially enhance audio quality by solving the issue of multiple points of sample rate conversion within a processing chain.
I feel the same. There's so much possible and I feel constantly limited like we live in some stone age era, wasting computer resources and amazing workflow possibilities. Actually some solution would be DAWs implementing such internal plugins with offline capabilities and inter-talking themselves though, if the plugin companies won't be able to create some cool common standards
Everyone has a different opinion but I personally enjoy the open architecture of the PC instead of the closed Apple system however each succeeded due to this fact. The original Pro Tools system required 30 thousand pounds or dollars of hardware before you could use a single plugin eliminating most musicians from the ProTools recording business. There's definitely a rightful debate for both sides and always has been. Good video!
How about the ability to embed a frozen state of plugins into the host save? Meaning that even if you no longer had the plugins installed / authorized, you would be able at any time in the future, open a project on any computer with any newer OS/ Hardware , edit the audio and MIDI, remove frozen or add new plugins, render the audio and so on. In effect being able to save a project archive, complete with plugin state and without having to think about rendering all the audio tracks..?
I agree with you mate. The lookahead should be a thing. However, as a programmer (not in music) I see two problems. The massive amount of temp files being generated and managed because we all love to make changes all the time in the plug chain AND if you insert a non lookahead plugin in the chain. I still use some old VSTs in my projects and I don't think developers who are now gone to other projects will update their old stuff. BUT, saying that... I'm onboard! I hope someone does it. Maybe using GPUs. I mean, they would be ideal.
As much as I love that I can make music with DAWs. Some major parts of how they work have not developed in the least. The stuff that you're talking about definitely, but also channel summing wich could have a global plugin controlling how the summing is being calculated. Imitating an analog console sound would be a breeze with that. Plus it would open up other global level sonic processing. Theres been suggestions for a different sampling format. One wich could eliminate aliasing. Its still only an idea but I think it holds a lot of promise.
May I please correct one of the statement. Clap format is created and developed by Bitwig and U-He. Not only the latter one. Thank you. PS: Clap. Clever Audio Plugin API. Also Gonorrhea. Not sure I dig this name much… 🤭
I wonder if an upsampling/downsampling container vst is possible. Where you would load all the vst's into a container and let the container do the upsampling.
Interesting ideas, but I’m sure there’s some real, actual problems with implementing them, otherwise we would have them already. For one, the reason why plugins need to analyse in real-time, and can’t do it offline, is because unless they’re fist-in-chain they don’t scan the original audio file, they scan whatever comes out of the plugins that came before. If you wanted this process to go on automatically in the background, you’d need to run signal through all those plugins, and this would need to be done again every time you tweak any of those plugins. Same goes for the LUFS measurements. All of this would be eating up a good chunk of your processing power invisibly, under the hood. You’d need quite the clever programmer to make all those processes automatically pause the moment you press play, just so you’d have all the processing available when it’s actually needed to play the session. You could say that processors have become so fast these days that you could easily spare some amount of power, but that would depend completely on what computer and what type of project we’re talking about. Sure, the guy in the sweet spot with a monster machine, and sessions that are not completely insane, might have processing to spare, but what about the people running mammoth sessions, or the people on a relatively budget machine. The DAWs and plugin-manufacturers want to serve them all well, without having to make multiple versions of their software. So, I agree to an extent that we’re overdue a new standard, and that it would be very cool if it was more universal instead of multiple proprietary ones, but I think that on many aspects of this you’ll be running into good reasons for ‘why’ these things don’t exist yet. That said, I encourage you to talk to plugin developers and to try to get this ball rolling. If no one ever dreams outside the box, nothing ever happens. Good luck! ;)
@@chokocat9064 You’re not really disagreeing with what I said. The things I discussed are indeed DAW level, and I’m not saying it can’t be done. I’m saying it comes at a pretty high compute cost to do all this extra constant rendering. And most DAW developers choose to have their DAW run smoother rather than having more background rendering. I’m pretty sure DP doesn’t render ‘everything’ constantly, and restarts every time you make ‘any’ adjustment, just to be able to give you a constant accurate LUFS value. It does bits where it can, when there’s unused compute, to speed up processes, not at the expense of those processes. Also, just having a new plugin standard would require implementation in each DAW that wanted to be compatible. Having DAWs with these options available to plugins is the topic of the video.
@@chokocat9064I have an Apple Silicon Mac. I know they are powerful. You are not really talking about the same thing though. I’m not talking about just ‘any’ background task. I’m talking about tasks that would be invalidated the moment you touch the session. You can’t put them on hold while you’re doing something else, the moment you do something else, they have to recalculate. Answer me this question: Does DP give you a constant, accurate, LUFS reading?
@@chokocat9064 No, you did not address it, and this ‘is’ the actual type of thing the video was about. You know, the thing you said DP did already. One last time: we’re not talking about just any background rendering. We’re talking specifically about things like constant LUFS readings. You know, the topic. I ‘only’ mentioned background processes, in this context, because it would be the only way to do a constant LUFS reading. Same goes for a lot of the other things discusses in the video. You’re the one claiming DP does these things already. And this is simply not the case. Really, this discussion reminds me a lot of the very first time someone told me about DP, about 18 years ago. They were telling me about all the ways DP could mimic every other DAW, and that it was just better than all of them. Then when I tried it, it could ‘look’ ‘vaguely’ like other DAWs, but it worked like DP, and only like DP. Look, I get it, you like Digital Performer. That’s fine. If it works for you, that’s great. But stop acting like it has fixed all the things Witse is talking about kn the video, simply because it does a bit of background rendering. It does not do the things this video is talking about. No matter how much you try to deflect the point away from this.
@@chokocat9064 No, you did not address it, and this ‘is’ the actual type of thing the video was about. You know, the thing you said DP did already. One last time: we’re not talking about just any background rendering. We’re talking specifically about things like constant LUFS readings. You know, the topic. I ‘only’ mentioned background processes, in this context, because it would be the only way to do a constant LUFS reading. Same goes for a lot of the other things discusses in the video. You’re the one claiming DP does these things already. And this is simply not the case. Really, this discussion reminds me a lot of the very first time someone told me about DP, about 18 years ago. They were telling me about all the ways DP could mimic every other DAW, and that it was just better than all of them. Then when I tried it, it could ‘look’ ‘vaguely’ like other DAWs, but it worked like DP, and only like DP. Look, I get it, you like Digital Performer. That’s fine. If it works for you, that’s great. But stop acting like it has fixed all the things Witse is talking about in the video, simply because it does a bit of background rendering. It does not do the things this video is talking about. No matter how much you try to deflect the point away from this. Unless DP is sharing the functionality you’re talking about with plugins, you’re not talking about the same thing Witse and I are talking about. You just read ‘background processing’ and jumped on that. And even ‘if’ it did do all of that, which it doesn’t, it would still not be what the topic is about. Which is, a new standard for plugins, meaning that it should be universal, or at least compatible with more than one DAW. Yes, DP does some background rendering where it can, to lighten the load on the CPU. It’s a sort of auto freeze and de-freeze, running in the background. That’s not what we’re talking about here.
@@chokocat9064 You keep completely missing every point. No one is saying these processes should be implemented at the plugin level. Witse was asking for a new standard, so that every DAW would give plugins access to these processes so they could implement certain features. Did you even watch the video? Nowhere did I claim that DP didn’t do pre-lookup, nowhere am I saying it doesn’t do background pre-rendering, nowhere am I disputing that it can do ARA, or that things like ARA shouldn’t be done at the DAW level. And no, the features that Witse requests in the video are ‘not’ implemented anywhere, not even in DP. If you read my very first comment here correctly, you’d see that I actually agree that a lot of his requests should really be implemented at the DAW level, ‘and then offered to the plugins when they ask for some of those features’. See the difference? Also, no one is claiming DP is not the oldest, that wasn’t the point at all. Again, you’re defending against things I didn’t say. The point of my telling you about the first time I heard about DP was not to say that DP was ‘made to copy other DAWs’, of course it wasn’t. The point was that even back then people were telling me things they thought I wanted were already implemented in DP, when in fact they weren’t. One last time: yes, DP has background processing, and a lot more, I never said it didn’t. But it does ‘not’ have the features Witse was asking for, which is the point of this whole discussion. You can’t keep saying that it does these other, related things, and then when you come to the point say: well, that’s stupid and should be done at mastering. Yeah, I might even agree, but ‘that’s what Witse was asking for’. Just because I proposed that pre-rendering and some form of lookahead ‘could potentially’ be used to implement ‘some’ of the features Witse asked for, does ‘not’ mean that pre-rendering and lookahead ‘alone’ ‘are’ the actual thing Witse asked for. And more than that, I acknowledged, right from the start, that this is not really in the domain of plugins, and should be DAW-level implementations, that ‘then’ could possibly be made accessible to plugins, on the condition that each DAW implemented them in a compatible way. Please, read this as I wrote it, and stop imagining what I must have meant. This is getting silly. You’re fighting windmills.
What about Reaper's integrated oversampling functionalities? No communication between plugins, but we can set manually chain oversampling if I remember correctly.
Final Cut Pro already does automatic rendering whenever you stop manipulating stuff for a second. I can imagine a DAW making « freezing » tracks more automated. However, I think it would struggle with sidechaining tracks with each other.
Creating a new standard will just just be that, another standard that developers will need to write to in addition to the existing standards. VST2.4 is still widely used and it is 30 years old now. Currently the cost of development is so high that this doesn't make economic sense to try and create another new, competing standard. It is simply money. Something as big as a new effects SDK requires a lot of money and time not only in creating the standard, but in getting companies to support that standard.
The "universal upsampling communication" thing would be a pretty cool feature to just have automatically happen in the background, but I think getting it to work reliably would be a nightmare and a constant struggle, since it would depend on all the plugin devs implementing it correctly. That would mean more testing and dev time, and then having to continually support the feature when new plugins from other companies come out and one misbehaving plugin will ruin everything... yeah the more I think about it the more I realize it's probably for the best that plugins don't talk to each other too much, since it creates that many more points of failure. 🤣 - A simpler way to do this would be to just have the track itself be able to do the upsampling, and maybe even have containers of upsampled plugins. You can already do this with Reaper, or plugin loaders like DDMF Metaplugin, albeit in a more clunky (and sometimes buggy) manner.
The only thing what I wanna see in the future before I die is Blender 3D level of Open Source DAW while also using CLAP with it, it doesn't have to be perfect since not everyone will be please on every features of it but at least it can do what most big boys DAW can do (and it doesnt need to be as complicated a reaper lol)
These kind of "productivity plugins" are less of a niche market than we imagine, IMHO - the ideas you are talking about (ex: a look-ahead approach to a series of plugins) are excellent! Discord channel to brainstorm? :)
when you move into live sound some close systems are already there, like soundvision. you should get a programmer ally and start making a daw from scratch the way it should be with proper features as stock 😁
I don't understand the argument. A new, open standard would not guarantee that it supports all the nice features you're asking for. Portability of source code is essentially already there for quite some time through cross-platform frameworks such as JUCE. It's not optimal, but apparently a working solution.
what needs to stop is the "dropping a plugin" and "taking money" without servicing and upgrading it...it's like a hit and run strategy. PIs are software - and developers typically keep upgrading and updating their softwares, making it better...Looking at PA, tehy have plugins that have not changed in 5 or 10 years , and that just needs to stop. Apple, however, services products for years and years...Even very old iPhones still work. Oh and most of tehir software upgrades are free, free, free and always free. Logic X has been getting new plugins, features etc for 10 years without a dollar! Get your act together Universal Audio, Plugin Alliance etc...
I know that CLAP brings polyphonic modulations and things like that but I’m not sure it brings any improvements regarding how audio streams are processed.
Im not a programmer nor big head. But I think CLAP does change the way plugin use cpu resources and allow bi directional communication with host/plugin. So it well may be possible. But hosts will need to adapt too. I believe it’s a long time goal of bitwig because it’s just fit their ecosystem as in bitwig plugin or chains of plugins can be seen as one process.
Bitwgi and U-he are the founders of clap, try it out with openstagecontrol, just leave the old reaper cubase logic midi ancient stuff behind and stop complaining about problems that aren't there
@@JohnSmith-pn2vl did you just call reaper ancient stuff? I use bitwig but reaper is anything but ancient. Also, leaving midi behind isnt really possible currently. Although they are finally developing midi 2.
Plugins Are Great, And it’s More about learning when and When not to use them once you actually Learn How they Work and Not To Buy Duplicates which Just have A Different U i.
Maybe this is a bit off topic, but I'd really like to be able to use Ableton Max plugins in LPX pro. Guess it's impossible to create a Max host for other non-Ableton DAWs so their users can avail themselves of those devices without having to buy and learn an entire new program. Best we can do in theory is to connect Ableton to our DAW via Loopback .. and God knows how well that would work.
Yes. I have been thinking about this. There could be a more integrated approach. Maybe DAWs could be split up into 2 areas. 1. GUI and 2. processing. For example, I like using Reaper because of the UI. But, what if a company like SSL could build the back end processing for Reaper? So that you could have the customizable workflow UI and the signal processing of an SSL console. So DAW manufacturers could sell a version of their DAW that is just the GUI. So that software processing manufacturers could sell the back end processor. Maybe companies like SSL, API, NEVE, etc. I like the CLA mixhub. However, It doesn't have sends in the buckets. I understand why. But it is clunky. Or, I like the way Mixbus 32c has all of the EQ, Dynamics, Bussing built in. Or Studio One has “Mix FX.” If reaper had that feature I would probably use that. I find that just a touch of the crosstalk and drive does some really cool things. I like how it deals with things on a lower level - like crosstalk. I don’t know how this could be accomplished. But, I do know that the mixing in the box experience could be much better than it is.
IMO, the plugins themselves should not be doing upsampling. Upsampling should be global. If upsampling is enabled, all plugins are given upsampled audio by the DAW, and when all plugins are finished, the DAW downsamples it.
What is getting better is the realistic 3D shading on my screws in my plugins
Your studio is looking very nice these days.
If there’s one thing the industry can get behind together it’s definitely rereleasing every plugin in a new format that we need to purchase again.
I hope not! I doubt if many people are willing to pay just for CLAP, especially this early in its development and adoption. My guess is that plugin makers who want to use CLAP as an excuse to charge extra will wait until CLAP is better established and its benefits are clear. The two CLAP plugins I have so far (from U-he and Audiority) both came as part of free updates.
CLAP support is on the way for FL, it's currently being tested in the 2024 beta
It's already on BItwig too.
@RAM_845 VST is not a REAL standard. It is a monopoly. They punish developers who support VST2 because they make money from VST3 licenses. VST3 hurts developers and users by limiting how it can be used and not supporting new innovations. CLAP is a TRUE open standard, it doesn't require a license, doesn't limit how it can be used, and has already shown commitment towards supporting new innovations in updates. CLAP is very important. A CLAP plugin created today, will always be supported, as there is no profit-motivated governing body to obsolete it for something inferior/restricted.
@RAM_845 it's open source
@RAM_845 CLAP is not VST. It is a different plugin format. It's open source, very stable and also supposed to be more resource efficient.
@RAM_845it’s an open source standard that’s way more extensible and could replace VST entirely if given the chance
I have to say this is a pretty nice idea. The problem with most developers are they're obsessed over re-creating 60 year old designs and workflows in a computer. "The eagles didn't have 1176s talking to each other - why would we need to have plugins talk to each other?"
We need more developers like DMG, Fabfilter, Goodhertz etc who do not start with the ancient workflow and start fresh with a perspective with current needs and processing capabilities in mind.
I feel like it's vicious cycle - passion for retro plugins is whipped up by celebrating the old ways and classic albums .. which then the plugin developers cater for , which then has users thinking about the old ways and feeling the passion, which has the plugin developers making more .. meanwhile the real vintage equipment buying frenzy is also pumping it all up too.
@@natdenchfield8061maybe it’s because im old, but that is connected to anything. I like guitar music, and if you like recorded instruments, most of the classic albums are recorded in a classic way. I don’t think any of the modern Neural DSP bands will be considered timeless or classic. So I think music that we consider classic is just not going to sound good when mixed with plugins that are too perfect. So we can embrace more digital perfected music, like techno, industrial , gridmetal etc . But me personally, I like a Siamese Dream or a Powerage. Those albums will not sound good with a perfected compressor, AI eq , electronic drum kit , 8 string guitar and other perfected versions.
I’m all for development, but the music will go along with that. And that is for a younger generation
@@skeletonmodel Just another little point - if one has any skill at all, the tools don't change your vision of the sound you want to create.
When tape would dull the sound, people boosted treble.
If ITB compression is very clean, they will add distortion elsewhere ... ?
If an engineer wants the sound of analogue EQs or compressors ... they can use outboard too. Look at Mr White Sea Studio and his options .. a good engineer knows it all, outboard and plugins .
As I say the rest is about taste, about artists making music for themselves - if you personally feel left behind by their tastes... that's what happens to the average consumer.
Personally, I love music and I find myself appreciating new and old equally .. maybe part of not seeing myself as old?
(I also appreciate the recorded sound more and more - clean plugins allow you to absolutely focus on the sound from the mic, not worried about how some piece of gear is going to ruin it, dull it or whatever)
@@natdenchfield8061 I think boosting the treble on a tape recording will bring up a little more hiss compared to digital recordings with more high end etc.
I don’t think it’s skill per se, you can be a great guitar player but not sound like a trumpet.
I appreciate new music as well. But if you’re going to record the first Ramones album digitally, or In Utero, it’s just not going to sound the same. You can say that’s recorded crappy but that is raw and a sound you will not get in the box.
You don’t have to, new music sounds great when it sounds like new music. But I don’t think you should try to sound like the old limited recordings with non limited gear. It’s just not the same.
A photograph would’ve captured the Mona Lisa in far greater detail where you can focus on the Pureness of the image. Is it therefore better? Some disagree
Agreed, theres a sea of emulation right now. It feels like they only do it because it is the easiest way to program a plug-in.
A lot of plugin ideas that needs to be made but they just fail to realize it
I am nobody in this sector, only i play piano (amateur), but i appreciate you so much for your integrity, i like to see your videos for it, you are so authentic!!! My great compliments to you
I totally agree!
the genius of Dave Smith’s midi. RIP
Audio processing tech has always been behind. I've been saying this for years. I'm so glad you're saying this!
only people who have no clue whatsoever say this
Reaper can handle upsampling a whole chain of plugins like that already, and then downsampling the chain, to my knowledge.
That's not solving any problems mentioned otherwise, but quite a fine thing.
I think the open CLAP standard is seeking to solve what you're talking about.
Came to say the same. I use some u-he plugins in CLAP format in Bitwig.
Unfortunately it's not getting alot of support yet.
@@MrRacecourser fabfilter adopted it, so thats nice.
8:21
He's running reaper so he has support for CLAP, but yeah, developers need to get on that, also that new daw file saving standard and midi 2.0
A lot of the things you described are already possible, but not in plugins, but DAW features. For example in Cubase Pro you can apply an offline processing effect chain to any audio event you want. It can include any realtime plugins you have and if you tweak a parameter in the middle of the chain it will automatically re-render the interleaved audio from that effect on. The only problem is that they didn't add this feature for a whole audio track, but I'm pretty sure they could do that if they wanted to. They already have implemented the pretty similiar track freeze feature. Another thing you mentioned was the oversampling thing. Why can't a plugin tell the next plugin that they could share the same oversampler to save some resources and sound quality? Well, Reaper has a feature, where you can wrap a whole effect chain in an oversampler. And Bitwig has even more useful containers, like a mid/side-container or several multiband ones, that make it easier to use small plugins, that don't bring a lot of features themselves. So all in all I think you should just focus on DAWs instead of plugins with the things you want. DAW features can solve all these problems without a new plugin format. The job of an audio plugin is just to synthesize or process audio or MIDI and it has all the available tools and information available for doing that already.
Thank you! There’s cubase for that 😊
Many have already said this but CLAP is basically the plugin standard equivalent of a standard like Vulkan for graphics.
Open Source, developed and supported by multiple DAW vendors (Bitwig, Presonus) and actually makes sense from a API sense.
Something to also add is the DAWProject format that Bitwig and Presonus have introduced. Another open-source standard that actually manages to do cross-daw project sharing (no more stem/file exporting!).
Somehow I cannot see DAWProject being a good thing. The way I currently see it would just stagnate the daw development and/or eventually turn every daw exactly the same, essentially just different looking skinpacks of the same daw, because everything has to be done compatible with each other.
While absolutely convenient idea in the short term, I cannot see any long term good happening from it. But of course my current stance could be because I may be ignorant of some relevant information. I'm open to change my mind if you could elaborate what good this could bring?
Presonus doesn’t support clap.
I think you mean FLStudio, not Presonus.
are you refering to ARA or something?
@@anteshell I disagree dude. You wrongly think that supporting a common format will force DAWs to drop features - that is not true. If you think of it as an IMPORT format, where the user is expected that only the core aspects of the project are going to be loaded, and that some things will not sound exact, it becomes much more useful. I admit that the usefulness of a universal project file that wont sound IDENTICAL between DAWs is questionable, it's still useful because often times we just want the BONES of a project, as a starting point!
Fl Studio is about to support CLAP. In 2 years since its release 2 major DAWs adopted CLAP and there's others thinking about adopting it. I truly believe CLAP will be the future but it may take a while.
Three major DAWs nos that FLStudio beta has it.
The 'proxy render' option would be cool. It is something that's already very common in the Video Editing softwares. Something that would eliminate the need to do freezing or rendering the tracks etc. Basically it would 'pre-render' the track in real time, and it would keep the effects on the tracks, turning off the plugins (until they are tweaked again). It would make working on big projects easier and faster, even on worse computers.
TLDW: Wytse argues for a modern global universal standard for plugin development, DAW implementation and hosting. This means that plugins, DAWs and instruments would be able to communicate with one another and know what kind of processing is going on across a whole project.
sounds like communism to me KKona LUL
@@ComplexConfiguration That's not funny
Yes it was funny and you made it funnier, thanks
Another standard we need to be widely adopted is some kind of royalty-free audio networking. I wish AVB - a 12 year old standard- was more widely adopted. ADAT I/O is not enough
FL has Clap support in beta
I hope to see it in Studio One sometime
And what about ARA? You know, the thing Melodyne uses - seems to have offline access to multiple tracks :)
For the first point there is ARA (Audio Random Access) which was developed by the company of Melodyne. Else a plugin like Melodyne would not work.
Just in case you don't know: Digital Performer will PRE-RENDER plugins--which is pretty much what you're talking about--if you want it to.
I worked in standardization for years, be in a completely different field. I recognize everything you say, and you are right about everything. I often felt like an alien, because you hardly ever can explain why everything can't just be connected to each other and just exchange data. Standardization is in a way always a compromise and comes with (experienced) limitations. Getting all parties agreeing takes a lot of time and is more a matter of culture, egos and diplomacy. Als everyone has to make explicit what they want and do and that turns out to very difficult. There also have to be shared goals, and you need to trust each other. By now it may be clear we are detached from the technical level (and lost the developers and programmers). The key may be the concept of plugin that should work with every DAW. The more parties will hae to work with it, the less you can do. Interesting may be de facto standards like USB. Or how MIDI came about. In a way Germans seem to be good in standardization. Let's figure out why that is. From the start I thought CLAP was a stupid name which wouldn't facilitate it's acceptance.
The Mooger Fooger Plugins also communicate with each other + the Moog Marina Plugin
When you said, that VST3 was finalized in 2008 and considering, that most plugins from 5 years ago where only supporting VST2, it tells you much about the development and adoption rate issues for any standard. Specifically, an open standard always begs the questions: who is going to invest their time in the development and support? What happens, when that development and support just stops?
What I wished to be part of the standards next to inter-plugin and extended plugin-DAW communication was multicore CPU usage and (with hopefully enough love of GPU audio) GPU usage.
Can you do the following: Have an interview with a developer on how VST3 vs. CLAP comparison looks like and why there are so little implementations of CLAP so far (like none of the major brands in the instrument and FX business aside from u-he). Because just asking for a new, better standard doesn't say much about if the current standards already have the features and are just not implementing it as they could and should. Also, a new standard means it needs to be adopted, specifically for business economic reasons. If it takes too much time or effort, it will not be adopted. If there's already a solution, why not use that and pay a few bucks? As of now, CLAP is mostly supported by rather small, unknown devs after two years. That doesn't sound good if you want a standard to take off.
When Juce officially supports Clap it’ll start to take off with devs, unfortunately they’re not in a hurry to look at it.
The thing with CLAP is that most of the advantages it has over VST and AU are developer focused, not user focused. There are some advantages over VST for users as well, like better performance for modern CPUs, better plugin metadata and organization, built-in per-note automation and modulation (MIDI 2.0 and "MPE on steroids"), and ofc great cross-platform support. We will probably see more user centric improvements in the future, but until CLAP has become the de-facto plugin standard, most new improvements will probably be on the developer side just to make sure that most developers follow suit.
I think, to be able to do what you want, is to rethink how tracks in DAWs work. It is not a matter of a plugin-format. But a new way of thinking on tracks. I would also like to see the use of DATA streams integrated to the tracks, for controller functions, as well a ways of encoding time-codes, to do "look ahead", even with analog outboard gear, as it could buffer time-coded streams and sync them, to allow for time aligned parallel processing. And also the ability to stream tracks through the network, to use other computers to offload, with the data streams also enabling control of remote plugins, in an integrated way.
I was thinking about writing Behringer about this when they were asking about what people would like in their new DAW. Not that I think they are necessarily the ones to pull it off well. But at least they were starting off fresh, and has some money behind them.
The other thing I really would like to see is something like dawproject, being adopted by the whole industry. And DAW developers to the extent possible, releasing their custom plugins as standard format plugins, that I would be fine with requiring the ownership of their DAW to get access to. I mean, if it is possible to run Ableton Devices, as plugins in any other DAW, one might be more inclined to use them, if one is on a a multi-dawset-up. Whereas one might otherwise find 3rd party plugins, just to know that one is able to run them in any daw, at any point. That would of course also be required for a true multi daw format. I think the only ones really to potentially lose out with a proper multi-daw format is pro-tools, unless they are the ones inventing it, and getting some license fees for it. For everyone else, if they lose a customer for a couple of generations of the DAW, at least when they add the features people were looking for, the reason they switched, at least then it would be easy to switch back. And many more would be willing to be multi-daw users, expanding the over all market.
And if I could dream, imagine being able to send a project, that comes with project specific licenses to plugins. So anyone opening it, could download the plugins, and if they don't have a license, they can use the project specific one. Yes, there would have to be some rules to how much one can change the project, to not be able to use it as a way of sharing plugins.
But it would be fantastic for so many use cases. For collaboration. Or for the audio engineer that is tasked with mixing or mastering, being able to actually open up the plugins used and correct things as the plugin level, instead for having to ask the producer to fix and re-send.
I would also see other smart ways of dealing with licenses, so that one is not locked out, when forgetting to either bring the USB key, or to release a license... There could be ways of solving it, by having to later connect to the same network as the computer that had the license in the firt place, not to be locked out. Or basically, getting rid of most offline licenses, but not requiring authorization ever time it is used, but at some interval, with limited possibilities of pausing autohorization.
Thank you for advertising your ideas. And by the way, before watching this video, I had no idea about the problem of sampling filters of several plugins. I think that this can be solved inside DAW, with a special built-in container plugin that internally upsamples and has a downsampling filter on the output. And the idea with proxy rendering is also great. In fact, everything for it is already inside the software. Since, for example, I do something similar manually. I'm just doing a bounce at the bottom of the original track. Then I turn it off. This allows me to always go back a step and change something. It also saves a huge amount of resources. All you need is to simply automate this process.
I have been thinking this for a while too, so many possibilities open up when vsts have "offline access". When I started I was very surprised you couldn't just check the LUFS whenever.
Fortunately music software is an area where passionate people occasionally create things that don't necessarily make sense from a business standpoint (Reaper's Winrar-like selling strategy). So I do have some hope for the future.
Awesome video, totally agree.
why would anyone need this except mastering engineers who should use a Mastering Software not a daw in the first place.
Very good Wytse! Thanks for always pushing the audio world to get better and better!
Oversampling one is spot on...
There are open protocols developed by the Linux community called LADSPA and LV2. Any standard that is not open is doomed to fail to be consumer-friendly as we have seen it so many times across the industry. I just wish LV2 had native support for DAWs running in MacOS
What you suggest is also marred with problems. Plugins looking ahead to a render ends up in a vortex in that the render needs to bounce down other plugins other than itself to get a picture, then others do the same, but also plugins are material sensitive to what they get in a moment in time and in a sequence, it basically can’t happen, everything needs to be sequentially interpreted in the moment like it is currently. Oversampling, to some degree the solution is to use a mega high sample rate in the project instead, but not everything needs to oversample, so there’s wastage. What CLAP brings is mainly freedom from Steinberg and a slightly better interface, but the DSP approach has to be the same sequentially. The biggest problem with plugins is CPU and what they have to do in short blocks without hogging too much. Thats why emulations try to capture the best perceived characteristics of what they are based on but can never manage it all, they skim because that’s all they can do.
Regarding oversampling, maybe each plugin could declare what sample rate its input and output channels should be, e.g. a reverb plugin might request 1x the project sample rate, but a distortion would request 8x or 16x the project rate. Then the DAW would insert appropriate up- and downsampling steps between the plugins.
You could even extend this concept to automation parameters by treating them as additional audio channels, possibly at sample rates below the project rate. That would allow any plugin to output automation curves to (i.e. side-chain) any other plugin.
@@edwardfanboy it doesn’t really help because then all you do is shift the oversampling multiplication back to the DAW instead, which still has to go up and down sequentially in realtime between plugins, so there’s no greater efficiency achieved. But I’m not totally disagreeing that more shouldn’t be thrown back to the DAW, but there is already enough idiosyncrasies with what DAWs supply anyway, so it could open that up further, i.e, believe it or not, some plugins are doing host adaption, i.e. if ableton do this, something else do Y, which I think is fundamentally wrong and is working around discrepancies that shouldn’t exist (but the vendor is too scared to correct because those workarounds exist). Plugin architecture is generally quite good, but fundamental digital processing issues like oversampling will always be an issue in the digital realm, but generally the pros outweigh the cons and digital can do some things better than analog and vice versa, analog isn’t a perfect flow either. Maybe quantum computing would offer a paradigm shift in the way such problems are handled. Fundamentally what is mentioned in this video has been thought about many many times before, there’s simply no simplified solutions that don’t open up other cans of worms. Nothing is ever perfect in technology, but there are some small things that could be improved. Routing is one, like Studio Ones mix engine fx, one plugin at the start of the master chain getting and affecting every channel in the mixer was a good idea but that architecture already exists in plugins (multi ins, multi outs), it is DAWs that bottleneck that option here and dictate the flow.
@@bassc The advantages to shifting oversampling back to the DAW is that you can combine or eliminate resampling steps, and that it takes effort off the plugin developer to implement high-quality resampling. For example, if you have a synth using 2x oversampling followed by a distortion using 16x oversampling, you can do one 8x upsampling step instead of downsampling inside the synth then upsampling inside the distortion. DAWs already need to be able to resample audio so they can mix sound files that were created at different sample rates.
Ideas are possible. Here's one: a plugin wrapper that lets you tab transients and make break points so you can turn regions' volumes up and down. Then the plugin wrapper lets you use another plugin like a limiter or compressor. After the compressor, the plugin automatically reverses all your volume changes, restoring the macro dynamics. The point would be to let you prep your signal to feed consistently into a compressor or limiter so the processing works more like a micogroove shaper rather than a leveler, but then gives you your dynamics back on the back end. It could do busy work for you like analyze the new waveform for the nearest transient break points (they will shift around with processing). Or even automate the frontend of the process. Its kind of like conjugation in abstract mathematics g^-1*h*g.
Curious about Sound Radix Pi. It uses info from all the tracks. Is the distinction that it can't have a global view of the session data?
NEVER say never!
I’ve been playing around with Suno lately and while the bitrate sounds pretty degraded, the overall mix quality is better than what I can produce with tons of paid plugins and a few years of learning what I can. It’s crazy to me that it can create a rounded professional style mix in seconds but side chaining is the most we can do to have tracks communicate with each other.
Hasn't Reaper solved the up/downsampling thing by making it possible to upsample the signal within the whole plugin chain?
I may be wrong but I’m pretty sure FL Studio added CLAP recently.
I come from the IT environment and am a big supporter of the OpenSource community, so I also contribute to it. I mean, especially in IT, the whole world is based on OpenSource projects. But I've also noticed that this open source and standardization community in the audio sector has fallen asleep a bit. I really like your idea and this approach to change something about it
I really love that you referenced the xkcd standards comic :D
Dont worry, I'm sure we'll get CLAP support in Ableton by 2052
maybe
ableton will be the last DAW to support it since BITWIG is one of the co-creators. I'd assume that ableton execs do not like bitwig as it was created from ex ableton employees.
Ableton dont need clap.
I too have often thought about look ahead processing. I never really understood the limitations of VST or other formats, I always thought that the reason it was mot available was the stubbornness of old school industry types
Your video really provoked some thought for me. Thank you
I suspect the 'look ahead' wouldn't work in the way you imagine. Although computers are very powerful now, rendering audio offline actually takes a lot of resources. You can see that with the new mastering feature in Logic: when you activate it, the DAW has to pause for quite a long time while it chews through the audio. And the problem is that every time you change something in your DAW, move a single fader, turn a single dial or or add in a single new plugin, your 'look ahead' algorithm would need to be updated. Could end up being a huge extra load on the CPU. So I suspect just doing this in the background all the time may not be that feasible?
2:05 it is caller propellerhead reason (before it allowed VST user remained decades without vst...never made so many track that at that time)
Facts! I loved reason when it was closed off to outside vsts. It was super stable. I made so many beats with version 5.
Coffee ad cookies ... absolutely brilliant analysis of our current state of bit candy ... you rock
Reason tried to do a closed ecosystem, look at them now.
UAD recently opened their plugins for use outside their hardware.
UAD’s native plug-ins came way too late IMO
When I hit play on my daw, the audio engine starts calculating all the tracks outputs and bus outputs and mix outputs. I press stop, and then play again, and the audio engine does exactly the same calculations all over again, and gets the same result again. Why not cache each tracks render as a hi quality wav file in RAM (we all have huge amounts of RAM these days), and then simply play the sample back next time. If the track changes or a plug in adjusted, then next playback calculate it again. The load on the processor would plummet. Saving the project could give the option to save all the renders out as well if needed. Then a plugin could easily 'look head' as the wave would be sitting there ready to inspect.
@@chokocat9064 Interesting, I didn't know that. I'll go check that out
Your thoughts on offline processing at 5:15 remind me of the experimental DAW Blockhead where you see the waveform of your track audio get altered in real-time as you apply FX and tweak parameters.
i've had the same thought about wishing plugins could do lookahead/offline processing
I've been doing so much mixing and mastering in last year mostly EDM. I have learned so much, and one of things I've learned VST's cannot replace Hardware, and you will always have limitations so you have to adapt your knowledge to VST. Many engineers and "big" producers have sold their equipment, yet I hear phasing in their tracks, and things that would never appear if they used proper hardware.
I hope one day there will be good enough analog emulation that can provide same results as it did 20 years ago, even tho tracks sounded "muddier" they were way cleaner and you could hear each element of track, something that digital VST's cannot provide unfortunate.
Korg gadget instruments are now useble outside of gadget as well
All we.need is more cowbell
The CLAP format looks interesting also from a licensing standpoint. It’s got a license that is friendly to both opensource as well as commercial development, unlike VST which has this awkward dual license model. Steinberg where once innovators that brought a widely adopted plugin format but they have been resting on their laurels. When they created VST, they also created ASIO to go along with it. It was all fine and dendy in the 2000’s but users needs have changed since then. Development on ASIO is completely stagnant. Not much has changed to it since 1999! Meanwhile the landscape of audio hardware has changed, USB interfaces came along and since the last couple of years also synths, grooveboxes, drum machines etc with USB audio have appeared. But there is one thing holding them back, and that’s the rather old fashioned single-device architecture of ASIO. I feel that it is stuck in the 90’s and that a new driver standard is also required that allows multiple devices to be used under one driver in a reliable way, just like how you can plug multiple things into an analogue mixer and it just works. I’d like to see along side the CLAP plugin format a new, and open audio driver model. With open standards innovation can happen that can result in new solutions that can solve today’s needs as well as anticipate future needs. Wouldn’t it be cool if there could also be a specialised, audio oriented OS that could run any DAW and Plugin that doesn’t require a locked down computer?
I think you are right and things will close up. But it will be a time to look forward to. Because it can also be offline and can REALLY have the best out of both worlds, Analog&digital: Look at UDO Super Gemini. FPGAs are the future of audio devices. Hardware feel because of like 8x real time oversampling with close to no latency- and it will sound great. But it will need a hardware device to load „logic“ onto.
FPGAs can load software structures as Hardware (programmed with HDL Hardware Description Languages) and run the logic at samplerates like 25 Mhz instead of 192 Khz. And they run processes in parallel and can even be used in parallel to normal MCU based environments
Coming from a web dev background and being a hobbyist musician, would be great to see something cross-platform so no matter which platform you're using whether PC or Mac it should work. I'm curious whether the DSP for Mac and PC are somehow different which is why people develop specific to that platform or just lazy to code it. Would love to learn more about how all this works since I'm curious what are the limitations
DSP code is usually c++ which is portable enough but to be efficient it has to be built on the specific platform architecture. The bigger problem is UI and OS differences/idiosyncrasies that are unique and need to be worked out and ever changing, which is why most develop in a cross platform framework like Juce. To make something cross platform with a single build, you would need to use an interpreted language like Java, but unfortunately they are too inefficient for realtime DSP because of the realtime translation they also need to do to make it happen.
I think image-line hasa clap support for fl studio in the current beta.
very interesting, so is this time in music and the world. Thanks!
Im okay with my fab filter suite 😎
Apples and oranges. And always will be. The direction McDsp took with their APB line is the first break-through since ProTools TDM in 1995 promised a true in-the-box studio when combined with great analog summing boxes.
Reaper lets you set the upsampling for a whole plugin chain. Each plugins 'sees' the chain's sample rate as if it were the session's sampling rate.
Some brilliant ideas you have there! Hope to see them one day become a reality
Reaper is the DAW for rebels
And I , for one, do not fear it!
Bitwig is that, reaper is the old school way of making music just like Cubase Logic etc
@@JohnSmith-pn2vlold school? lol why is that
@@JohnSmith-pn2vl yes I was a Cubase user from old. In a DAW I’m looking for an accurate digital multitrack pretty much
@@iamlittylee Because everything is in a straight line. It's still almost entirely timeline-based. That's just tape for the new age, as it true with most daws. It's really great at what it does but what it does is handle a single timeline:
- There's no real arranger - which as far as I can see only Cubase and Cakewalk have (ie not Bitwig either). Other daws that have something called an arranger is really just a jumped up copy and paste, ie a slightly more convenient method of splicing tape (if it actually works properly...). An arrangement in a real arranger calls one section of music then a different one then a third one, etc. It allows multiple arranger tracks to define sections, and multiple arrangements of your songs. It allows to render straight from your arrangement without having to commit it to the timeline first. [I know the SWS Region Playlist does some of this btw.]
- There's no clip launcher. (Personally I think clip launchers need the ability to save an arrangement though. Multiple different arrangements actually. The whole "live" thing is a toy for most people. But I digress.)
- Digital Performer has something called "chunks". (Terrible name.) These are complete or partial pieces of music including mixing, etc, that can be included on a timeline. They could be sub parts of songs for example. That way you can arrange things how you like on your timeline both horizontally and vertically to get it how you want. And you can nest as deeply as you like. One fact one place. The only problem is that DP is a horrible daw to use in my experience but the idea is brilliant.
I'm sure there must be other ways of doing this sort of non-linear temporal flow and I am always interested to see / hear about them so don't take this as a comprehensive list.
I've often wondered why oversampling isn't managed at the DAW level. It seems like a logical step towards achieving consistency in audio processing across different plugins. Having oversampling centralized within the DAW could streamline the workflow and potentially enhance audio quality by solving the issue of multiple points of sample rate conversion within a processing chain.
I feel the same. There's so much possible and I feel constantly limited like we live in some stone age era, wasting computer resources and amazing workflow possibilities. Actually some solution would be DAWs implementing such internal plugins with offline capabilities and inter-talking themselves though, if the plugin companies won't be able to create some cool common standards
What is it that the VST standard can't accommodate? Oh you answered that. I should have been more patient 😂
I've also wondered about why there has not been any offline processing style plugins. Now I know a bit more about why it hasn't been done.
Everyone has a different opinion but I personally enjoy the open architecture of the PC instead of the closed Apple system however each succeeded due to this fact. The original Pro Tools system required 30 thousand pounds or dollars of hardware before you could use a single plugin eliminating most musicians from the ProTools recording business. There's definitely a rightful debate for both sides and always has been. Good video!
7:11 a DAW should be able to do upsampling/downsampling in a chain though. Since it already knows which plugin is doing what. Much easier solution.
How about the ability to embed a frozen state of plugins into the host save? Meaning that even if you no longer had the plugins installed / authorized, you would be able at any time in the future, open a project on any computer with any newer OS/ Hardware , edit the audio and MIDI, remove frozen or add new plugins, render the audio and so on. In effect being able to save a project archive, complete with plugin state and without having to think about rendering all the audio tracks..?
I agree with you mate. The lookahead should be a thing. However, as a programmer (not in music) I see two problems. The massive amount of temp files being generated and managed because we all love to make changes all the time in the plug chain AND if you insert a non lookahead plugin in the chain. I still use some old VSTs in my projects and I don't think developers who are now gone to other projects will update their old stuff. BUT, saying that... I'm onboard! I hope someone does it. Maybe using GPUs. I mean, they would be ideal.
Could you make a video about the difference between a clipper and a limiter and how to use them in conjuction with eachother? Thank you in advance
As much as I love that I can make music with DAWs. Some major parts of how they work have not developed in the least.
The stuff that you're talking about definitely, but also channel summing wich could have a global plugin controlling how the summing is being calculated. Imitating an analog console sound would be a breeze with that. Plus it would open up other global level sonic processing.
Theres been suggestions for a different sampling format. One wich could eliminate aliasing. Its still only an idea but I think it holds a lot of promise.
May I please correct one of the statement. Clap format is created and developed by Bitwig and U-He. Not only the latter one. Thank you.
PS: Clap. Clever Audio Plugin API. Also Gonorrhea. Not sure I dig this name much… 🤭
I'm waaaaay behind the time!!......I've never heard of clap!?!? 🤷♂😕. I hope your message come to fruition. I'd stand behind a new standard 😉👍
Hardware is more expensive . Or is it ? Maybe time to reconsider hardware ?
I wonder if an upsampling/downsampling container vst is possible. Where you would load all the vst's into a container and let the container do the upsampling.
Reaper has this feature built in.
Love the Randall Munroe cartoon!
Interesting ideas, but I’m sure there’s some real, actual problems with implementing them, otherwise we would have them already.
For one, the reason why plugins need to analyse in real-time, and can’t do it offline, is because unless they’re fist-in-chain they don’t scan the original audio file, they scan whatever comes out of the plugins that came before. If you wanted this process to go on automatically in the background, you’d need to run signal through all those plugins, and this would need to be done again every time you tweak any of those plugins. Same goes for the LUFS measurements. All of this would be eating up a good chunk of your processing power invisibly, under the hood.
You’d need quite the clever programmer to make all those processes automatically pause the moment you press play, just so you’d have all the processing available when it’s actually needed to play the session. You could say that processors have become so fast these days that you could easily spare some amount of power, but that would depend completely on what computer and what type of project we’re talking about. Sure, the guy in the sweet spot with a monster machine, and sessions that are not completely insane, might have processing to spare, but what about the people running mammoth sessions, or the people on a relatively budget machine. The DAWs and plugin-manufacturers want to serve them all well, without having to make multiple versions of their software.
So, I agree to an extent that we’re overdue a new standard, and that it would be very cool if it was more universal instead of multiple proprietary ones, but I think that on many aspects of this you’ll be running into good reasons for ‘why’ these things don’t exist yet.
That said, I encourage you to talk to plugin developers and to try to get this ball rolling. If no one ever dreams outside the box, nothing ever happens. Good luck! ;)
@@chokocat9064 You’re not really disagreeing with what I said. The things I discussed are indeed DAW level, and I’m not saying it can’t be done. I’m saying it comes at a pretty high compute cost to do all this extra constant rendering. And most DAW developers choose to have their DAW run smoother rather than having more background rendering. I’m pretty sure DP doesn’t render ‘everything’ constantly, and restarts every time you make ‘any’ adjustment, just to be able to give you a constant accurate LUFS value. It does bits where it can, when there’s unused compute, to speed up processes, not at the expense of those processes.
Also, just having a new plugin standard would require implementation in each DAW that wanted to be compatible. Having DAWs with these options available to plugins is the topic of the video.
@@chokocat9064I have an Apple Silicon Mac. I know they are powerful. You are not really talking about the same thing though. I’m not talking about just ‘any’ background task. I’m talking about tasks that would be invalidated the moment you touch the session. You can’t put them on hold while you’re doing something else, the moment you do something else, they have to recalculate.
Answer me this question:
Does DP give you a constant, accurate, LUFS reading?
@@chokocat9064 No, you did not address it, and this ‘is’ the actual type of thing the video was about. You know, the thing you said DP did already.
One last time: we’re not talking about just any background rendering. We’re talking specifically about things like constant LUFS readings. You know, the topic.
I ‘only’ mentioned background processes, in this context, because it would be the only way to do a constant LUFS reading. Same goes for a lot of the other things discusses in the video.
You’re the one claiming DP does these things already. And this is simply not the case.
Really, this discussion reminds me a lot of the very first time someone told me about DP, about 18 years ago. They were telling me about all the ways DP could mimic every other DAW, and that it was just better than all of them. Then when I tried it, it could ‘look’ ‘vaguely’ like other DAWs, but it worked like DP, and only like DP.
Look, I get it, you like Digital Performer. That’s fine. If it works for you, that’s great. But stop acting like it has fixed all the things Witse is talking about kn the video, simply because it does a bit of background rendering.
It does not do the things this video is talking about. No matter how much you try to deflect the point away from this.
@@chokocat9064 No, you did not address it, and this ‘is’ the actual type of thing the video was about. You know, the thing you said DP did already.
One last time: we’re not talking about just any background rendering. We’re talking specifically about things like constant LUFS readings. You know, the topic.
I ‘only’ mentioned background processes, in this context, because it would be the only way to do a constant LUFS reading. Same goes for a lot of the other things discusses in the video.
You’re the one claiming DP does these things already. And this is simply not the case.
Really, this discussion reminds me a lot of the very first time someone told me about DP, about 18 years ago. They were telling me about all the ways DP could mimic every other DAW, and that it was just better than all of them. Then when I tried it, it could ‘look’ ‘vaguely’ like other DAWs, but it worked like DP, and only like DP.
Look, I get it, you like Digital Performer. That’s fine. If it works for you, that’s great. But stop acting like it has fixed all the things Witse is talking about in the video, simply because it does a bit of background rendering.
It does not do the things this video is talking about. No matter how much you try to deflect the point away from this.
Unless DP is sharing the functionality you’re talking about with plugins, you’re not talking about the same thing Witse and I are talking about. You just read ‘background processing’ and jumped on that.
And even ‘if’ it did do all of that, which it doesn’t, it would still not be what the topic is about. Which is, a new standard for plugins, meaning that it should be universal, or at least compatible with more than one DAW.
Yes, DP does some background rendering where it can, to lighten the load on the CPU. It’s a sort of auto freeze and de-freeze, running in the background.
That’s not what we’re talking about here.
@@chokocat9064 You keep completely missing every point.
No one is saying these processes should be implemented at the plugin level. Witse was asking for a new standard, so that every DAW would give plugins access to these processes so they could implement certain features. Did you even watch the video?
Nowhere did I claim that DP didn’t do pre-lookup, nowhere am I saying it doesn’t do background pre-rendering, nowhere am I disputing that it can do ARA, or that things like ARA shouldn’t be done at the DAW level.
And no, the features that Witse requests in the video are ‘not’ implemented anywhere, not even in DP. If you read my very first comment here correctly, you’d see that I actually agree that a lot of his requests should really be implemented at the DAW level, ‘and then offered to the plugins when they ask for some of those features’. See the difference?
Also, no one is claiming DP is not the oldest, that wasn’t the point at all. Again, you’re defending against things I didn’t say. The point of my telling you about the first time I heard about DP was not to say that DP was ‘made to copy other DAWs’, of course it wasn’t. The point was that even back then people were telling me things they thought I wanted were already implemented in DP, when in fact they weren’t.
One last time: yes, DP has background processing, and a lot more, I never said it didn’t. But it does ‘not’ have the features Witse was asking for, which is the point of this whole discussion. You can’t keep saying that it does these other, related things, and then when you come to the point say: well, that’s stupid and should be done at mastering. Yeah, I might even agree, but ‘that’s what Witse was asking for’.
Just because I proposed that pre-rendering and some form of lookahead ‘could potentially’ be used to implement ‘some’ of the features Witse asked for, does ‘not’ mean that pre-rendering and lookahead ‘alone’ ‘are’ the actual thing Witse asked for. And more than that, I acknowledged, right from the start, that this is not really in the domain of plugins, and should be DAW-level implementations, that ‘then’ could possibly be made accessible to plugins, on the condition that each DAW implemented them in a compatible way.
Please, read this as I wrote it, and stop imagining what I must have meant. This is getting silly. You’re fighting windmills.
What about Reaper's integrated oversampling functionalities? No communication between plugins, but we can set manually chain oversampling if I remember correctly.
He mentions Reaper at 9:11
@@charlesrocksYea, but I am not talking about hosting CLAP.
The oversampling problem Reaper solved long time ago.
Final Cut Pro already does automatic rendering whenever you stop manipulating stuff for a second. I can imagine a DAW making « freezing » tracks more automated. However, I think it would struggle with sidechaining tracks with each other.
yeah, if plugins to talk to each other i feel like it would be really good especially for atmos mixing
What about when analogue computing that is affordable and efficient becomes a thing? Surely plug-ins will improve then.
Creating a new standard will just just be that, another standard that developers will need to write to in addition to the existing standards. VST2.4 is still widely used and it is 30 years old now. Currently the cost of development is so high that this doesn't make economic sense to try and create another new, competing standard. It is simply money. Something as big as a new effects SDK requires a lot of money and time not only in creating the standard, but in getting companies to support that standard.
Interesting video. Thanks Witse.
....CLAP?
The "universal upsampling communication" thing would be a pretty cool feature to just have automatically happen in the background, but I think getting it to work reliably would be a nightmare and a constant struggle, since it would depend on all the plugin devs implementing it correctly. That would mean more testing and dev time, and then having to continually support the feature when new plugins from other companies come out and one misbehaving plugin will ruin everything... yeah the more I think about it the more I realize it's probably for the best that plugins don't talk to each other too much, since it creates that many more points of failure. 🤣
-
A simpler way to do this would be to just have the track itself be able to do the upsampling, and maybe even have containers of upsampled plugins. You can already do this with Reaper, or plugin loaders like DDMF Metaplugin, albeit in a more clunky (and sometimes buggy) manner.
The only thing what I wanna see in the future before I die is Blender 3D level of Open Source DAW while also using CLAP with it, it doesn't have to be perfect since not everyone will be please on every features of it but at least it can do what most big boys DAW can do (and it doesnt need to be as complicated a reaper lol)
Ardour is getting very good lately, but I'm not sure they support CLAP. They do support and open source plugin model, though
Thank you for not using clickbait titles and sharing priceless knowledge instead.
Unfortunately, it doesn't always work ☹️
Imagine turning one knob of a plugin and see the whole waveform being rendered in real time 😋
This
The new plugin format they are developing right now is called CLAP
These kind of "productivity plugins" are less of a niche market than we imagine, IMHO - the ideas you are talking about (ex: a look-ahead approach to a series of plugins) are excellent! Discord channel to brainstorm? :)
when you move into live sound some close systems are already there, like soundvision.
you should get a programmer ally and start making a daw from scratch the way it should be with proper features as stock 😁
Amazing content again. I'm not wiser now but I'm way more informed. This is important!
I don't understand the argument. A new, open standard would not guarantee that it supports all the nice features you're asking for. Portability of source code is essentially already there for quite some time through cross-platform frameworks such as JUCE. It's not optimal, but apparently a working solution.
what needs to stop is the "dropping a plugin" and "taking money" without servicing and upgrading it...it's like a hit and run strategy. PIs are software - and developers typically keep upgrading and updating their softwares, making it better...Looking at PA, tehy have plugins that have not changed in 5 or 10 years , and that just needs to stop. Apple, however, services products for years and years...Even very old iPhones still work. Oh and most of tehir software upgrades are free, free, free and always free. Logic X has been getting new plugins, features etc for 10 years without a dollar! Get your act together Universal Audio, Plugin Alliance etc...
I know that CLAP brings polyphonic modulations and things like that but I’m not sure it brings any improvements regarding how audio streams are processed.
Im not a programmer nor big head. But I think CLAP does change the way plugin use cpu resources and allow bi directional communication with host/plugin. So it well may be possible. But hosts will need to adapt too. I believe it’s a long time goal of bitwig because it’s just fit their ecosystem as in bitwig plugin or chains of plugins can be seen as one process.
Bitwgi and U-he are the founders of clap, try it out with openstagecontrol, just leave the old reaper cubase logic midi ancient stuff behind and stop complaining about problems that aren't there
@@JohnSmith-pn2vl did you just call reaper ancient stuff? I use bitwig but reaper is anything but ancient. Also, leaving midi behind isnt really possible currently. Although they are finally developing midi 2.
Plugins Are Great, And it’s More about learning when and When not to use them once you actually Learn How they Work and Not To Buy Duplicates which Just have A Different U i.
Great insight! Thx!
once computer speed and space increase maybe plugins can be packed with more algorithms to further sound like hardware. ?
Maybe this is a bit off topic, but I'd really like to be able to use Ableton Max plugins in LPX pro. Guess it's impossible to create a Max host for other non-Ableton DAWs so their users can avail themselves of those devices without having to buy and learn an entire new program. Best we can do in theory is to connect Ableton to our DAW via Loopback .. and God knows how well that would work.
Yes. I have been thinking about this. There could be a more integrated approach. Maybe DAWs could be split up into 2 areas. 1. GUI and 2. processing. For example, I like using Reaper because of the UI. But, what if a company like SSL could build the back end processing for Reaper? So that you could have the customizable workflow UI and the signal processing of an SSL console. So DAW manufacturers could sell a version of their DAW that is just the GUI. So that software processing manufacturers could sell the back end processor. Maybe companies like SSL, API, NEVE, etc.
I like the CLA mixhub. However, It doesn't have sends in the buckets. I understand why. But it is clunky. Or, I like the way Mixbus 32c has all of the EQ, Dynamics, Bussing built in. Or Studio One has “Mix FX.” If reaper had that feature I would probably use that. I find that just a touch of the crosstalk and drive does some really cool things. I like how it deals with things on a lower level - like crosstalk.
I don’t know how this could be accomplished. But, I do know that the mixing in the box experience could be much better than it is.
IMO, the plugins themselves should not be doing upsampling. Upsampling should be global. If upsampling is enabled, all plugins are given upsampled audio by the DAW, and when all plugins are finished, the DAW downsamples it.