v6.67+dev0914 - September 14 2022

[sockmonkey72]

v6.67+dev0914 - September 14 2022

• * Includes feature branch: media item fade editing changes
• * Includes feature branch: selected media item appearance changes
• * Includes feature branch: track grouping manager dialog
• * Includes feature branch: CLAP plugin support
• * Includes feature branch: track media/razor edit grouping
• * 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
• + API: expose realloc_cmd_register_buf/realloc_cmd_clear to C/C++ API
• + CLAP: fix UI positioning and artifacts for plugins that don't support resizing
• + FX: fix CPU metering errors when using instance oversampling
• + Media explorer: when creating database from folder via context menu, name the database "DB: <foldername>" by default, for consistency
• + Render: after user-cancelled render, render statistics actions and API functions return nothing
• # CLAP: don't send 3-byte MIDI meta-messages to plugins as regular MIDI [p=2595436]
• # CLAP: prevent crash when passing sysex to plugins [p=2595417]
  

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

[sockmonkey72]

• + API: expose realloc_cmd_register_buf/realloc_cmd_clear to C/C++ API

What's this stuff for? Thanks!

[schwa]

Originally Posted by sockmonkey72

What's this stuff for? Thanks!

It's for extension (not needed by reascript) callers of REAPER API functions to more cleanly handle returned buffers from functions like GetSetProjectInfo_String() without knowing the length of the returned data beforehand. Somewhat technical.

[nofish]

@sockmonkey
https://forum.cockos.com/showthread....94#post2156994

Thanks @devs.

[sockmonkey72]

Originally Posted by schwa

It's for extension (not needed by reascript) callers of REAPER API functions to more cleanly handle returned buffers from from functions like GetSetProjectInfo_String() without knowing the length of the returned data beforehand. Somewhat technical.

I've been known to write extensions and REAPER-extended plugins, so this is the kind of technical stuff I like to know about.

So if I were calling GetSetProjectInfo_String() from my extension, I would do something like:

char *ptr = NULL;
int size = 0;
int tok = realloc_cmd_register_buf(&ptr, &size); // allocate ptr and return initial ptr/size
GetSetProjectInfo_String(NULL, "NEEDS_BIG", ptr, false); // REAPER checks some internal table of registered pointers to see if it can realloc for the data to be returned, doing so as necessary
realloc_cmd_clear(tok); // don't need you anymore

?

[schwa]

Originally Posted by sockmonkey72

I've been known to write extensions and REAPER-extended plugins, so this is the kind of technical stuff I like to know about.

So if I were calling GetSetProjectInfo_String() from my extension, I would do something like:

char *ptr = NULL;
int size = 0;
int tok = realloc_cmd_register_buf(&ptr, &size); // allocate ptr and return initial ptr/size
GetSetProjectInfo_String(NULL, "NEEDS_BIG", ptr, false); // REAPER checks some internal table of registered pointers to see if it can realloc for the data to be returned, doing so as necessary
realloc_cmd_clear(tok); // don't need you anymore

?

That should work, although a more typical usage would be to have ptr/size initially point to a reasonable-sized local buffer. That way no heap allocation occurs if the returned data is small enough to fit in the provided buffer.

char buf[4096];
char *ptr = &buf;
int size = sizeof(buf);
int tok = realloc_cmd_register_buf(&ptr, &size); // allocate ptr and return initial ptr/size
GetSetProjectInfo_String(NULL, "NEEDS_BIG", ptr, false); // REAPER checks some internal table of registered pointers to see if it can realloc for the data to be returned, doing so as necessary
realloc_cmd_clear(tok); // don't need you anymore

[sockmonkey72]

Originally Posted by schwa

That should work, although a more typical usage would be to have ptr/size initially point to a reasonable-sized local buffer. That way no heap allocation occurs if the returned data is small enough to fit in the provided buffer.

char buf[4096];
char *ptr = &buf;
int size = sizeof(buf);
int tok = realloc_cmd_register_buf(&ptr, &size); // allocate ptr and return initial ptr/size
GetSetProjectInfo_String(NULL, "NEEDS_BIG", ptr, false); // REAPER checks some internal table of registered pointers to see if it can realloc for the data to be returned, doing so as necessary
realloc_cmd_clear(tok); // don't need you anymore

Got it, that makes sense. Clever, thanks!

[schwa]

Originally Posted by sockmonkey72

Got it, that makes sense. Clever, thanks!

( this was all Justin )

[helgoboss]

That realloc stuff is great. I was always allocating lots of heap memory when getting track chunks, just to be sure. If I understand correctly, this can be optimized now Thanks devs!

[Tale]

• + CLAP: fix UI positioning and artifacts for plugins that don't support resizing
• # CLAP: don't send 3-byte MIDI meta-messages to plugins as regular MIDI [p=2595436]
• # CLAP: prevent crash when passing sysex to plugins [p=2595417]

FWIW, I can confirm that these issues are fixed. Thanks!

I do have a new issue: My CLAP IPlug example effect is now listed as CLAPi instead of CLAP. Its CLAP features are "audio-effect" and "stereo".

[Tale]

If I use CLAP_PARAM_IS_BYPASS on a CLAP plugin parameter, then it would seem that this parameter is omitted from the generic UI parameter list. However, it is still included in the automation list. I guess it should be omitted there as well, because else you can automate both the parameter and REAPER's own bypass, which could lead to conflicting values.

(BTW, I have no plugin to test this with, because IMHO the whole CLAP_PARAM_IS_BYPASS isn't well-defined. Also, I can't get it to play nice with Bitwig, so for now I've given up on it.)

[daxliniere]

Originally Posted by nofish

https://forum.cockos.com/showthread....94#post2156994

Okay, wow, that's a big deal. Awesome. *applause*

[BartR]

Originally Posted by sockmonkey72

v6.67+dev0914 - September 14 2022[*] * Includes feature branch: media item fixed lanes

2 things can be interesting.
the first: to add a lane upfront recording. It's just more clear, more intuitive as well, to the user. I mean upfront any recording even the very first. Perhaps adding a insert empty lane in grayish (since a lane has sense after the first one is recorded)

the second: it will be nice if adding a lane, the vertical amplitude of the track increases accordingly, without being constrained to do it manually.

[mschnell]

Originally Posted by sockmonkey72

v6.67+dev0914 - September 14 2022

• * Includes feature branch: internal pin management overhaul for future extension

Regarding discussions in the Feature Request forum:
I am slightly confused why here, Audio and Midi routing is presented to the user in a very different way, even though we do have Audio channels and Midi buses that follow a similar concept, and for tracks a common Routing Matrix. In theory that also could be a pin routing matrix for Midi, as well.
-Michael