CLAP 1.0 betas for ACE, Diva, Hive, MFM 2.5

[Funkybot's Evil Twin]

Question on the betas/preview build while I'm at work: are there updates to the VST/VST3/AU builds included in this thread with fixes for us? Basically: should non-CLAP users treat this as a new public beta or should we wait this one out? I'm assuming the stricter error reporting would only exist on the CLAP format, but if it's going to impact VST/VST3/AU, I'd rather wait this out.

[cb8rwh]

When comparing VST2 and CLAP, VST2 is quite a bit better with either Multicore activated or deactivated.

Have you tried how many VST2 instances you can play with activated multicore vs how many instances of CLAP you can play at the same time with activated multicore feature?

I tried 10 instances of each and VST2 was still better CPU-wise. I will go further!

[EvilDragon]

Every time I launch Reaper for the first time each day, it has to scan each file in the BlueCat resource folders in my VST Plugins folders. Takes a few seconds, but enough to be annoying. I reported it and asked they used shared resources in ProgramData or Documents, but the response was that users would want the flexibility of having different skins for each plugin type [or something like that - I'm going off memory]. Which sounded crazy to me at the time! And Acustica is just gonna Acustica. User experience just doesn't seem like a priority for them IMO.

OK so actually I have a solution for you. Use symlinks. Move out all that "crap" to whatever other place you want on your hard drive(s), then in place of that create a symlink from the current location of "crap" to where you moved it out.

Reaper skips symlinks when scanning for plugins. You should get much faster scans after this!

[cb8rwh]

Went to 20 and the gap is definitely closing. Seems that CLAP is less spiky as well at that number of instances.

Thanks for the info

[gnu23]

Huge mistake forcing an arbitrary install location.

Your preference is not everyone's preference. If you ask our support team for instance, they'll tell you how much less work they have since we made our installers more restrictive. So for computer savvy people such as yourself it surely isn't a great deal to move a dll from one place to another once or twice a year?

First, congratulations on CLAP.

Second, I am going to respectfully disagree - forcing an arbitrary install location is a problem.

(Speaking Windows now): That location is a usually C-drive, and in modern installers, there's usually a Registry entry involved as well. Also, in newer PCs C-drive is often a 1 TB SSD. That 1TB SSD can fill pretty quickly.

For those reasons alone, the end-user should be offered the opportunity to select their own installation location. I would also suggest also that the installer should extend to offer the option to move everything and auto-update the Registry (when Registry keys are used) should the user need to move everything again (or any time they choose).

Finally, I would suggest not making the assumption the user is "computer savvy". Users span the spectrum from novice to pro. Software vendors should take that into account and make things as easy for the user range as possible.

I'll finish with a generalization or two. No doubt U-he makes great plugins. There's a ton of solid code in every one of them. So it should be relatively easy to extend that coding skill all the way to the installer to make ease of use seamless - from install to use to move to uninstall.

Thanks for reading.

[tasmaniandevil]

I tried 10 instances of each and VST2 was still better CPU-wise. I will go further!

Which operating system are you using, which CPU?
How many voices are you playing with each instance?
Which sample rate and buffer size did you set?
How are you measuring the CPU?
If you are on Mac, and have set Bitwig's sandbox to "per plugin", you can use Activity Monitor to check the plugin host process, which shows only the power the plugin consumes.

[tasmaniandevil]

Question on the betas/preview build while I'm at work: are there updates to the VST/VST3/AU builds included in this thread with fixes for us? Basically: should non-CLAP users treat this as a new public beta or should we wait this one out? I'm assuming the stricter error reporting would only exist on the CLAP format, but if it's going to impact VST/VST3/AU, I'd rather wait this out.

Yes, the stricter error handling only applies to CLAP.
But we always incorporate small improvements and bug fixes that apply to all plugin formats and platforms.
And in case of MFM2, I've added a small changelog with the most important changes since the last beta to the MFM2.5 beta thread.

[cb8rwh]

Sorry yeah I didn't exactly provide much info.

I am on Win 10. Ryzen 5950
6 voices for both (Preset BS Beauty Pad - Great accuracy)
Sample rate 44.1, buffer 512 samples

[tasmaniandevil]

Sorry yeah I didn't exactly provide much info.

Thank you for the additional details, much appreciated.
We actually haven't tested with AMD processors yet, only with Intel and M1.

[Funkybot's Evil Twin]

Reaper skips symlinks when scanning for plugins. You should get much faster scans after this!

Ah...that's something I didn't know. I always thought the whole idea with symlinks was that applications didn't "know" they existed and were "tricked" into thinking the folder was actually there. If Reaper skips them, that would indeed work. Thanks!

[cb8rwh]

Sorry yeah I didn't exactly provide much info.

Thank you for the additional details, much appreciated.
We actually haven't tested with AMD processors yet, only with Intel and M1.

Ah ok, that's fair enough.

So with 16 of those instances on divine accuracy, holding down 5 notes, I think CLAP performs at least as well as VST2, if not slightly better. Definitely a lot less CPU spikes.

[EvilDragon]

Reaper skips symlinks when scanning for plugins. You should get much faster scans after this!

Ah...that's something I didn't know. I always thought the whole idea with symlinks was that applications didn't "know" they existed and were "tricked" into thinking the folder was actually there. If Reaper skips them, that would indeed work. Thanks!

Yeah symlinks sure behave like that, but there are I/O APIs on every OS that enable the program to know if something is a symlink or not, etc.

[Funkybot's Evil Twin]

Finally, I would suggest not making the assumption the user is "computer savvy". Users span the spectrum from novice to pro. Software vendors should take that into account and make things as easy for the user range as possible.

I'd respectfully argue back that is exactly what they're doing: they're making things as easy as possible for all users in that novice to expert range. What that means is having to build for the novice and prevent changes to protect them from themselves. If more "Pro" users want to try their luck with Symlinks or manually moving files anyway, they can try that and hope for the best. But you have to prevent novices from making a mess of things, which means tighter controls.

I understand your points overall. Smaller SSD's as system drives can definitely fill up more quickly. But I think in the grand scheme of things, that's just going to have to be something users need to keep in mind and enforcing the path will do more good than harm.

[EvilDragon]

Exactly.

[Double Tap]

As long as the only thing people complain about are our installers, I think we did something right with the concept of this standard for plug-ins and host. I guess that's why such an amazing number of industry players agree with us, even though we haven't even really started until today.

When I heard you were doing this, I didn't think it was particularly important for users, but the video showing the different options for modulation etc completely changed my view. This looks like it will make a real difference improvement to workflows.