v7.16+dev0601 - June 1 2024

[bolgwrad]

v7.16+dev0601 - June 1 2024

* Includes feature branch: up to 4 different click types/samples in metronome
* Includes feature branch: render setting to preserve source media sample rate if possible
* Includes feature branch: RGB profile tweak
* Includes feature branch: improved UI for editing click pattern in metronome, time signature markers, and click source properties
* Includes feature branch: improvements to grid spacing and labeling with compound time signatures
* Includes feature branch: improved loudness peaks
* Includes feature branch: global preference to crossfade left, center, or right when splitting
* Includes feature branch: optionally display mouse position indicator line in arrange view
* Includes feature branch: changes to lane recording settings and behavior
* Includes feature branch: up-rank/down-rank takes and take markers
* Includes feature branch: additional localization options
* Includes feature branch: extended ASCII encoding for .wav file text metadata
+ Lanes: ignore setting to automatically remove empty lanes when displaying only one lane [p=2786394]
+ Metronome: support 3 over 2, 3 over 4 triplets (click the + buttons below the grid to set)
# Metronome: improve playback when project playrate is not 1.0

Full Changelog - Pre-Releases - Feature Requests - Generated by WhatsNew2

[Daodan]

Originally Posted by bolgwrad

v7.16+dev0601 - June 1 2024
* Includes feature branch: improvements to grid spacing and labeling with compound time signatures

Would be great to also reset grid at time signature markers. Like in this example at current zoom level there is ruler units every 4 bar (1.1 - 5.1-9.1-13.1-...) but there is 2/4 measure and then 4/4. From that point ruler units not aligned with actual song structure and it's a little bit confusing. Would be great to show them aligned (in this example at 7.1 instead 9.1, 11.1 instead 13.1 and so on)

I hope I described it clearly. I saw someone on the forum describe this better than me, but I can’t find the post.

[amagalma]

Originally Posted by bolgwrad

v7.16+dev0601 - June 1 2024
# Metronome: improve playback when project playrate is not 1.0

Works great now! Thank you so much!

[ferropop]

Originally Posted by Daodan

Would be great to also reset grid at time signature markers. Like in this example at current zoom level there is ruler units every 4 bar (1.1 - 5.1-9.1-13.1-...) but there is 2/4 measure and then 4/4. From that point ruler units not aligned with actual song structure and it's a little bit confusing. Would be great to show them aligned (in this example at 7.1 instead 9.1, 11.1 instead 13.1 and so on)

I hope I described it clearly. I saw someone on the forum describe this better than me, but I can’t find the post.

This exact same issue with "Divide Arrange View Vertically every x Measures".

The moment you introduce an uneven bar, the tinting is thrown off for the rest of the project. Not only is this inconvenient but I'd go as far as saying disruptive. We rely on the tinting for making accurate Razor Edits for example, and having the tinting be off like this really screws things up visually. Trying to accurately eyeball "Half of the verse" is now an eyestrain or a literal manual process with fingers up against the screen to count bars. Not great when you could just quickly swipe the tinted area and know with confidence it's x bars.

Have proposed a few fixes, such as resetting at beginnings of Regions or a marker named "#RESET" etc. Please consider!

https://forum.cockos.com/showthread.php?t=287349

[schwa]

A "reset grid" checkbox in the tempo/time signature marker dialog seems like it would do the trick.

[Edison]

Render to File window. See Gif.

This problem does not happen in the Batch File/Item Converter window

[ferropop]

Originally Posted by schwa

A "reset grid" checkbox in the tempo/time signature marker dialog seems like it would do the trick.

This would be amazing and cover many bases!

[smandrap]

Thanks for the updates.

When setting 3 over 4 metronome grid (and also any triplet grid in general) i get the "percentage" part with 4 digits. It's precise yeah, but i find it a little distracting.

Also notice how when i switch the grid to beats minimal, it doesn't show any mark at all for triplets



And... i renew my proposal for a linear beats grid timebase

[schwa]

Originally Posted by smandrap

When setting 3 over 4 metronome grid (and also any triplet grid in general) i get the "percentage" part with 4 digits. It's precise yeah, but i find it a little distracting.

This is with the grid set to follow the metronome, right?

[smandrap]

Yes, but I get the same with 1/4T grid in grid settings

[schwa]

Originally Posted by smandrap

Also notice how when i switch the grid to beats minimal, it doesn't show any mark at all for triplets

Beats (minimal) means that only whole beats are marked, so it seems correct that triplets would not be marked.

[smandrap]

Originally Posted by schwa

Beats (minimal) means that only whole beats are marked, so it seems correct that triplets would not be marked.

You're (obviously) right sorry for that.

[pentecost]

I think the handling of triplets is really elegant here, but it looks to carry over a pain point (IMO) from the original metronome:
no mechanism to accent the first beat of each tuplet.
In 4/4 with tripleted 8ths, I'd really hope to achieve an AccBccBccBcc arrangement.
Otherwise, this retooling of the metronome is more than I'd ever hoped for! Might put me off custom midi click tracks entirely.

[denmla]

Just want to say that I went back to 714+dev0413 as new UI redrawing etc. is not working well here (win 10 X64).

MIDI editor is laggy in a way like in 90s PCs and worse, MIdiQuest 10 is totally unusable - I need to wait few seconds for thing to move.

Reverted back to 7.14 dev 413 and all is smooth as butter again..

Thanks

[benmiller]

Originally Posted by bolgwrad

v7.16+dev0601 - June 1 2024

* Includes feature branch: changes to lane recording settings and behavior

this is great, with lanes collapesed, don't add lanes, and trim existing media it's the behaviour i've been hoping for.

hope this makes it into to a release!

[Kabraxis]

Originally Posted by bolgwrad

* Includes feature branch: optionally display mouse position indicator line in arrange view

Such neat idea! Is there a reason we can't have this for Piano Roll as well?

[mozart999uk]

Originally Posted by Kabraxis

Such neat idea! Is there a reason we can't have this for Piano Roll as well?

That would be great!

[thommazk]

Originally Posted by denmla

Just want to say that I went back to 714+dev0413 as new UI redrawing etc. is not working well here (win 10 X64).

MIDI editor is laggy in a way like in 90s PCs and worse, MIdiQuest 10 is totally unusable - I need to wait few seconds for thing to move.

Reverted back to 7.14 dev 413 and all is smooth as butter again..

Thanks

I have a similar issue but had to roll back to +dev0509.

https://i.imgur.com/T17mIRt.gif [7.16rc1] vs https://i.imgur.com/hZW4ShC.gif [v7.15+dev0509]

https://i.imgur.com/oKJTX6h.gif [7.16rc1] vs https://i.imgur.com/sId3bf9.gif [v7.15+dev0509]

[Skap]

Originally Posted by Kabraxis

Such neat idea! Is there a reason we can't have this for Piano Roll as well?

I agree, it would be great. Curiously, and on a similar note, during the past couple of weeks I’ve been thinking/dreaming of some sort of note preview indicator in the piano roll. When hovering over this area with the mouse cursor, it would be great if a ghost preview would light up and indicate where the note would be placed if clicking. Not just the start of the note, but the whole note according to the current set note length. And already snapped if snap to grid enabled. I have a feeling that this would make the experience more intuitive.

[Vagelis]

Originally Posted by Kabraxis

Such neat idea! Is there a reason we can't have this for Piano Roll as well?

Also it's missing an option to follow grid settings.

[ferropop]

Originally Posted by Kabraxis

Such neat idea! Is there a reason we can't have this for Piano Roll as well?

Maybe this was brought up before... it still feels weird when Snap to Grid is on but the indicator doesn't snap.

I guess the trouble is "when should it snap and when shouldn't it?".

My 2cents :

1. if Snap to Grid is on, snap indicator line to grid
2. if Snap to Grid is on, but Shift is being held, do not snap indicator to grid
3. if Snap to Grid is off, do not snap indicator to grid


I chose Shift here because it's most often associated with "off the grid" actions. Maybe this can be optionally chosen?

[amagalma]

I tested against the official version, so I am not sure if the following broke in this or in a previous pre-release:

Click source items do not sound correct out of their loop boundaries, unless the item has the Loop Source checked.
Test project here: https://stash.reaper.fm/48704/Proble...k%20source.rpp

[Daodan]

Originally Posted by ferropop

I chose Shift here because it's most often associated with "off the grid" actions. Maybe this can be optionally chosen?

Yes, but by default shift+click extend time selection and that snaps to grid if snap enabled. And ctrl+click moves cursor and ignores snapping but ctrl+drag creates MIDI item and it follows snapping. So should indicator snap when ctrl pressed or not?

So the problem is that different modifiers can be associated with "off the grid" actions (and that's by default). More of that indicator should know somehow what you gonna do click or drag, because one can follow and another ignore snap.

What about:
3. if Snap to Grid is off, do not snap indicator to grid
1. if Snap to Grid is on, snap indicator line to grid
2. if Snap to Grid is on, but any mouse modifier is being held, snap indicator to grid and show second indicator at the same time (bit different visually) that do not snap to grid.

?

[schwa]

Originally Posted by amagalma

I tested against the official version, so I am not sure if the following broke in this or in a previous pre-release:

Click source items do not sound correct out of their loop boundaries, unless the item has the Loop Source checked.

Fixing, but wondering if we should change this so click source items with "follows project tempo" disabled don't return samples outside of the source bounds if unlooped, just like all other media items.

[amagalma]

Yes, I think this would make it more consistent. But please, make the action for inserting a click source item, to make the item loop by default.

[smandrap]

Will the metronome grid be supported in the Midi editor?

[User41]

Originally Posted by Skap

I agree, it would be great. Curiously, and on a similar note, during the past couple of weeks I’ve been thinking/dreaming of some sort of note preview indicator in the piano roll. When hovering over this area with the mouse cursor, it would be great if a ghost preview would light up and indicate where the note would be placed if clicking. Not just the start of the note, but the whole note according to the current set note length. And already snapped if snap to grid enabled. I have a feeling that this would make the experience more intuitive.

That would be an awesome feature and I think easy to implement.

[Vagelis]

Originally Posted by Daodan

What about:
3. if Snap to Grid is off, do not snap indicator to grid
1. if Snap to Grid is on, snap indicator line to grid
2. if Snap to Grid is on, but any mouse modifier is being held, snap indicator to grid and show second indicator at the same time (bit different visually) that do not snap to grid.

?

I proposed a couple of times a simple and logical way just to be ignored...
It's pretty simple, just follow the grid settings except when a mouse modifier is held that does not snap to grid, then bypass the grid settings.

This would look a lot better I think with snap to grid at any distance disabled because of the smoother transition between gridlines, but it won't look bad either with this setting enabled. The important thing is to know where the edit is going to happen.

[ferropop]

Originally Posted by Vagelis

I proposed a couple of times a simple and logical way just to be ignored...
It's pretty simple, just follow the grid settings except when a mouse modifier is held that does not snap to grid, then bypass the grid settings.

This would look a lot better I think with snap to grid at any distance disabled because of the smoother transition between gridlines, but it won't look bad either with this setting enabled. The important thing is to know where the edit is going to happen.

It's just that no single modifier is consistently "off the grid", especially given that we can customize everything.

I can get behind "if Any modifier is being held, don't snap indicator". Seems like a reasonable catch-all option that helps those who want it tremendously and leaving others unaffected.

[odedd]

The metronome changes are very welcome!

I think that while it is being redone - I have two requests -

1. adding "regular" subdivisions (8ths/16ths - not just triplets) would be a good idea.

Ideally, a 4/4 bar with a metronome of 8ths should be something like:

Acbcbcbc
or at least
Abbbbbbb

but currently, by setting the BPM basis to 1/2, I can only get AbbbAbbb (or AbcdAbcd) per bar - that is the same pattern twice, which does not give a sense of where the first beat of the bar lands.

The only way of achieving that would be to call it a 8/8 bar, but that is not really the case musically, sometimes it's a 4/4 bar, but I want musicians to listen to a subdivision - this is easier to follow when there are lots of gradual tempo changes.

2. Since there's now an option for a gradual change (yay!) some kind of way of curve ease editing would be great (alt+drag, a-la fade and automation curves).

[schwa]

If you set the metronome to 2x, the pattern length doubles, so you would have an 8-beat non repeating pattern in 4/4, for example.

[odedd]

Originally Posted by schwa

If you set the metronome to 2x, the pattern length doubles, so you would have an 8-beat non repeating pattern in 4/4, for example.

That's awesome. Thanks!
Maybe this could be enabled on a per tempo-change basis though?
(so not only at the main metronome settings window, but on the tempo/meter change menu as well?)

[Vagelis]

Originally Posted by ferropop

It's just that no single modifier is consistently "off the grid", especially given that we can customize everything.

I can get behind "if Any modifier is being held, don't snap indicator". Seems like a reasonable catch-all option that helps those who want it tremendously and leaving others unaffected.

I think the basic modifiers that could work with no snap indicator are:
The selection modifiers (RE,TS), in both item and track contexts
The draw item modifiers in track context
The new split item modifier in left click item context
When creating comp areas.

It would be very useful for editing and comping

[Edison]

Originally Posted by Edison

Render to File window. See Gif.

This problem does not happen in the Batch File/Item Converter window

@Devs

Thanks for fixing!

[schwa]

Originally Posted by ferropop

It's just that no single modifier is consistently "off the grid", especially given that we can customize everything.

That is the issue, yes. There is no way for REAPER to know what the user is about to do: click with the mouse, drag with the mouse, right-click, press a shortcut key, etc. If the mouse is over an object, like an envelope point or a media item, clicking will grab the object under the unsnapped mouse location regardless of snap settings, but running an action might respect snap or might not depending on the action.

What we maybe could do is indicate *both* the snapped and unsnapped locations, if the toolbar snap button is enabled.

[ferropop]

Originally Posted by schwa

That is the issue, yes. There is no way for REAPER to know what the user is about to do: click with the mouse, drag with the mouse, right-click, press a shortcut key, etc. If the mouse is over an object, like an envelope point or a media item, clicking will grab the object under the unsnapped mouse location regardless of snap settings, but running an action might respect snap or might not depending on the action.

What we maybe could do is indicate *both* the snapped and unsnapped locations, if the toolbar snap button is enabled.

That might also mitigate some hitpoint grievances, indicating whether you're snapping left or right if you were to click at an ambiguous position near the center.

[Vagelis]

Originally Posted by schwa

That is the issue, yes. There is no way for REAPER to know what the user is about to do: click with the mouse, drag with the mouse, right-click, press a shortcut key, etc. If the mouse is over an object, like an envelope point or a media item, clicking will grab the object under the unsnapped mouse location regardless of snap settings, but running an action might respect snap or might not depending on the action.

What we maybe could do is indicate *both* the snapped and unsnapped locations, if the toolbar snap button is enabled.

Schwa, imo using actions for modifiers should not be considered to work with the indicator because it's something customizable. However the native modifiers should be prioritized, like the ones I 've posted above. It would make a lot of sense to work with the indicator while holding the modifier and BEFORE clicking.

For example: let's say the indicator follows always the grid, if i press the split without snap modifier BEFORE clicking anywhere, e.g shift, then moving the mouse it should not snap on grid. After I click it doesn't matter because the indication disappears.
The same idea could apply with all modifiers I've mentioned previously, like the selection, draw, comp modifiers. The indicator could change while holding the modifier and moving the mouse before clicking anywhere. I don't want to say it, but that's how it works in daws that support this.

EDIT: I see what you meant, like what happens when we use the same modifier for click and drag. That's an issue indeed, bummer..

Maybe this could be solved if we could choose to show the indicator per modifier somehow.

[schwa]

Originally Posted by Vagelis

EDIT: I see what you meant, like what happens when we use the same modifier for click and drag. That's an issue indeed, bummer.

And also the user might not be about to click or drag at all, but instead run an action that might or might not respect snapping. It's not about customization, it's about not being able to predict the future.

The next build will optionally highlight the snapped-to grid line in addition to the unsnapped mouse indicator, we'll see if that helps.

[Vagelis]

I think actions no need to be taken into account imo since they are not mouse modifiers, might be wrong though.

But thanks for looking at it good sir!