Microsoft Windows 10 Update Will Let You Use More Virtual Instruments & Effects In Your DAW

[Psychlist1972]

Cheers. What about bridging between a 64bit host and 32bit VSTs? Presumably the 64bit bridge VST itself would only use one set of resources. But in this case, each bridged 32bit VST would be in a separate memory space, right, and not shared? Would each 32bit VST then use its own slots?

Depends on how it's implemented.

If they do the bridging through a separate process (the most likely solution) and they load all 32 bit plugins in that process, then you get another 128 slots. If they host *each* 32 bit plugin in a separate process, then you get 128 slots for each plugin.

Some DAWs let you host even 64 bit plugins in separate processes.

Now, there's memory and processor overhead to an additional process, and also additional latency with inter-process communication. But seems to work for many people.

But really, as a musician, you shouldn't have to micro-manage your plugins. We think you just want to be able to make music, and not worry about OS implementation details. Hence the >4000 limit upgrade.

Pete

[zvenx]

More and more people wrote, there are no real benefits from this extension, because no one have so large/complex projects, which will hit the old value of 128. So where exactly is the great improvement for 99% of all DAW users?

People who do a lot in the box run up against this all the time. Forums are full of people lamenting the limit of 128. Why? Load up something like the Arturia Analog lab, which uses 45 slots, or any of the processing plugins like the iZotope stuff.

This is especially true for composers and others who want to duplicate tracks and try different plugins to see which ones work better for the sound they're trying to get.

This problem was only getting worse as DAW computers got more powerful.

So it may not benefit you personally, or maybe it will in the future and you won't realize it, because you're able to just happily continue working on your project.

Pete

Thank you for this response Pete...kvr sometimes really has me scratching my head.
rsp

[t3toooo]

Thanks a lot Pete.Honestly, I never expected anything like this to happen.

[zvenx]

Thanks a lot Pete.I honestly never expected anything like this to happen.

Neither me.
Much much appreciated.
rsp

[metamorphosis]

Unique plugin DLLs, not plugin instances.

50 instances of the same plugin will not use any more FLS slots unless the plugin code allocates them on purpose. So 50 instances of a plugin that uses 1 FLS slot, will continue to use only 1 FLS slot.

But 50 *different* plugins, each using 1 FLS slot, will use 50 FLS slots, even if each one is used on many tracks.

Hope that makes more sense.

Pete

Good point, yes I missed that, Thanks-

[4damind]

So this update goes into the Visual C++ runtime library and needs a recompilation of plugins using a statically linked runtime library?

[stash98]

More and more people wrote, there are no real benefits from this extension, because no one have so large/complex projects, which will hit the old value of 128. So where exactly is the great improvement for 99% of all DAW users?

People who do a lot in the box run up against this all the time. Forums are full of people lamenting the limit of 128. Why? Load up something like the Arturia Analog lab, which uses 45 slots, or any of the processing plugins like the iZotope stuff.

This is especially true for composers and others who want to duplicate tracks and try different plugins to see which ones work better for the sound they're trying to get.

This problem was only getting worse as DAW computers got more powerful.

So it may not benefit you personally, or maybe it will in the future and you won't realize it, because you're able to just happily continue working on your project.

Pete

A litt off topic, but when it comes to music and system resources - Do you think it will be possible to get Windows to send a jitter free MIDI clock out to hardware from a DAW, or is too complex due to 3rd part software..etc?

[Psychlist1972]

A litt off topic, but when it comes to music and system resources - Do you think it will be possible to get Windows to send a jitter free MIDI clock out to hardware from a DAW, or is too complex due to 3rd part software..etc?

MIDI speed and jitter are close to my heart.

I have on my backlog here to do some jitter testing comparison between the old Win32 MIDI API and our current Windows 10 / WinRT MIDI API (the one that also supports BLE MIDI, and may eventually support new MIDI standards). I always thought the jitter was in the driver, which they both share, but one of the devs told me this week that it's likely in a different part. I need to test to confirm.

If the current API has better jitter characteristics, I think it will help me get companies to adopt it. Right now, Cakewalk and ROLI / JUCE are the only big names that support the current API.

Pete

[Psychlist1972]

So this update goes into the Visual C++ runtime library and needs a recompilation of plugins using a statically linked runtime library?

No. The update is in the Windows 10 Kernel and does not require any recompilation of anything other than the Windows Kernel (which we have done <g>).

If I could get plugin authors to recompile all their plugins, I'd ask them to dynamically link the runtime at the same time. Better for memory, better for servicing, and better for dealing with FLS slots. Unfortunately, it would make their installers more complex.

Pete

[4damind]

So this update goes into the Visual C++ runtime library and needs a recompilation of plugins using a statically linked runtime library?

No. The update is in the Windows 10 Kernel and does not require any recompilation of anything other than the Windows Kernel (which we have done <g>).

If I could get plugin authors to recompile all their plugins, I'd ask them to dynamically link the runtime at the same time. Better for memory, better for servicing, and better for dealing with FLS slots. Unfortunately, it would make their installers more complex.

Pete

Great!
Pete, is there also something planned in the audio department for the future? Maybe to allow smaller latency without interruption from the OS or that other devices can't delay/block the quick handling of audio buffers?

[Psychlist1972]

So this update goes into the Visual C++ runtime library and needs a recompilation of plugins using a statically linked runtime library?

No. The update is in the Windows 10 Kernel and does not require any recompilation of anything other than the Windows Kernel (which we have done <g>).

If I could get plugin authors to recompile all their plugins, I'd ask them to dynamically link the runtime at the same time. Better for memory, better for servicing, and better for dealing with FLS slots. Unfortunately, it would make their installers more complex.

Pete

Great!
Pete, is there also something planned in the audio department for the future? Maybe to allow smaller latency without interruption from the OS or that other devices can't delay/block the quick handling of audio buffers?

Nothing to disclose at this time.

We can't do anything to ASIO, as it is not our standard. It's also about as low-level as you can get -- an API right to the hardware (which is also why it doesn't do aggregation, except for ASIO4ALL).

In general, we have guidance on how long you can tie up parts of the kernel, DPCs, etc. but those are more tuned to overall performance, not specifically for audio. Some drivers and hardware do better than others for sure. The custom DAW PC builders tend to know which combinations work best, have most predictable performance, lowest DPC wait time, etc.

Pete

[bill45]

Have they addressed the 9 midi driver limit

[Psychlist1972]

Have they addressed the 9 midi driver limit

I've never tried to have 9 different MIDI *drivers* going, as I use our class driver for almost everything. But here's from my own PC a week or three back:

https://twitter.com/Pete_Brown/status/1 ... 7032419328

Pete

[stash98]

A litt off topic, but when it comes to music and system resources - Do you think it will be possible to get Windows to send a jitter free MIDI clock out to hardware from a DAW, or is too complex due to 3rd part software..etc?

MIDI speed and jitter are close to my heart.

I have on my backlog here to do some jitter testing comparison between the old Win32 MIDI API and our current Windows 10 / WinRT MIDI API (the one that also supports BLE MIDI, and may eventually support new MIDI standards). I always thought the jitter was in the driver, which they both share, but one of the devs told me this week that it's likely in a different part. I need to test to confirm.

If the current API has better jitter characteristics, I think it will help me get companies to adopt it. Right now, Cakewalk and ROLI / JUCE are the only big names that support the current API.

Pete

That’s great to hear. Music Hardware and software integration will be in a much better place sooner than later I think!

[ThatsMeAgain]

More and more people wrote, there are no real benefits from this extension, because no one have so large/complex projects, which will hit the old value of 128. So where exactly is the great improvement for 99% of all DAW users?

People who do a lot in the box run up against this all the time. Forums are full of people lamenting the limit of 128. Why? Load up something like the Arturia Analog lab, which uses 45 slots, or any of the processing plugins like the iZotope stuff.

This is especially true for composers and others who want to duplicate tracks and try different plugins to see which ones work better for the sound they're trying to get.

This problem was only getting worse as DAW computers got more powerful.

So it may not benefit you personally, or maybe it will in the future and you won't realize it, because you're able to just happily continue working on your project.

Pete

Thanks for the reply. Yes I'm not a tech savvy about this stuff and I never heard before. So I wonder about this strange limitation of loading VSTs. I'm not sure if I have a project with more than 100 different plugins (certainly not). The AnalogLab is a good example and Arturia wrote also some sentence about this value and why. But good to know, that we now can do a little more. My limits are the RealTime Audio from software synths which consume a lot of the CPU power but nothing from the GPU.

VST2GPU bridge would fabulous!