Insert empty space moving later items not working with measure changes

[_Stevie_]

Hey devs,

the action "Time selection: Insert empty space at time selection (moving later items)"
doesn't seem to working nicely with measure changes. I guess the reason is, that it's regarding the time selection as time without taking beats into account.

Before inserting space:



After inserting space:



The result is:

- the moved item(s) don't start on the measure anymore
- a second 2/4 measure is inserted at bar 4, but the 4/4 from the project start should be retained

[_Stevie_]

This seems to be connected with a setting in the project, but I have no idea which one could cause this. I'm attaching the minimal project RPP:
https://stash.reaper.fm/v/46916/inse...ence_issue.RPP

steps to repro:

- simply execute "Time selection: Insert empty space at time selection (moving later items)"

My bad, used a different measure pattern when re-creating it manually and got a different result.

Bottom line is: it's always happening and there is no setting in the project that causes this.

[sockmonkey72]

I get the same behavior in a new project created w/ ignore default template (same with a portable install):



I don't know what the objectively correct behavior is here, but that result is definitely not it. Probably this is what I'd expect to see:

[schwa]

Originally Posted by _Stevie_

- a second 2/4 measure is inserted at bar 4, but the 4/4 from the project start should be retained

After inserting time, bar 4 is only 2 quarter notes long.

REAPER adds a 2/4 time signature marker in order to prevent a partial measure. If you delete that added
time signature marker, everything remains the same (and is probably visually what you expect), but the
project then contains a 4/4 measure that is only 2 quarter notes long. The * displayed with the remaining
2/4 time signature marker indicates that the previous measure is incomplete.

[_Stevie_]

Hey schwa,

thanks for chiming in! Yeah, I can see your point.
However there is another issue, which I cannot find a logical explanation for.

This is the starting point:


And this is the result:


The tempo changed, although, all meters are at 120 bpm, plus, the tempo at the beginning of the project changed from 120 to 109.714.

Here's the minimal project:
https://stash.reaper.fm/v/46921/temp...e%20change.rpp

[schwa]

That happens because of the 7/8 measure. The action inserts 8 1/4 notes plus 7 1/8 notes
= 23 1/8 notes. If the time signature throughout is 4/4 then the tempo has to change.
The only other real option would be to insert a marker somewhere within the inserted
time to rationalize the time signature by creating an x/8 measure, but that would require
some fuzzy logic and would be unlikely to give a more predictable result in most cases
anyway.

[sockmonkey72]

Originally Posted by schwa

That happens because of the 7/8 measure. The action inserts 8 1/4 notes
plus 7 1/8 notes = 23 1/8 notes. If the time signature throughout is 4/4
then the tempo has to change. The only other real option would be to
insert a marker somewhere within the inserted time to rationalize the
time signature by creating an x/8 measure, but that would require some
fuzzy logic and would be unlikely to give a more predictable result in
most cases anyway.

I guess the disconnect is that there are two (main) use cases: inserting wall time vs inserting musical time. This action is doing the former, with all of the potential musical side effects (the tempo change inserted at the top of the beginning of the project is going to affect playback of meter-based media, no?).

It would be enormously helpful to have support for the latter (quantizing the TimeSel to a beat grid and duplicating the metrical changes before pushing the content (and meter changes) forward in [musical] time).

[schwa]

You could create a region from the time selection and ctrl+drag that region to copy it immediately after itself, then delete the original media.

[Klangfarben]

Schwa, honestly that is a terrible solution. First, we all know that creating a region and duplicating it does not respect locked items. So what your solution is doing is creating shrapnel and forcing a LOT of clean-up on the user's part. Secondly, not only does that solution create a lot of extra work on the user's part, but it cannot be scripted. So in a large project or when doing conforms, you are literally creating chaos that a scripter much more clever than myself cannot clean up.

THAT is your solution?? Come on, man...

If the user is in bars/beats and not time, there either needs to be a native action that is inserting bars, not time that will respect what should be happening *musically*, not mathematically or the current action needs to be changed. In the case of Stevie's example, there are several issues. Here is what it should be doing.

1) The tempo at measure 1 needs to stay the same - 120 bpm
2) Measure 1 should not be truncated. The selection does not truncate, so neither should the result as that is most definitely not the intention of the user.
3) The insertion of the selection should be starting on the old measure 2. The user clearly intended for the selection to start on the measure, therefore the insertion should also start on the measure. Again, anything else will not be the intention of the user.
4) Regarding Stevie and Sockmonkey's first example, Reaper should NEVER be adding consecutive meters that are the same. There should never be a 2/4 measure followed by ANOTHER 2/4 measure. That is simply an error and not musically correct. You would never see a meter change followed by the SAME meter change in the next measure in a score ever. So logic dictates you should never see that in the insertion process.

Now this simply may be a result of the fact the native action is inserting time, not bars/beats. But what is very important here is the user's intention which is to insert bars/beats and follow basic music principles. Reaper's native action is most definitely NOT doing that as both Stevie and Sockmonkey have pointed out. If the result of the native action is never going to match the intention of the user, then the action has a pretty serious problem that needs to be rectified. OR a native action that inserts bars/beats vs time (and acts more similar to regions) and follows basic music principles should be added.

[sockmonkey72]

Originally Posted by schwa

You could create a region from the time selection and ctrl+drag that region to copy it immediately after itself, then delete the original media.

If that were scriptable, that would be a potential workaround/hack, and I appreciate the suggestion.

However, the suggestion skirts the underlying conceptual problem that I wouldn't be using the measures.beats ruler and/or an item Beats timebase if my intention were to insert wall time.

I've checked similar functionality in a number of other DAWs and they all support beats-based time insertion with TS preservation (with varying degrees of success, to be perfectly honest), at least as an option.

I think that inserting wall time is a perfectly valid use case, but for users making any kind of pulse-based music along a measures/beats ruler (many?), inserting wall time is always musically incorrect, and will break stuff in the presence of tempo or time signature changes.

[_Stevie_]

There are various reasons, why the region approach won't work for me.

1. I have a locked timecode generator item in my project -> moving a region splits it
2. I have to do some MIDI house cleaning before inserting time (deleting trailing notes that were created by splitting, moving CCs back to item start, when a CC gap was created by splitting)
3. I need to be able to adjust my project start time, in conjunction with inserting time.

All these things happen automatically in my custom script, which is build around the action 40200 (insert space). So a mouse drag feature won't work here.


Let me briefly showcase what side effects I experienced in the last days with the behavior of "insert space". I can't recall what the exact order of events was, but this is the result of insert space: (picking up sockmonkeys' "break stuff" comment here)

These item starts used to sit on the grid, they got completely lost:




The other side effect was that item ends got completely messed up:

[schwa]

Originally Posted by Klangfarben

THAT is your solution?? Come on, man...

99% of the time I don't care when users are rude but occasionally it gets under my skin. I am never, ever rude to users. This is a good faith conversation, would you talk that way irl to somebody who was trying to understand and help?

[nofish]

Alternatively js' Insert empty beats script perhaps?

(I know this is in bug reports, I'm not argueing pro/con it...)

[_Stevie_]

Originally Posted by nofish

Alternatively js' Insert empty beats script perhaps?

(I know this is in bug reports, I'm not argueing pro/con it...)

That script actually does pretty much what I want. However, it's that complex that I have a hard time weaving my extras into it. I guess, it will take me days to get myself into Julian's mindset.

[Klangfarben]

Originally Posted by schwa

99% of the time I don't care when users are rude but occasionally it gets under my skin. I am never, ever rude to users. This is a good faith conversation, would you talk that way irl to somebody who was trying to understand and help?

Schwa, I wasn't being disrespectful or rude. I was expressing shock and/or disbelief that you considered your suggestion a legitimate solution. And then took the time to try and explain exactly WHY that was not a legitimate solution. There is a large difference there. And yes, I absolutely would talk to that someone that way sitting across the table from them having this discussion, even you. Saying come on man is not rude, nor was it intended to be and I'm very sorry you took it that way and will attempt to be a little less... direct with you in the future.

You are an extremely bright person, Schwa. So you obviously know that something can be two things at once. It can be mathematically correct. AND it can be completely musically incorrect which is the case here. So take a second and think about what the user is expecting. If the user is in bars/beats they are expecting it to be musically correct. They need to export that midi to other people. They need to put it on paper for other musicians to read. They have to play it back and get approval based on what it is doing musically.

Sockmonkey brings up a very good point which is, if someone is working in bars/beats they aren't concerned with wall time. I would go even further than that. If you are inserting time while in bars/beats it is specifically because you do not want to preserve the current timeline. If you are conforming to new video for instance, the old sync does not apply anymore, so you are inserting time to match new sync. And in the process have to do that musically as anything else results in a cue that can't be turned in - or put in front of musicians to play.

I'm happy to send you a large midi-only project so you can see the carnage that is created by taking your suggestion. Perhaps that will help you understand my incredulousness at your response and maybe understand the use case a little better, since all media composers are going to have the same use case here. The bottom line is if the action does not have the intended result for all users working in bars/beats then from a user standpoint, it is hard to consider it anything other than a bug.

[nofish]

I think part of the issue or confusion is the naming of this action, "Insert empty space...", if it would be named "Insert time..." (or wall time, as mentioned by sockmonkey) it would be clearer imo.

And then ideally an additional one "Insert empty beats...".

[schwa]

We're thinking the same action could work as it does now if the project setting for the tempo envelope timebase is in time, and duplicate any existing tempo/time signature changes if the timebase is in beats.

[_Stevie_]

Originally Posted by schwa

We're thinking the same action could work as it does now if the project setting for the tempo envelope timebase is in time, and duplicate any existing tempo/time signature changes if the timebase is in beats.

THIS would be awesome, schwa!

And it would make adjusting my custom script so much easier than diving into Julian's.

[sockmonkey72]

Originally Posted by schwa

We're thinking the same action could work as it does now if the project setting for the tempo envelope timebase is in time, and duplicate any existing tempo/time signature changes if the timebase is in beats.

[dangguidan]

In Reaper, I have found patterns that are not prone to errors in the various operations of the beat. I need to plan in advance and never let the beat appear in the middle of the measure, Otherwise, it will cause the time and tempo to be misaligned.