v6.65+dev0812 - August 12 2022

[schwa]

"Group 1" is the name of a folder track in your project, not the name of a group, right?

[Klangfarben]

Originally Posted by schwa

"Group 1" is the name of a folder track in your project, not the name of a group, right?

I have now Inception-ed myself and will casually walk away in shame...

[sockmonkey72]

Originally Posted by schwa

That behavior (which is optional and enabled by default) should be overridden when "automatically group selected tracks" is enabled, fwiw.

A niggle: the wording of this preference is such that I had no idea what it is for. Maybe something like "Clicks in the arrange view select track" or something like that. "Track view" does appear in the manual, but appears to be an older way of describing the arrange view, and is now used preferentially to distinguish screen set types. In the actions list, it only appears in association with screen sets.

[PitchSlap]

I didn't have much excitement for CLAP until the developer from GPU Audio said they expect CLAP to be 20-40x faster than VST3 due to limitations with the spec (~150 reverb instances in VST3 wrapper vs. over 2000 without the wrapper.)
('.')

[mschnell]

Originally Posted by PitchSlap

I didn't have much excitement for CLAP until the developer from GPU Audio said they expect CLAP to be 20-40x faster than VST3 due to limitations with the spec (~150 reverb instances in VST3 wrapper vs. over 2000 without the wrapper.)
('.')

Exactly what limitations ?

-Michael

[sockmonkey72]

Originally Posted by PitchSlap

I didn't have much excitement for CLAP until the developer from GPU Audio said they expect CLAP to be 20-40x faster than VST3 due to limitations with the spec (~150 reverb instances in VST3 wrapper vs. over 2000 without the wrapper.)
('.')

Without seeing the specifics of this claim, it's difficult to say for sure, but this sounds, on the face of it, like utter bullshit. The existing plugin APIs don't add overhead on this order of magnitude.

If they are getting 20-40x improved performance, it's because they are doing the DSP more efficiently, which has nothing to do with the handful of API functions used for passing parameters and samples between the host and the plugin.

It's possible that their plugin(s) benefit wildly from the CLAP thread pool (limiting the number of threads being used and competing for system resources), in which case they could also just implement a plugin-global thread pool to get similar speedups without CLAP.

Always happy to be proved wrong, but this just doesn't pass the smell test.

[mike@overtonedsp]

I didn't have much excitement for CLAP until the developer from GPU Audio said they expect CLAP to be 20-40x faster than VST3 due to limitations with the spec (~150 reverb instances in VST3 wrapper vs. over 2000 without the wrapper.)

If they are getting 20-40x improved performance, it's because they are doing the DSP more efficiently, which has nothing to do with the handful of API functions used for passing parameters and samples between the host and the plugin.

My understanding is that the speed increase in this case (compared to say a conventional CLAP / VST / VST3 plug-in) is because they are using the graphics card to process the audio. So this does not mean 'any CLAP plugin is 40% faster than e.g. a VST' because CLAP. It isn't. The REAPER devs would be better able to say if CLAP enables them to do anything more efficiently on REAPER's side, but from a plug-in developer perspective I can tell you that there is no automatic performance boost with CLAP.
You get given a buffer of samples, you do some maths on them and you hand them back. Just like VST. You can do that as efficiently or inefficiently as you want (you might use the GPU, CPU, or you could even print them out and have someone calculate them manually and type them back in though I wouldn't recommend this, as the latency would be quite bad... ). As I understand it GPU Audio are leveraging the GPU to offload some of the processing from the CPU (and that's not a specific architectural feature of CLAP). I would imagine there are cases where that works / scales very efficiently, and others perhaps less so, and maybe there are aspects of the CLAP API which better suit their specific use case.

[mschnell]

Originally Posted by mike@overtonedsp

because they are using the graphics card to process the audio.

This supposedly is completely independent of the CLAP issue, as "CLAP" or "VST3" is just an interface description (between DAW and plugin).
Theoretically, any plugin can be designed to use the GPU for processing. (Right now as a normal product, nobody does this because you don't know which Graphics card the target machine will feature.

The only efficiency improvement feature CLAP seems to offer over VST3 is the ability to allow the DAW to provide a common thread pool, for all (CLAP) plugins. which might be slightly advantageous over each plugin providing a separate thread pool. But in fact plugins can provide a thread pool common for all instances, avoiding the difference in most cases. AFAIU, Kontakt (VST2 and VST3) does this.

-Michael

[PitchSlap]

Originally Posted by sockmonkey72

Without seeing the specifics of this claim, it's difficult to say for sure, but this sounds, on the face of it, like utter bullshit. The existing plugin APIs don't add overhead on this order of magnitude.

If they are getting 20-40x improved performance, it's because they are doing the DSP more efficiently, which has nothing to do with the handful of API functions used for passing parameters and samples between the host and the plugin.

It's possible that their plugin(s) benefit wildly from the CLAP thread pool (limiting the number of threads being used and competing for system resources), in which case they could also just implement a plugin-global thread pool to get similar speedups without CLAP.

Always happy to be proved wrong, but this just doesn't pass the smell test.

Well if someone said 2 years ago they could run hundreds or thousands of instances of a convolution reverb on your GPU with essentially no latency it wouldn't pass the smell test either.

From what I understand VST3 is creating a bottleneck and Steinberg hasn't been responding to their emails on the ways to address it. Meanwhile AMD which is vastly larger than Yamaha/Steinberg was more than willing to work directly with them to add support so it's not unreasonable to assume the tech is solid, but VST3 could use some improvement if the performance is far below AU/CLAP.
https://youtu.be/P3dpp7UuBg0?t=445

[bFooz]

Originally Posted by schwa

Text is aligned left (the track manager "group" column is incorrect and should be aligned left), numbers are aligned right, and symbols (dots, single-character indicators like "M" for mute, etc) are centered.

The numbers of the FX collumns are centered.
The color is left aligned.
[+] is left aligned. If I didn't know, I would thought we add something here, or when [-] we remove the track. And there is no other indication except that small same-color +/- that we have a folder collapsed there.

Trying to use the track manager now when trying these things, there are some obvious usability problems. E.g. some columns react to only a single click, some only to a double-click and some to both. And some to none, e.g. Freeze and Lanes. I honestly don't know what Lanes should do and how to enable it.

Or e.g. a doubleclick on the Offset column opens another window with still more parameters AND the highlighed textfield is not the one I need. (I need Offset but highlighted is Volume)

And the track manager can get really wide with such a great number of columns. When trying to activate a far-right column of a particular track, having the trackname as a far-left column, it is impossible to aim for that one track wihout e.g. hover highlight.

[Justin]

Originally Posted by bFooz

One case of disappearing text I found is solved but this one remains.

https://drive.google.com/file/d/1wC4...ew?usp=sharing

thanks, fixing (but for post-6.66)