v6.08+dev0418 - April 18 2020

[SmajjL]

v6.08+dev0418 - April 18 2020

• + JS: update Add-FX displayed effect name when saving plugin in editor
• # MIDI Sequencer Megababy: clamp keyboard view to valid MIDI note range
• # MIDI Sequencer Megababy: support note name maps in the same format as the MIDI editor
• # Render: better handling of skipping silent renders when rendering stems that are folders

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

[Klangfarben]

Originally Posted by SmajjL

# Render: better handling of skipping silent renders when rendering stems that are folders

So the render inclusion/exclusion on multiple selected folders/tracks seems to be working properly.

I ran into another issue though which is folder tracks are not respecting muted items/tracks in subfolders/children.

Here are the steps in the GIF below:
1) Select Folder track (Brass Long) with unmuted item in active subfolder/child track. Works correctly and Folder track is included in render.
2) Mute item in active subfolder/child track. The Folder track is not excluded but should be since there are no unmuted items in any of the subfolders/children
3) Mute the child track itself. The Folder track is still not excluded.
4) Mute the Folder track itself. The Folder track is not excluded. As it is muted, obviously no audio will be printed and it should be excluded.
5) Mute the child track, track item and Folder track. The Folder track is still not excluded.



If you select an individual track that either has only muted items or the track is muted, it is correctly excluded from the render. The same behavior should hold true for Folder tracks with subfolders/child tracks/items.

[schwa]

Originally Posted by Klangfarben

So the render inclusion/exclusion on multiple selected folders/tracks seems to be working properly.

We'll fix the behavior in your cases 4 and 5, where the folder track itself is muted, but the other cases seem to be working locally here. If that project is in the same state you posted earlier, the Brass Long folder has another unmuted child track, Horns Long, which itself contains child tracks with unmuted media items.

[Klangfarben]

Originally Posted by schwa

We'll fix the behavior in your cases 4 and 5, where the folder track itself is muted, but the other cases seem to be working locally here. If that project is in the same state you posted earlier, the Brass Long folder has another unmuted child track, Horns Long, which itself contains child tracks with unmuted media items.

You are 1000% right. My apologies. I should have been doing the test with the folder track below, not Brass Long. Can confirm the behavior is working correctly except for the folder track itself being muted as you stated. Thank you so much!

[Klangfarben]

Originally Posted by schwa

We'll fix the behavior in your cases 4 and 5, where the folder track itself is muted, but the other cases seem to be working locally here. If that project is in the same state you posted earlier, the Brass Long folder has another unmuted child track, Horns Long, which itself contains child tracks with unmuted media items.

You might want to consider one more use case. If there are midi items on a child track but no plugins or midi sends on that track, it should also be excluded from render since no audio can be triggered by the midi and the midi is not being sent to another track. Sometimes users place midi items on dummy tracks so they can see a part while working/playing on another track. This is also common occurrence when importing midi files.

[schwa]

We can have it skip empty or text or image items. Tracing the routing carefully enough to skip MIDI items that don't actually play back probably adds more complexity than benefit.

If you are using dummy tracks for visual reference, you should disable the master/parent send for those tracks anyway, right?

[Reflected]

no subprojects love

[_Stevie_]

Originally Posted by schwa

We can have it skip empty or text or image items. Tracing the routing carefully enough to skip MIDI items that don't actually play back probably adds more complexity than benefit.

But wouldn't it be better to get the feature right in the first place, taking into account the valuable feedback from users who actually have use cases for this feature? I know it may sound absurd...

[EvilDragon]

Originally Posted by Reflected

no subprojects love

Because they're obviously not the focus of this prerelease cycle. Read Justin's post here.

[schwa]

Originally Posted by _Stevie_

But wouldn't it be better to get the feature right in the first place, taking into account the valuable feedback from users who actually have use cases for this feature? I know it may sound absurd...

Sorry, what do you mean?

[_Stevie_]

Well, although it might be a little more complex, covering use cases like midi items not triggering anything and free running VSTi (for example Reaktor ensembles) would be valuable and worth the effort to make the feature more complete IMHO. The issue is, users might expect this to work and might get confused, because it doesn't = bad user experience. I think it's really worth the extra mile.

[_Stevie_]

Quick follow up for an example of those free running Reaktor Ensembles:
https://youtu.be/1a00OH19vqw?t=145

[schwa]

Originally Posted by _Stevie_

Well, although it might be a little more complex, covering use cases like midi items not triggering anything and free running VSTi (for example Reaktor ensembles) would be valuable and worth the effort to make the feature more complete IMHO. The issue is, users might expect this to work and might get confused, because it doesn't = bad user experience. I think it's really worth the extra mile.

If the user has a dummy track with dummy items, it won't trigger a render unless it's routed somewhere. I think it's reasonable to put the burden on the user to disable routing for dummy tracks. It's also a reasonable use case for the user to intentionally trigger a render using an empty item, so I don't think this is a situation where adding complexity to handle one case and not the other is a benefit. It's also much worse to render too little than too much, so if there's any ambiguity, the default should be to render rather than skip.

What is an example where rendering a free running instrument would not behave as expected with the new option?

[Klangfarben]

Originally Posted by schwa

If the user has a dummy track with dummy items, it won't trigger a render unless it's routed somewhere.

Just to be clear any track with unmuted items (in a folder or not) that has "parent send" checked in the routing would then be included, yes? So in the case of excluding from render the user would need to uncheck parent send (sorry if I'm misunderstanding here).

Originally Posted by schwa

What is an example where rendering a free running instrument would not behave as expected with the new option?

Maybe someone who uses these more can chime in here, but if you have a free running VSTi enabled on a track - generating audio with no items or muted items only - currently that would be excluded from the render, yes? As well as folder tracks that contained child tracks with free running VSTi and no items/muted items. I think this is the case Stevie and others are referring to.

EDIT: A test tone or SMPTE generator would be another example of this.

[schwa]

Originally Posted by Klangfarben

Just to be clear any track with unmuted items (in a folder or not) that has "parent send" checked in the routing would then be included, yes? So in the case of excluding from render the user would need to uncheck parent send (sorry if I'm misunderstanding here).

Yes, that's correct.

Originally Posted by Klangfarben

Maybe someone who uses these more can chime in here, but if you have a free running VSTi enabled on a track - generating audio with no items or muted items only - currently that would be excluded from the render, yes? As well as folder tracks that contained child tracks with free running VSTi and no items/muted items.

Also correct, but the use case where you have a free running vsti and also want to render regions but exclude silent files seems narrow. In that situation, It seems reasonable to ask the user to add empty items for the regions of the free running vsti that they actually want to render.

[Klangfarben]

Originally Posted by schwa

Also correct, but the use case where you have a free running vsti and also want to render regions but exclude silent files seems narrow. In that situation, It seems reasonable to ask the user to add empty items for the regions of the free running vsti that they actually want to render.

And the same for test tones/smpte generator prints, yes? That seems a bit unintuitive to me. Another example would be printing an 8th note click track at the same time as a quarter note click. Right now, there is no good way to do that in Reaper so the alternative is to use a Kontakt instance with the click sample loaded following DAW tempo and set to double incoming midi on play/midi input (again with no items).

Obviously, it would be difficult to cover all use cases but those are three examples where the user would have to create an empty item to be included in the render. If that is what you decide on (and obviously captain's prerogative here), you may want to rename the feature, since as Stevie said the expectation would be that if there is actual audio coming from those tracks, it would be included. If the feature is going to be based on active items, then you might want to instead call it "Do not render files without active items" as there would be less confusion as to what is included/excluded from render.

[deeb]

"Only render files with active items"?

[schwa]

Originally Posted by Klangfarben

And the same for test tones/smpte generator prints, yes?

What's an example case where you want to render a test tone that is not being triggered by anything in the project, but also want to skip rendering silent areas?

[AB1]

Originally Posted by deeb

"Only render files with active items"?

Yes, or better still something like "Only render within bounds containing active items", to emphasize to the user that they need to pay attention to the INPUT/trigger of the renders (active items or lack thereof actually on the track itself and within the region required) rather than the OUTPUT (the FILES that are output possibly having passed through a VST that requires no input).

[Klangfarben]

Originally Posted by schwa

What's an example case where you want to render a test tone that is not being triggered by anything in the project, but also want to skip rendering silent areas?

Sure that one is easy. I want to print all my stems (excluding silent) and I want to deliver a test tone track which is being generated by a JSFX that is calibrated to a specific amount so the mix studio can use that to match/calibrate on their end.

As a JSFX test generator doesn't need to be an audio item and just generates in real time and I can print all my stems without monitoring the test tone by sending it to a separate hardware out, I can then select all my stem folders + test generator track, render everything in one go AND have it exclude blank stems.

In the current scenario, I would first have to render my stems. Then go back and do a second render pass for just the test generator with the do not render option unchecked. Or put a blank item in the time selection of the Render. So the two options as they stand are do a second pass of render or create an empty item the length of the project (to make sure the test tone would always be included in the render regardless of the render area/time selection).

Same thing for printing an 8th note click. I want to print all my stem folders, the click track (inserted as click source) and the 8th note click track which has a Kontakt instrument on it receiving Host tempo and outputting click while the Reaper transport is playing and sending host tempo to Kontakt. Would be the same workaround. Either two separate renders or create an empty item the length of the project in the 8th note click track.

[EvilDragon]

That's a pretty good example. Workflows should be made easier, not harder.

[schwa]

Originally Posted by Klangfarben

I want to print all my stems (excluding silent) and I want to deliver a test tone track which is being generated by a JSFX that is calibrated to a specific amount so the mix studio can use that to match/calibrate on their end.

I think this is going to be a live-with-it situation. The fundamental issue is that REAPER needs to know the filenames before it starts rendering, so it can resolve wildcards, detect conflicts with existing files or existing items in the render queue, and increment filenames if necessary. That process sometimes involves interaction with the user and sometimes results in the render being canceled. It's not feasible to detect silence during or after the render, and then do the file resolution step.

So we need to determine which rendered files will be skipped based on the project state before the render, rather than the rendered output. I understand that won't handle your example case, but we are adding a new feature here, not changing existing behavior. If there are many workflows that immediately benefit from the new feature, and some workflows that require additional user action to benefit (like putting empty items where you want a test tone generator to be rendered), that's OK. If you don't enable the new feature, your workflow remains the same as it is now.

[heda]

wasn't it easier to just render it all and then delete silent files and rename remaining files? I think the render process could flag a file somewhere as having some signal while rendering, then delete flagged files. no need to rescan all files again for silence.

[EvilDragon]

It's not just about that, because you save time by not rendering stuff that doesn't need to be rendered in the first place. If I understood things correctly.


But say, on topic of renders, one thing that always irked me is limited number of meters being displayed in the render dialog during render, especially when rendering more than say 10 tracks. There's no scrollbar so you cannot see levels for other channels. There should be a scrollbar so that you can see all the meters, and also that dialog should be resizeable, too, maybe.

[schwa]

Originally Posted by heda

wasn't it easier to just render it all and then delete silent files and rename remaining files? I think the render process could flag a file somewhere as having some signal while rendering, then delete flagged files. no need to rescan all files again for silence.

It doesn't matter when you scan the files. The issue is that deleting some rendered files can cause some of the files you are keeping to need to be renamed, based on wildcards. If the renaming causes conflicts with existing files or renders in the queue, you end up in a very messy situation.

[heda]

ah ok. it is true. if there are many empty tracks being rendered it would hurt the hard drive performance for other tracks. I wasn't thinking about it.

yes I would love more meters to be visible to.

[Klangfarben]

Originally Posted by schwa

I think this is going to be a live-with-it situation. The fundamental issue is that REAPER needs to know the filenames before it starts rendering, so it can resolve wildcards, detect conflicts with existing files or existing items in the render queue, and increment filenames if necessary. That process sometimes involves interaction with the user and sometimes results in the render being canceled. It's not feasible to detect silence during or after the render, and then do the file resolution step.

Ok, thanks for the explanation. Like I said, not all use cases will be able to be covered. But it is good to know what those are so hopefully that information was useful.

I still think you might want to rename the feature. Probably with one of AB1's or deeb's suggestions rather than mine

[heda]

Originally Posted by schwa

It doesn't matter when you scan the files. The issue is that deleting some rendered files can cause some of the files you are keeping to need to be renamed, based on wildcards. If the renaming causes conflicts with existing files or renders in the queue, you end up in a very messy situation.

ok thanks for the explanation! I was not thinking all the possible problems. messy situation would be bad indeed.

[Klangfarben]

Originally Posted by schwa

I understand that won't handle your example case, but we are adding a new feature here, not changing existing behavior.

The other thing you could do is just make it two options for the feature. 1) Render tracks with active items and 2) Do not render tracks below x threshold (optionally with a user-specified value). So two checkboxes.

That would satisfy most all use cases. If users needed consecutive wildcard numbering they would choose the first option (as it currently is implemented). If users didn't need wildcard ordered numbering, they could use option 2 which would delete silent files after the render but not rename files (as your first version was implemented). Then a user could choose whatever option best suited them.

[_Stevie_]

That sounds like a pretty good solution to me, +1.

[RandomAwesome]

Originally Posted by EvilDragon

It's not just about that, because you save time by not rendering stuff that doesn't need to be rendered in the first place. If I understood things correctly.

Exactly. I recently delivered 6500+ stems to a band because I didn't have time to sort through the blank tracks.

But say, on topic of renders, one thing that always irked me is limited number of meters being displayed in the render dialog during render, especially when rendering more than say 10 tracks. There's no scrollbar so you cannot see levels for other channels. There should be a scrollbar so that you can see all the meters, and also that dialog should be resizeable, too, maybe.

This is a great idea! It's nice to see if something's clipping on the way out.

[operator]

Originally Posted by EvilDragon

[...] limited number of meters being displayed in the render dialog during render, especially when rendering more than say 10 tracks. There's no scrollbar so you cannot see levels for other channels. There should be a scrollbar so that you can see all the meters, and also that dialog should be resizeable, too, maybe.

This! :-) +1 from me on this one.

[AB1]

Originally Posted by Klangfarben

The other thing you could do is just make it two options for the feature. 1) Render tracks with active items and 2) Do not render tracks below x threshold (optionally with a user-specified value). So two checkboxes.

I included this 2nd option in the script I wrote for RandomAwesome's thread. I could only see how to scan audio items (all midi items included by default) but it might have been more useful to scan the track output for each required region, post FX and routing.

Is this possible with the current API?

Because if not, it would be great to have this amongst Reapers own render options. It might be better to scan before rendering, once all required tracks are selected, perhaps using a 'scan' button rather than the dialog auto-updating as tracks are selected. The scan takes time so might not save much time over doing an actual render, but it would allow users to take full advantage of Reapers filename management whilst obviously solving the problem of unwanted renders.

I wasn't pushing for this as I thought it might be a big ask, but since Klangfarben mentioned it already...
If not hopefully devs will consider it for further down the road making sure it could be an additional option without needing to change what has been discussed/implemented so far.

It would be a useful feature for example, for a static set-up of armed tracks and mics put up, where only some mics are in use and renders only required for recordings that peak over the background noise level picked up and recorded by all mics.

With a pre-render scan the two options Klangfarben suggested could possibly be independent rather than either/or.

[xpander]

Now that Megababy is also worked on, would it be possible to make it send All notes off command when changing Megababy presets?

Changing between different patterns while running playback works fine, when you are working within one preset. But if you change from one preset to another during live playback, the last note from the previous preset/pattern hangs, unless the following preset/pattern also has the same note.

[akademie]

Also, please look at clicking bug/problem in Super8 as reported in v6.08+dev0416a thread
https://forum.cockos.com/showthread....2&postcount=65

[Klangfarben]

Originally Posted by AB1

I included this 2nd option in the script I wrote for RandomAwesome's thread. I could only see how to scan audio items (all midi items included by default) but it might have been more useful to scan the track output for each required region, post FX and routing.

That is why I suggested including both options because Schwa has already coded them. The threshold method in dev0414 when the feature was introduced and the item method he changed to in dev0416. Since he already has done them both, I thought it might be a good/easy solution.

Originally Posted by AB1

It might be better to scan before rendering, once all required tracks are selected, perhaps using a 'scan' button rather than the dialog auto-updating as tracks are selected. The scan takes time so might not save much time over doing an actual render, but it would allow users to take full advantage of Reapers filename management whilst obviously solving the problem of unwanted renders.

I agree this might be the more elegant approach - depending on the scan time of course which I think most users would be ok with(?) But again captain's prerogative on this.

Originally Posted by AB1

With a pre-render scan the two options Klangfarben suggested could possibly be independent rather than either/or.

This is true and something I thought about. It would be better to have them independent rather than either/or. I do think though that if it is done this way there should be a user set threshold amount, especially in the example you provided. Otherwise, it would be a little more tricky to use the feature. But I didn't want to pile more on to Schwa and irritate him (more than I have already lol). So, I'm glad you did

[TonE]

Originally Posted by xpander

Now that Megababy is also worked on, would it be possible to make it send All notes off command when changing Megababy presets?

For what is Megababy useful for? Any precise examples?

[EvilDragon]

It's a step sequencer like any other really.

[mccrabney]

Originally Posted by TonE

For what is Megababy useful for? Any precise examples?

it's mostly used to make me wish there was better hardware integration for it

[_Stevie_]

Do we have a tag for $totalfiles?
This would be super useful when rendering multiple files to create something like: Render 1 of 9, Render 2 of 9, etc...