v6.29rc5 - May 12 2021

[mabian]

v6.29rc5 - May 12 2021

• * Includes feature branch: custom metadata columns in Media Explorer
• * Includes feature branch: razor envelope editing
• * Includes feature branch: ReaSurroundPan
• + JSFX: allow export_buffer_to_project() to use 64 channels
• + Notation view: assign current voice when inserting notes via "insert note at nearest X" actions [t=216159]
• # Razor edit: fix trim-behind behavior [p=2443104]

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

[xpander]

Originally Posted by mabian

# Razor edit: fix trim-behind behavior [p=2443104]

Working again at least here, thanks for the fix!

[mccrabney]

razor edits are still getting pooled when split by RE movements.

this has severe, unintended, offscreen consequences if you use RE to split an AI in order to propagate parts of a project containing AI to other parts of the project.

[bolgwrad]

Originally Posted by mccrabney

razor edits are still getting pooled when split by RE movements.

this has severe, unintended, offscreen consequences if you use RE to split an AI in order to propagate parts of a project containing AI to other parts of the project.

Does this preference not fix that?



Unchecking the 'When copying with tracks or media items' option seems to create an unpooled AI by default.

[schwa]

Originally Posted by bolgwrad

Does this preference not fix that?

That preference controls what happens when copying an automation item via razor edit, but not when doing the split-and-move edit shown in the screencap.

[bolgwrad]

Originally Posted by schwa

That preference controls what happens when copying an automation item via razor edit, but not when doing the split-and-move edit shown in the screencap.

Right, thx

[n997]

Originally Posted by mccrabney

razor edits are still getting pooled when split by RE movements.

this has severe, unintended, offscreen consequences if you use RE to split an AI in order to propagate parts of a project containing AI to other parts of the project.

Thanks for catching that one!

[mschnell]

I am doing a testing plugin using the JUCE library.

It's a VST3 and features GUI embedding (TCP/MCP). Hence it only works with the prerelease Version of Reaper (and with a tiny patch for the JUCE sources).

I ran into a peculiar problem:

In one of its functionalities, The plugin replaces a certain CC message (channel 1, CC#1) by the same with a different channel ID = 2.

In JUCE you need to do this by saving the appropriate messages in a second buffer, clear the buffer provided and then add all new messages to the buffer.

What happens is that the input messages stay in the stream together with the new messages.

I did theses additional tests:
Using Pitchbend messages instead of CC: same behavior.
Clear the buffer but don't add new messages: empty stream -> neither new nor old messages.

(Of course the plugin environment in Reaper is set to "Midi Output Replaces Midi Bus (default)".)

I filed a report in the JUCE forum and they checked out the behavior (doing their own code).

-> https://forum.juce.com/t/midi-filter/45997 :

"I can reproduce the issue you’re seeing in REAPER, but not in Bitwig Studio or the AudioPluginHost. Debugging through the VST3 wrapper, I can’t see anywhere that duplicate messages might be introduced. The IEventList of output events appears to have the correct number of entries after the process call. Therefore, I think the issue is likely on REAPER’s side."

I suppose they used the released version of Reaper (and an unpatched JUCE source) as they did not implement "embedding" in their test plugin. (That is why I post a link to this message in the "bug reports" forum, as well.

My (still unfinished) plugin for testing -> http://www.bschnell.de/VST3_Test_mschnell.zip
With the slider more than half, the buffer is cleared and new messages are added to the buffer. With the slider less than half, the buffer is just cleared:

    midiMessages.clear();
    if (pos >= 0) {
        if (currentParameter.midiVolume > 64) {
            midiMessages.addEvents(newMidiMessages, 0, -1, 0);   // add all
        }    
    }

-Michael

[mschnell]

I verified that when compiling the same code to a VST2. the problem does not occur.

-Michael