v6.64+dev0802 - August 2 2022

[sockmonkey72]

v6.64+dev0802 - August 2 2022

• * Includes feature branch: CLAP plugin support
• * Includes feature branch: track media/razor edit grouping
• * Includes feature branch: pan law/function improvements
• * Includes feature branch: improve experimental silent-track CPU reduction option to include FX tail length
• * Includes feature branch: media item fixed lanes
• * Includes feature branch: internal pin management overhaul for future extension
• + CLAP: support plugins that output MIDI
• # CLAP: add preferences menu option to re-scan all CLAP plugins
• # CLAP: fix resizing on plug-in resize notification
• # CLAP: fully deinitialize plugin factory on unload
• # CLAP: scan plug-ins in .clap subdirectories on platforms other than macOS
• # CLAP: support CLAP plugins in FX folders and recent FX list
• # CLAP: support CLAP plugins in project bay

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[Funkybot]

Right-click in the FX Browser then "Scan for new plugins" does not locate newly installed CLAP plugins. One needs to go to Preferences and do a rescan from there if you want to find CLAP plugins without restarting Reaper.

[RobU]

Now properly scanned and working perfectly, thanks!

[TAL-DAC.clap]
_=005A8B3A188ED801005A8B3A188ED801
ch.toguaudioline.taldac=0|TAL DAC plugin (TAL-Togu Audio Line)
[TAL-Drum.clap]
_=009DEE38A48FD801009DEE38A48FD801
ch.toguaudioline.taldrum=1|TAL-Drum (TAL-Togu Audio Line)

[deeb]

CLAP CLAP for CLAP. Thank you

[baconpaul]

Just for completeness, indeed the CLAP midi out tests work now. Thanks!

[hans]

Regarding track media/razor edit grouping:

Moving item contents and right edge, ripple edit later items.

Shouldn't the right edge of the follower tracks follow the edge of the lead?

[AZpercussion]

Originally Posted by hans

Moving item contents and right edge, ripple edit later items.

Shouldn't the right edge of the follower tracks follow the edge of the lead?

Yeah, I think it should.

[Gass n Klang]

Thank you for the great great great media/razor edit group feature. It was SO MUCH needed!!! It's a pleasure to work with and I'll instantly remove all item grouping shortcuts as soon as it gets released. In most cases it behaves like expected.
But I wouldn't expect all items to be trimmed when doing something like this:

[schwa]

Originally Posted by Gass n Klang

But I wouldn't expect all items to be trimmed when doing something like this:

If the items are all selected, and the mouse modifier is "move edge (relative edge edit)", then all the edges will move. If the items are grouped but not selected, or if the mouse modifier is "move edge", only edges that line up will move.

[Gass n Klang]

Originally Posted by schwa

If the items are all selected, and the mouse modifier is "move edge (relative edge edit)", then all the edges will move. If the items are grouped but not selected, or if the mouse modifier is "move edge", only edges that line up will move.

ah got it, thanks! It's pretty nice, the item on track 1 is trimmed as soon as it lines up. But I think it could be really cool, if it was resetted to its previous length as soon as the trim exceeds the boundaries of the smaller item. at the moment there is a tiny little item remaining which isn't useful for anything:



alternativly the small item could be deleted, but I think this can easily be done by splitting and deleting the bigger items. so resetting would be fine I think.

[Ozman]

Either deleted or reversed.

[mike@overtonedsp]

Doing some testing with CLAP support (Linux). I noticed when I adjust a CLAP parameter value in Reaper's UI, in some cases its not possible to adjust to the full max and min values. In fact what appears to happen is that when a slider hits the 'end stop' no call is made to get the last human readable value - so you only get a display of the value before the max or min, even though the plug-in has been sent the correct value.

To break this down more, it seems that on moving a control, Reaper sends the param change event to the plug-in, then immediately asks the plug-in for the parameter value, asks the plug-in to translate this value to a human readable form, and displays it. Problem is that the parameter change event won't be seen by the plug-in until the next 'process' call. So what Reaper is actually getting back is the 'old' value from the plug-in and not the new one.

It could be something about my plug-in implementation, but the CLAP SDK appears to mandate that (understandably) parameter change events should only be dequeued in the process call. Any other dev's have some insight (is there something in the CLAP parameter API I'm not aware of? Does it even matter? (since the plug-in works perfectly using its own GUI) Is it a Reaper bug? (Perhaps Reaper - or hosts generally? - should just echo the adjusted param value to their own GUI locally, only using the plug-in's value_to_text call to get the human readable translation (assuming that's not already being done). That at least appears to fit better with the CLAP SDK design - as far as I can tell)

EDIT: This also appears to affect other plug-ins. For example adjusting the VMod1 parameters in Uhe's 'Diva' using the Reaper UI allows me to go from -93.20 to 99.40 instead of the expected -100 to +100 achievable using the Plug-in UI

[Denys]

Hello, the default path for CLAP doesn't seem to work on my system (W11 21H2, system language set to French Canadian). It is shown all caps, with %\, as the LV2 path on the following screenshot:




After setting it manually, the only CLAP plugin I have (Fog Convolver 2) seems to be recognized, but the loading fails.

[lalelu]

Originally Posted by mike@overtonedsp

Doing some testing with CLAP support (Linux). I noticed when I adjust a CLAP parameter value in Reaper's UI, in some cases its not possible to adjust to the full max and min values.

<snip>

Is it a Reaper bug? (Perhaps Reaper - or hosts generally? - should just echo the adjusted param value to their own GUI locally, only using the plug-in's value_to_text call to get the human readable translation (assuming that's not already being done).

I noticed the same with my own and also other plug-ins:

https://forum.cockos.com/showpost.ph...5&postcount=12

I agree with your conclusion regarding reponsibility of the host. Looks like Bitwig is doing it right. Isn't it how it's working in other APIs like VST3?

[Funkybot]

CLAP plugins don't appear in the FX Browser under the "Developers" list. I'm not sure if/how CLAP supports "Categories" but they may not be there either if they're 'supposed to.'

[STOP]

Originally Posted by Denys

Hello, the default path for CLAP doesn't seem to work on my system (W11 21H2, system language set to French Canadian). It is shown all caps, with %\, as the LV2 path on the following screenshot:




After setting it manually, the only CLAP plugin I have (Fog Convolver 2) seems to be recognized, but the loading fails.

"Fog Convolver 2" Demo version working fine here.
Windows 11 French Canadian

[STOP]

CLAP Surge XT issue, like if the keyboard sustain pedal is held on.

[EvilDragon]

Originally Posted by STOP

CLAP Surge XT issue, like if the keyboard sustain pedal is held on.

What sort of issue? Please a bit more detail. Sustain pedal in Surge XT CLAP works fine over here.

[EvilDragon]

@schwa/Justin - it seems REAPER does not read the CLAP_PATH environment variable? Envvar is supposed to (I think) take precedence over Common Files one, so it'd be nice if REAPER picked it up automatically and set as the most important one (last listed path).

[schwa]

Originally Posted by mike@overtonedsp

Doing some testing with CLAP support (Linux). I noticed when I adjust a CLAP parameter value in Reaper's UI, in some cases its not possible to adjust to the full max and min values.

Thanks for the detailed report. This does affect all plug-in types when using the generic UI in REAPER, but we should be able to improve it.

[Sexan]

Originally Posted by Gass n Klang

But I think it could be really cool, if it was resetted to its previous length as soon as the trim exceeds the boundaries of the smaller item. at the moment there is a tiny little item remaining which isn't useful for anything:

alternativly the small item could be deleted

+1 for any

[mike@overtonedsp]

I agree with your conclusion regarding reponsibility of the host. Looks like Bitwig is doing it right. Isn't it how it's working in other APIs like VST3?

VST3 implements a more conventional model-view-controller style architecture, which means these issues around 'state' are better managed (that's kind of the point). CLAP (and VST2) seem a bit more naive in that respect, with some rules that the CLAP plugin is responsible for synchronizing its UI to DSP state and the host just sits on top (if I understand it correctly). So it seems more open to interpretation.

In VST2 its perfectly possible that you can setParameter from any thread, so it might be that if you do setParameter getParameter getParameterDisplay in response to a host UI control change, you actually just set and read back some locally stored value in the plugin anyway, that hasn't yet propagated to the DSP. Effectively the same as the host just echoing its own UI parameter changes locally.

[STOP]

Originally Posted by EvilDragon

What sort of issue? Please a bit more detail. Sustain pedal in Surge XT CLAP works fine over here.

When I play notes on the keyboard (midi controller) all the notes get stuck.

nightly.d6f3c71
Windows 11

Edit: No issue with Odin 2 CLAP version

[EvilDragon]

Yeah I don't get that over here at all...

[Gass n Klang]

Is this intended? The smaller item will be influenced by the boundaries of the larger items but not vice versa. I think this behaviour makes sense when it comes to moving the smaller item, cutting or whatever. But if you expand the boundaries I'd expect the larger items to be expanded as well as soon as they line up.

[Gass n Klang]

probably the same hickup but it even doesn't work with items that start earlier as long as they end earlier, too. I think this is no expected behaviour (as the items are not even select. So only the boundaries should count I think)

[Tas from planet u-he]

Originally Posted by Denys

Hello, the default path for CLAP doesn't seem to work on my system (W11 21H2.
After setting it manually, the only CLAP plugin I have (Fog Convolver 2) seems to be recognized, but the loading fails.

You likely made the same mistake as I did, and downloaded the 32bit version of the Reaper build, as it's the first link in the downloads list and its name doesn't imply that it's a 32bit installer.

The 64bit installer can be found towards the end of the list.

[Denys]

I confirm this now works with the proper Reaper version. Thank you, Tas!

[AZpercussion]

Originally Posted by Gass n Klang

probably the same hickup but it even doesn't work with items that start earlier as long as they end earlier, too. I think this is no expected behaviour (as the items are not even select. So only the boundaries should count I think)

This item you trimming on the gif has no followers.
If you try to move it, it will moved independently of other items.
It would be weird if trimming work different way than moving.

But earlier I suggested a way that can adress this case.
We need to check neighbour items on the leader track and decide for each possible follower which item is a leader.



This way still have gaps, but less than now.
I hope that devs will take a look at this closer.

[Gass n Klang]

well in my understanding it's TRACK groups. So there is no leader/follow item (fortunatly). It's just track based.

For me this behaviour is unexpected:


And it's especially confusing when doing editing while zoomed in:


Perhaps this could be changed at least if no item is selected? When selected, you can easily see the group of selection.

Nevertheless: Editing is SO MUCH MORE FUN now! I completly swapped my time selection <-> razor edit behaviour and use track grouping every day. It saves so much time. Thanks a lot, DEVs