v6.64+dev0806 - August 6 2022

[Edgemeal]

v6.64+dev0806 - August 6 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
+ MIDI: add action to insert all available retroactively recorded MIDI
# MIDI: retroactive record will overdub into existing fully-overlapped item if in overdub mode
# MIDI: round retroactively recorded MIDI up to measure length
# SD2/PCM/RAW: add some help to source properties dialog
# SD2: fix endianness display in media source properties

Full changelog - Latest pre-releases

[sonicowl]

Is Input Quantize working for retroactive record? If yes, can it be enabled/disabled via action?

[daniellumertz]

I think this has been buried in the devs threads because I was investigating and editing a post. but videos dont work on Fixed Item Lanes Tracks https://forum.cockos.com/showpost.ph...1&postcount=40

[schwa]

Originally Posted by daniellumertz

I think this has been buried in the devs threads because I was investigating and editing a post. but videos dont work on Fixed Item Lanes

Fixing, thanks for the report.

[sockmonkey72]

+ MIDI: add action to insert all available retroactively recorded MIDI

Is this different from the other action in terms of time or in terms of record-enable state? Or some other factor? Thanks!

[Justin]

Originally Posted by sockmonkey72

Is this different from the other action in terms of time or in terms of record-enable state? Or some other factor? Thanks!

it inserts everything available, not just the most recent stuff (as a result you lose project synchronization info, you just get the raw data)

[vitalker]

Originally Posted by Justin

it inserts everything available, not just the most recent stuff (as a result you lose project synchronization info, you just get the raw data)

Available since last recording?

[Justin]

Originally Posted by vitalker

Available since last recording?

and beyond, everything in the history

[sockmonkey72]

Originally Posted by Justin

it inserts everything available, not just the most recent stuff (as a result you lose project synchronization info, you just get the raw data)

A useful action would be "Clear retrospective MIDI cache" to permit rigging together the different use case wishes (wrt when the cache is supposed to begin caching).

[Justin]

Originally Posted by sockmonkey72

A useful action would be "Clear retrospective MIDI cache" to permit rigging together the different use case wishes (wrt when the cache is supposed to begin caching).

yeah that could be handy

[vitalker]

Originally Posted by Justin

and beyond, everything in the history

Wow, wouldn't it make the world collapse?

[daniellumertz]

Originally Posted by Justin

it inserts everything available, not just the most recent stuff (as a result you lose project synchronization info, you just get the raw data)

idk if I misunderstood but with MIDI: Insert retroactively recorded MIDI for armed tracks. it should restore the midi synchronized where it was played in the project (if project is playing while MIDI are pressed)? Just asking because if I run this action while playing the item is created some bars after the playhead.

how the algorithm decides the length to restore? everything till last big pause(set in X seconds/bars)? everything till last play/stop ?

[daniellumertz]

Originally Posted by vitalker

Wow, wouldn't it make the world collapse?

if they will release that in 6.66, probably xD

[Kundalinguist]

Thanks for the evolutionary bump to sd2 conversion.

[mccrabney]

retroactive MIDI record is going to be very useful, thanks.

i'm having a little trouble figuring out how exactly these actions are deciding where to paste the retroactive MIDI. i only just joined on today's pre so i don't know if this is a result of "# MIDI: round retroactively recorded MIDI up to measure length"



in this gif, i have 8 markers. after hitting play, i retroactively record a note on each odd numbered marker. when i paste the retroactive MIDI, it pastes as expected, on markers 1, 3, 5, 7. i move this item to the next track and try again. this time, i retroactively record a pass of notes on even numbered markers. when i insert the retroactive MIDI, however, it inserts on odd markers.

i think that the expected behavior here would be that, if project is in playback when the MIDI was recorded, the performance would be entered exactly where it was performed in the project.

--------

currently the "insert retroactive" actions are working even on armed tracks marked "record disable" - this causes mayhem in armed/disabled MIDI effects/monitoring/routing tracks that are never intended to have MIDI items in them. these tracks should be excluded from these actions.

on that note, inserting MIDI from selected tracks only would be helpful to those of us working with several always armed MIDI tracks, i'm often only looking to call back an improvisation on one track/instrument at a time.

------

in this gif, i have playback stopped. after a pause, i record three taps of a chord. i then insert the retroactive MIDI. the resulting item includes the pause before i tap the keys, which is expected. however, it'd be useful to optionally be able to strip the "silence" before the first MIDI note/cc occurs. that would make inserting it at edit cursor more straightforward - perhaps even handing the retroactive MIDI data directly to the clipboard.



---------

lastly, +1 for an action to fully reset/clear the retroactive MIDI buffer. play/stop allows us to start over, but being able to fully clear it would be nice for custom actions

[Gass n Klang]

Mouse modifier: razor edit area: remove one area deletes just one area also when used in track edit groups while creating a razor edit mirrors that to all grouped tracks. I think "remove one area" also should remove that area from all grouped tracks.

[Kundalinguist]

re; sd2 file conversion.

Thanks for your efforts to bring this feature in. I appreciate it. I do have one question, however, that may influence how easily it will convert my old Digital Performer files (circa v6).

I have included an attached screen shot of what is inside the "Audio" folder of the DP project. As you can see, the suffix is NOT sd2 but rather .R and .L.

I'm not sure if these were originally stereo files, or if they were bounced to stereo. I assume the latter.

My question is: can Reaper be made to detect these files for import because currently it can't see them; they are greyed out. I had to add the .sd2 suffix by hand (which I could easily do in bulk with a renaming macro). However, it does change the name of the file at that point and it will then lose it's place within the timeline and probably be considered a "missing file" with an alert.

Any thoughts? I figure the easiest is to click import and Reaper just sees the file for what it is without the suffix. Can it be done?

Thanks again. This is a useful addition for me.

[_Stevie_]

Thanks for the retro rec additions, much appreciated!

[Lynx_TWO]

CLAP support already? D-mn, these developers are on top of it!

[schwa]

Originally Posted by Kundalinguist

re; sd2 file conversion.

Thanks for your efforts to bring this feature in. I appreciate it. I do have one question, however, that may influence how easily it will convert my old Digital Performer files (circa v6).

I have included an attached screen shot of what is inside the "Audio" folder of the DP project. As you can see, the suffix is NOT sd2 but rather .R and .L.

I'm not sure if these were originally stereo files, or if they were bounced to stereo. I assume the latter.

My question is: can Reaper be made to detect these files for import because currently it can't see them; they are greyed out. I had to add the .sd2 suffix by hand (which I could easily do in bulk with a renaming macro). However, it does change the name of the file at that point and it will then lose it's place within the timeline and probably be considered a "missing file" with an alert.

Any thoughts? I figure the easiest is to click import and Reaper just sees the file for what it is without the suffix. Can it be done?

Thanks again. This is a useful addition for me.

If these are raw PCM audio files, make a copy and add the extension .sd2 (or .pcm or .raw, it will all work the same way). You can then try to import them into REAPER. It's likely you will have to edit the audio attributes to get the files to play back correctly; open the source properties dialog for instructions on how to do so.

If the files contain metadata describing their position in the project, it's probably within a proprietary resource fork (essentially a hidden sidecar file) and there's no way to preserve that information in REAPER. Or that metadata may be in some sort of header chunk within the file, in which case they aren't raw PCM files and when imported into REAPER, there will be some garbage audio at the beginning and the files may not be importable at all. You'll have to experiment and see!

If you want, you can link to one of the files and we can look at it to see if it actually is raw PCM or something different.

[Justin]

Originally Posted by mccrabney

in this gif, i have 8 markers. after hitting play, i retroactively record a note on each odd numbered marker. when i paste the retroactive MIDI, it pastes as expected, on markers 1, 3, 5, 7. i move this item to the next track and try again. this time, i retroactively record a pass of notes on even numbered markers. when i insert the retroactive MIDI, however, it inserts on odd markers.

Hmm I can't duplicate that...

[mccrabney]

here, i think i've got it reproducing on a test file (attached on edit) on a vanilla install using virtual midi keyboard inputs.



here, i hit play, wait a second, and then mouse over the VMKB. then i insert retroactive MIDI.
while both tracks are armed, the MIDI is recalled out of place.
when i disarm the top track, the MIDI is recalled as expected.

[mccrabney]

one more gif of a different angle of the issue, in case it's helpful:

here, i've switched the top track to "all channels" of the vmkb.
track 2 is set to receive vmkb ch1.

i hit play, pause a second, sweep the keys, and run the insert retroactive MIDI action. the MIDI is not recalled correctly in track 1, incorrectly in track 2.

[Justin]

Originally Posted by mccrabney

one more gif of a different angle of the issue, in case it's helpful:

here, i've switched the top track to "all channels" of the vmkb.
track 2 is set to receive vmkb ch1.

i hit play, pause a second, sweep the keys, and run the insert retroactive MIDI action. the MIDI is not recalled correctly in track 1, incorrectly in track 2.

thanks, that’s helpful!

[Kundalinguist]

Well, Schwa, things just got a little more interesting on this end. Turns out when I name the files with the .sd2 suffix, I can drag them into the reaper timeline. Maybe you know this, but I sure didn't.

So that's another thing to cheer about.

Below is a link to a file in the format that I described. Uploading files has been a struggle for me cause I couldn't find one that was small enough. But this one should work.

https://stash.reaper.fm/45027/frz%20room-0.L.zip

Originally Posted by schwa

If these are raw PCM audio files, make a copy and add the extension .sd2 (or .pcm or .raw, it will all work the same way). You can then try to import them into REAPER. It's likely you will have to edit the audio attributes to get the files to play back correctly; open the source properties dialog for instructions on how to do so.

If the files contain metadata describing their position in the project, it's probably within a proprietary resource fork (essentially a hidden sidecar file) and there's no way to preserve that information in REAPER. Or that metadata may be in some sort of header chunk within the file, in which case they aren't raw PCM files and when imported into REAPER, there will be some garbage audio at the beginning and the files may not be importable at all. You'll have to experiment and see!

If you want, you can link to one of the files and we can look at it to see if it actually is raw PCM or something different.

[schwa]

That file appears to be 1 channel, 44.1k, 24 bit int, big endian pcm data, which happen to be the default attributes that REAPER uses when loading unknown pcm files. There's no apparent resource fork or embedded metadata. So, as you've found, change the file extension to .pcm or .sd2 or .raw (they are all treated the same way) and REAPER can play back the file just like any other supported media.

[pcp]

Nice improvements to retroactive record, thanks!

Assuming there is minimal resource usage from maintaining a long history, I'll put a contrarian -1 to the 'clear retroactive cache' suggestion, as I reckon allowing scripts to delete could lead to surprises on a safety-belt feature. Unless there's some use-case I'm not seeing.

The different insert/sync behaviours of the two retroactive actions might be confusing. I would still prefer a single action that inserts the recent synced data, like the main action does currently, but 'hides' the remaining raw MIDI data behind the left edge of the created media item ... seems the most logical and accessible.

[Kundalinguist]

Originally Posted by schwa

That file appears to be 1 channel, 44.1k, 24 bit int, big endian pcm data, which happen to be the default attributes that REAPER uses when loading unknown pcm files. There's no apparent resource fork or embedded metadata. So, as you've found, change the file extension to .pcm or .sd2 or .raw (they are all treated the same way) and REAPER can play back the file just like any other supported media.

Thanks, Schwa. I've looked at a few more and they all seem to be of this type. I don't know why DP and Pro Tools created the .sd2 file type if it shared the same basic characteristics as others. Maybe to lock people into their architecture. But as many found out just a few years later, it's a pain in the butt to have to convert all those projects so they can be properly archived.

Thanks again, Schwa. I'm sure this is going to come in quite handy in a number of ways, not the least of which is the ease of importing those DP audio files via drag and drop into Reaper. Yay!

[Arthur McArthur]

Great additions to retro record, thank you devs!!

[cern.th.skei]

now that i can confirm that my (linux) clap plugins work well in reaper too, i guess it's time to re-register again.. but maybe i'll wait a version or two, until it says reaper 666..

[hans]

Track group editing;
Mouse modifier moving contents and right edge - ripple later adjacent.

Dragging past left edge and back of the selected items does the following on the first track;

[Gass n Klang]

Originally Posted by Edgemeal

v6.64+dev0806 - August 6 2022
* Includes feature branch: track media/razor edit grouping

1) Could we please have a predefined "All" edit group for all tracks (existing and future). Activating that group could make it super easy to do razor edits to the whole arrangement.

2) It would be helpful to have a dockable window that shows which groups are in use, so we easily can disable individual groups by one single click:

[airon]

Groups are a little harder to manage than in old PT.

The Track Grouping properties only uses a dropdown, not a list. Perhaps that is an opportunity for a little redesign.

Or the grouping matrix. One of the harder ways to find the group you want to edit. Perhaps a list to the left of the matrix as an alternate way. Maybe even CTRL+click on the list to display the groups as they are now all displayed in the matrix. Just throwing that out there.

The old PT list view of groups made it easy to activate and deactivate the edit and/or mix groups you could have. You clicked on the entry to toggle it on/off. That made editing with what is a razer group in Reaper easier. The "All" group is a practical preset unalterable group to make recutting entire sessions easier.

The reconforming of sessions to new picture edits will happen via such groups if done by hand and not by applications such as Vordio(in Reapers case).

I find the track grouping properties window a very narrow view in to what groups can do. Like an FOV in a first person view game set really low. The group list is just one idea though. You can probably come up with something better.


My needs for razor editing grouping are

• recutting entire sessions (including all automation visible or not)
  
  
• copying bits and pieces of scenes to the next episode(recaps)
  -edit- Fast setups that can be created and edited are a help here. Sometimes it may be the odd track here, which is much quicker and precise than creating multiple razer edit selections. So bypassing and clearing groups needs to be fast too, as you're likely using a group or two to facilitate this kind of editing on all kinds of tracks during a session of 10+ 20 minute episodes.
  
  
• music editing across stems and non-stem mixes

My mixing group needs aren't met at all. A script my SPK77 with a slight mod by me for toolbar indication gives me some semblance of that, but this is just a sidenote.


I need to pick tracks to edit very quickly. The track group properties window is the fastest way to do this. The matrix is the slowest, so I hardly ever use it. But the matrix gives me an ok overview, even though it's so spread out. The track group properties window gives me NO overview.

With the razer edit groups this situation could use some clever help .

[mccrabney]

Assuming there is minimal resource usage from maintaining a long history, I'll put a contrarian -1 to the 'clear retroactive cache' suggestion, as I reckon allowing scripts to delete could lead to surprises on a safety-belt feature. Unless there's some use-case I'm not seeing.

that's really up to script writers and users themselves to avoid, imo, just like any other action that may do something a user doesn't want to do.

the use case supported by "clear buffer" is being able to snatch specific phrases out "of thin air" and quickly inserting them where they belong, without a long lead-in. programmatic use of "clear buffer" in custom actions will allow users to more effectively manage what's in the buffer.

"global callback" of all retroactive MIDI for all tracks is useful, but very blunt. if i'm playing piano on track/channel 3 and like what i just heard, i don't want to clutter up my timeline with 20 minutes of MIDI on 7 other tracks/channels - some of which may have been unwantedly written into existing MIDI items, due to the recent overdub-encapsulated pre addition.

[Gass n Klang]

There is a bug that appears if auto-crossfade is off, and trim content behind media items is on

That bug affects all crossfades on the grouped tracks

[Gass n Klang]

This setting in dynamic split isn't compatible with grouped tracks. An additional "split selected items (observe track edit groups)" would be nice.

[nofish]

Re: CLAP support

My plugin does come up with the default values I've defined when inserting in Reaper, but when moving the sliders then doing a 'Reset to factory default', nothing happens (the sliders don't move to their initial values).

Bug in Reaper or my plugin?

(p=2583166 and p=2583184 seem fixed here btw. thanks)

[mike@overtonedsp]

My plugin does come up with the default values I've defined when inserting in Reaper, but when moving the sliders then doing a 'Reset to factory default', nothing happens (the sliders don't move to their initial values).

This happens with my plug-ins too - however the effect of the factory reset can be heard in the audio, and if you toggle between the Reaper UI and the Plug-In UI, the controls correctly update. So it seems like this is just a redraw / refresh issue with the Reaper UI rather than the actual parameter values?

(Can I also reiterate my request for CLAP_PARAM_IS_BYPASS functionality if possible - if / when any of the devs pick this up)

[AZpercussion]

Originally Posted by airon

The reconforming of sessions to new picture edits will happen via such groups if done by hand and not by applications such as Vordio(in Reapers case).

Yeah, we need overview better than matrix.
I want to add something about reconforming.

Maybe it can be solved by razor grouping, may be by other stuff...
For now we have to use regions to reconform whole project if we need to move master track automation along with items.
But if we have new video or something else, that shouldn't be moved, it will be splitted and moved even it locked, fail(
Also it's slow to use regions if there are many edits.
We could use razor area (for now there is background script which duplicates razor area from folder track to children ones), but master track automation can't be moved by razor.

So, I think, it's need to allow razor on the master track, including tempo envelope. And then yes, it could be integrated with track grouping function.