Cockos Incorporated Forums

Cockos Incorporated Forums (https://forum.cockos.com/index.php)
-   REAPER Pre-Release Discussion (https://forum.cockos.com/forumdisplay.php?f=37)
-   -   Tempo / time signature bugs consolidated thread (https://forum.cockos.com/showthread.php?t=152914)

maxdis 01-01-2015 06:07 AM

Tempo / time signature bugs consolidated thread
 
1 Attachment(s)
Please, let's post in this thread all the bug reports regarding tempo and time signatures, so that devs (hopefully during the 5 cycle) will can fix this longstanding issue.
Important: attach an image demonstrating the bug, and also the relative .RPP file.

My first report:

http://www.acustronica.com/tempobug.gif

Bug: As you can see, if I move Region 2 (with the 7/8 time signature) and then I bring it back in its original position, two not needed time signature marker are created after the region, and the item in Region 2 is warped (if I set the item timebase to "Time", the item is not warped, but the not needed time signature markers are still there).
The problem is much worser when there are other items or regions after the region you're moving, because these will be affected in unpredictable ways, and often you'll notice that only after hours/days of workin on the project.

Expected behaviour: Time signature marker shouldn't be created if I'm bringing back the region to its original position; also, the item shouldn't be warped.


attached project:

G-Sun 01-01-2015 06:34 AM

You can't expect moving the region back to original position will get everything back to original state.
Only undo can be expected to work like that.

I agree the 6/8 time-sig is puzzling,
and the warp should not be created.

And I can confirm odd behaviour for these matters,
so thanks for bringing it up :)

EvilDragon 01-01-2015 06:57 AM

Quote:

Originally Posted by G-Sun (Post 1451633)
You can't expect moving the region back to original position will get everything back to original state.
Only undo can be expected to work like that.

So how come Cubase or S1 doesn't have any problems with things like this?

Evan 01-01-2015 07:44 AM

Allow me to add two useful timeline/tempo FRs:

(1) Fixed-spacing grid, irrespective of tempo

http://forum.cockos.com/project.php?issueid=2502


(2) Toggle follow/unfollow tempo map

http://forum.cockos.com/project.php?issueid=2385


Would be fantastic to have in R5 final, along with the bugfixes mentioned here.

jaydrake 01-01-2015 07:58 AM

With complex tempo mapping I frequently get "double" clicks (the attached gif in this thread shows the click source).

http://forum.cockos.com/showthread.php?t=141146

maxdis 01-01-2015 09:04 AM

Quote:

Originally Posted by G-Sun (Post 1451633)
You can't expect moving the region back to original position will get everything back to original state.

Actually I'm expecting exactly that, because I'm not changing anything

Quote:

And I can confirm odd behaviour for these matters,
so thanks for bringing it up :)
You're welcome :-)

xpander 01-01-2015 09:53 AM

Maxdis, I'm not getting quite the same behavior here. I can see the leftover time sig and tempo marker, but the item moved with the region behaves differently depending if you have regions 1&2 overlapping like they are in your project and how far they are moved back and forth.

maxdis 01-01-2015 10:08 AM

Do you mean region 3&2 ? (there's no region 1 in my project). But I'm not sure I understand what you mean by overlapping...
Yes, the item don't always is warped, depending where you move the region on, but in my opinion it never should be warped, regardless where you put in on.

Quote:

Originally Posted by xpander (Post 1451685)
Maxdis, I'm not getting quite the same behavior here. I can see the leftover time sig and tempo marker, but the item moved with the region behaves differently depending if you have regions 1&2 overlapping like they are in your project and how far they are moved back and forth.


xpander 01-01-2015 10:13 AM

Quote:

Originally Posted by maxdis (Post 1451691)
Do you mean region 3&2 ? (there's no region 1 in my project). But I'm not sure I understand what you mean by overlapping...

I mean the regions 1 and 2 which are overlapping in your project, R2 on top. This may or may not cause unnecessary confusion and misbehavior already. The leftover markers are there nevertheless, you're right about that.

maxdis 01-01-2015 10:29 AM

You're right, there is a region 1 under region 2, I forgot about that (btw, this is another area that needs some work by devs, ie make overlapping regions more clearly visible). But deleting region 1 does nothing to fix the problem, that is exactly as before.

Quote:

Originally Posted by xpander (Post 1451693)
I mean the regions 1 and 2 which are overlapping in your project, R2 on top. This may or may not cause unnecessary confusion and misbehavior already. The leftover markers are there nevertheless, you're right about that.


FnA 01-01-2015 11:06 AM

My feeling is that much of the confusion and frustration that gets labeled as "bug" or "broken" is because of "inferior design." Love my Reaper mind you.

1. Time timebase MIDI items. Pretty heavily discussed. Agreed upon by most/all as "bad." Exactly what has to happen to Reapers guts to fix it, I don't know. There's been several threads. Poofox's Bug Report and discussion thread is probably the hub of the matter.

2. Beats timebases themselves. This has received little technical attention. The definition in the help menu is incorrect. "Project elements will keep their position and length constant as measured in BEATS." No. It's determined by MEASURES and beats. This is why complaints arise about items getting shorter etc. Problem is not limited to MIDI items but it is very inconsistent with MIDI data contained within a single item. Simple example-

http://forum.cockos.com/attachment.p...1&d=1420134365

Everything was identical on either side of the Time Signature change before it was effected. Notice CCs in item versus (ReaControlMIDI) track envelope. There's other inconsistencies. Moving and copying things versus applying a time change among them. For example I could have cut the track in the pic, applied the time change, and pasted it back. It would have saved the item and envelope, but not the marker positions.

Of course, there is other complications. Like, "Remove contents of time selection" and "Insert empty space at time selection" could cause very odd fractions of beats to be introduced. But that seems like a detail, not the root of the problem. I also don't mean to say that what I write here covers everything.

xpander 01-01-2015 11:50 AM

Quote:

Originally Posted by maxdis (Post 1451699)
But deleting region 1 does nothing to fix the problem, that is exactly as before.

Yep, the extra time signature/tempo markers are still created after the region moves. There even seems to be a certain logic to it. They are added to the points where the moved region ended after the move. If there already was a (different) time signature marker at the end of the last region before the move, after the region move back and forth that time signature marker is still there and correct. Then only the last tempo marker is extra.

In your example project the 1st time signature after the moves is not only unnecessary, it also has incorrect value. It should be 85-7/8, but is instead the same what is valid before that region (85 - 6/8).

Yes, there's item misbehavior too, but there are other unnecessary(?) time sig markers in there also, so maybe the project had already been affected by move edits before? I tested this with a fresh project, only one item/region and two (later on three) time signature/tempo changes to get just the basic misbehavior without added complications.

maxdis 01-02-2015 05:27 AM

Quote:

Originally Posted by xpander (Post 1451724)
Yes, there's item misbehavior too, but there are other unnecessary(?) time sig markers in there also, so maybe the project had already been affected by move edits before?

Not much really, I created this project and after 1-2 minutes I came up with the bug; maybe there were some other time signatures added (althought I can't find them), but I don't think they would be affecting too much this issue.
But you're right that it seems that Reaper is "corrupting" every project, adding unnecessary time sig markers each time you move something. I'm not a programmer, but I feel that Reaper should "recalculate from scratch" (I can't come up with a better term) the item positions and time sigs with every move, instead of adding markers and unnecessary data every time.

xpander 01-02-2015 11:59 AM

Quote:

Originally Posted by maxdis (Post 1452039)
Not much really, I created this project and after 1-2 minutes I came up with the bug; maybe there were some other time signatures added (althought I can't find them), but I don't think they would be affecting too much this issue.

Yes, the basic misbehavior is still there but it might be a bit harder to see what is going on. For example when removing the "unnecessary" time signature from the bar 5 before the region moves, there will still be extra time sigs after the last region but with different values. Worth noting here is that what your example really shows is how time signatures (and items) are affected by region moves. Moving just separate items or even the time signature markers around is another deal.

---
Test pt.I, moving a region forward and back on timeline, one time signature change, ripple editing off.

For a simplest possible test I created a new project with one track and one region, no items. The start of the region has a tempo/time signature marker with different values than the beginning of the project has. After moving this empty region around, I noticed this behavior:
  • When the region is moved later in the timeline, the original position of the region keeps the same time signature the region has (a new tempo/time signature marker is added to the original position). It may be debatable if this is correct behavior? Users may want to keep the time signature that specific position had or they may want it to adopt the previous valid time signature? In latter case the added time signature marker is unnecessary.
    Also, the moved region will lose its time signature reading, the marker showing only the tempo. Since the the original region position still has the tempo/time signature marker and there are no further time signature changes in the project, this marker is unnecessary. Exception: may be good to preserve as the region may be considered as its own whole "entity" within the project, for as long as the region exists at least?

    An extra tempo marker is also created right after the region. This is unnecessary since it only repeats what is already defined by earlier markers.

  • When the region is moved back to the original position, two extra markers are left behind the region. The original tempo/time signature marker inside the region shows only the tempo (just like after the first move). Yet the measure within the region is still in correct time signature. The first extra time signature marker after the region now has the same values the region had. Meaning, also the time signature, not just the tempo. This marker is still unnecessary since the earlier one (inside the region) should already define the later part of the project until the next possible (different) time signature. However, if this extra marker is removed, also the area within the region will lose the time signature it had and only keep the tempo...the only thing what was showing there after the move anyway.

TL/DR; Two extra tempo/time signature markers were created after the region moves. Region itself lost its time signature reading during the moves, only keeping the tempo marker. Screencapture below shows all that is described above.

https://i.imgur.com/ZZqFwAa.gif

xpander 01-02-2015 12:19 PM

Ok, here's the second one.

Test pt.II, moving a region earlier and back on timeline, one time signature change.

https://i.imgur.com/8BpUtyQ.gif

---
edit: Regions with items and moves with ripple editing show the same behavior as in these two screencaps with empty regions and no ripple. Maybe another thing with added time signature changes after the region? Also, what happens to the items during these moves may deserve further study. Somebody?


OK. The region move earlier on timeline moves the tempo/time signature marker correctly with it. Measure 4 which used to be 4/4 120 is still so with the help of the added time sig marker. Measure 5 (now empty) is affected by the same marker. Measure 6 has now a new tempo/time signature marker, same values as the region had before the move, so nothing changed for the measure itself. As far as keeping everything in project as it were, apart from the actual region move, I see this as correct.

When the region is moved back to the original position, couple of odd things happen though. A redundant tempo/time signature marker is left where the region was...it has the same values as the start of the project already has. Also, the tempo/time signature marker at measure 6 is changed to different values, tempo still the same but time sig now from earlier part, not what would be defined by the region (with its marker) nor what was valid before the moves.

Further thoughts, notes?

EvilDragon 01-04-2015 12:41 AM

Seems like pre3 brings some fixes to these issues. Test out, people.

DarkStar 01-04-2015 02:24 AM

In a JS FX, if the number of beats in a bar changes anywhere in a song, then I cannot tell what bar I'm in.

http://forum.cockos.com/project.php?issueid=4287

maxdis 01-04-2015 04:49 AM

Quote:

Originally Posted by EvilDragon (Post 1453086)
Seems like pre3 brings some fixes to these issues. Test out, people.

that sounds interesting, I can't test just now, but I'll do as soon as possible

Quote:

Originally Posted by xpander
Further thoughts, notes?

Xpander, I'll check you reports too in pre3, thank you for your contribute

G-Sun 01-04-2015 08:26 AM

Quote:

Originally Posted by EvilDragon (Post 1453086)
Seems like pre3 brings some fixes to these issues. Test out, people.

No change regarding this as far as I can see

xpander 01-04-2015 10:09 AM

v5pre3
 
Different behavior now, but not necessarily all to better, afaic. One big change I see is how the time signature changes affect the regions and items inside.

Earlier: Make a region for one measure. Insert a new time signature marker to the start of the region. Time signature will affect all the following measures, region keeps the length of one measure.

Now: Make a region for one measure. Insert a new time signature marker to the start of the region. Time signature will affect all the following measures, but region keeps the old length as it was in number of beats, not as one whole measure.

Same applies for the time selection.

Odd time signature changes when moving regions around are still at least partly there, just a bit different now.

maxdis 01-04-2015 12:53 PM

This problem is still there:

http://www.acustronica.com/tempobug5.gif

two unnecessary time markers are created after I move a region and bring it back...(but at least the first of those two markers is correct now).
But the worst thing is that the item in the region is still warped after the move.

maxdis 01-04-2015 12:57 PM

G-Sun, xpander, please post your time bug reports in the pre3 thread, it seems that Justin is reading it.


Quote:

Originally Posted by G-Sun
No change regarding this as far as I can see

Quote:

Originally Posted by xpander (Post 1453289)
Different behavior now, but not necessarily all to better, afaic. One big change I see is how the time signature changes affect the regions and items inside.

Earlier: Make a region for one measure. Insert a new time signature marker to the start of the region. Time signature will affect all the following measures, region keeps the length of one measure.

Now: Make a region for one measure. Insert a new time signature marker to the start of the region. Time signature will affect all the following measures, but region keeps the old length as it was in number of beats, not as one whole measure.

Same applies for the time selection.

Odd time signature changes when moving regions around are still at least partly there, just a bit different now.


xpander 01-05-2015 04:38 AM

Quote:

Originally Posted by maxdis (Post 1453373)
G-Sun, xpander, please post your time bug reports in the pre3 thread, it seems that Justin is reading it.

Afais, Pre3 has a significant change. Now the behavior for the Timebase beats (position, length, rate) is like it has been described in timebase help: Project elements will keep their position and length constant as measured in beats. The earlier discrepancy has been pointed out by many people, eg. FnA earlier in this topic.

What I showed earlier is not exactly what happens now, so for that I'll have to make new tests when I have time. As for the "bugs", I don't even know. I'm describing what I'm seeing and many times just guessing on my part if what is seen is what people really want to happen or not. There are so many options and different ways to work compared to simple things I do, I can only say x or y should not happen from my limited point of view.

I think there has been way more people complaining about Reaper timebase problems than there are actually partaking eg. here. All this is voluntary of course and I'm not pointing fingers. But maybe it's not so easy when you have to actually put things down as exactly as you can while thinking about the whole also, instead of just saying it sucks. :D

maxdis 01-05-2015 05:33 AM

Quote:

Originally Posted by xpander (Post 1453713)

What I showed earlier is not exactly what happens now, so for that I'll have to make new tests when I have time. As for the "bugs", I don't even know. I'm describing what I'm seeing and many times just guessing on my part if what is seen is what people really want to happen or not. There are so many options and different ways to work compared to simple things I do, I can only say x or y should not happen from my limited point of view.

I agree that in some cases it's difficult to tell if it's a bug or "by design" thing, but in some cases (for example warped items, time signature not changing when requested (I'm posting an example very soon)), it's hard for me not calling that a "bug".
Overall, I find the whole timebase concept very confusing: it could be useful for some advanced, specialized thing, but IMHO we shouldn't be supposed to change timebase settings in order to do very basics things like moving regions and changing time signature (and also after changing timebase settings, things will not behave as expected)

Quote:

I think there has been way more people complaining about Reaper timebase problems than there are actually partaking eg. here. All this is voluntary of course and I'm not pointing fingers. But maybe it's not so easy when you have to actually put things down as exactly as you can while thinking about the whole also, instead of just saying it sucks. :D
I totally agree. This is a rather complex issue, and it would be helpful to have more people helping with examples and reports.

maxdis 01-05-2015 06:06 AM

1 Attachment(s)
new test on pre3:

http://www.acustronica.com/tempobug2.gif

As you can see, when I extend the 7/8 signature to 9/8, apparently nothing change, and the third item become warped. I have to add a 2/8 empty space in front of the 5/8 measure to make the 9/8 long as desidered, and also the warped item come back to its original shape.


Things get worse if I try to shorten the 7/8 to 3/8:

http://www.acustronica.com/tempobug3.gif

even in this case nothing moves, and the item become warped; this time I have to use the "Remove content of selection (moving later items)" action to put things right, but now the warped item remains warped

RPP:

G-Sun 01-05-2015 06:21 AM

Quote:

Originally Posted by xpander (Post 1453713)
Afais, Pre3 has a significant change. Now the behavior for the Timebase beats (position, length, rate) is like it has been described in timebase help: Project elements will keep their position and length constant as measured in beats. The earlier discrepancy has been pointed out by many people, eg. FnA earlier in this topic.

afaik, the tempo-marker time-base error was fixed in v4.23.

Now, region move, time-sig new/edit, project crop has bugs.
And it's often not totally clear for me what ideal behaviour should be.

xpander 01-05-2015 10:41 AM

Quote:

Originally Posted by G-Sun (Post 1453753)
afaik, the tempo-marker time-base error was fixed in v4.23.

Have to admit that I missed that one then. What I meant was this:

v4.76
After the time sig change, the elements keep their position and length constant as measured in...measures (bars).
https://i.imgur.com/O8ADY7U.gif

v5pre3
After the time sig change, the elements keep their position and length constant as measured in beats.
https://i.imgur.com/7j8ief0.gif


Quote:

Originally Posted by G-Sun (Post 1453753)
Now, region move, time-sig new/edit, project crop has bugs.
And it's often not totally clear for me what ideal behaviour should be.

Same here.

G-Sun 01-05-2015 01:07 PM

Quote:

Originally Posted by xpander (Post 1453866)
Have to admit that I missed that one then. What I meant was this:

v4.76
After the time sig change, the elements keep their position and length constant as measured in...measures (bars).
https://i.imgur.com/O8ADY7U.gif

v5pre3
After the time sig change, the elements keep their position and length constant as measured in beats.
https://i.imgur.com/7j8ief0.gif

Ok, thanks! Now I see.
Nice improvement :)

FnA 01-07-2015 03:38 PM

Wasn't pointing a finger at your bug maxdis. I felt that the issues I brought up were POSSIBLY "major surgery" items, and should probably be taken care of first. For example, don't you think it would be nice to just insert or start recording an item on a time timebase track (or "default" in time timebase project) and have it behave itself right off the bat? POSSIBLY, these changes, if implemented, might even introduce more bugs that need to be ironed out later. Not sure about specifics.

maxdis 01-08-2015 11:53 AM

Quote:

Originally Posted by FnA (Post 1455013)
Wasn't pointing a finger at your bug maxdis.

no problem at all :-)

Quote:

I felt that the issues I brought up were POSSIBLY "major surgery" items, and should probably be taken care of first. For example, don't you think it would be nice to just insert or start recording an item on a time timebase track (or "default" in time timebase project) and have it behave itself right off the bat? POSSIBLY, these changes, if implemented, might even introduce more bugs that need to be ironed out later. Not sure about specifics.
I agree with you, and I think Timebase issues should addressed and fixed once and for all (BTW, you could consider to post your report above in the v5 pre3 thread, it seems Justin is following it). Actually I think Time Sig problems and Timebase ones are closely related, because many problems I face when working with Time Sigs involve warped items.
Yes, probably it would be "major surgery", possibly also breaking project compatibility, so it should be done ASAP.

G-Sun 01-09-2015 04:37 AM

Some tempo-bugs:

Midi export is not behaving correctly:
Linear transition
from 46.1 100bpm
to 47.1 99,449bpm

becomes this when imported again
https://stash.reaper.fm/22847/Tempo1.png

G-Sun 01-09-2015 04:39 AM

Tempo min/max view does not change for all open tabs

v4.76 x32 win8.1x64

FnA 01-13-2015 03:19 PM

I'm really happy with the change to Beats timebase so far. Not too much time for pre testing unfortunately.

Something else that "bugs" me is the unpredictable behavior and "illegal"
measures (such as 4/4* with 3 quarters) that result when doing things like "Remove contents of time selection" and "Insert empty space at time selection" or working in the tempo envelope. I don't have a clue what to point the finger at there. I think, at least if things are snapped to a reasonable fraction, reaper should keep it legit.

memyselfandus 01-14-2015 08:43 AM

This type of stuff needs to be fixed.

Justin 01-14-2015 02:49 PM

Quote:

Originally Posted by maxdis (Post 1453745)
new test on pre3:

http://www.acustronica.com/tempobug2.gif

As you can see, when I extend the 7/8 signature to 9/8, apparently nothing change, and the third item become warped. I have to add a 2/8 empty space in front of the 5/8 measure to make the 9/8 long as desidered, and also the warped item come back to its original shape.


Things get worse if I try to shorten the 7/8 to 3/8:

http://www.acustronica.com/tempobug3.gif

even in this case nothing moves, and the item become warped; this time I have to use the "Remove content of selection (moving later items)" action to put things right, but now the warped item remains warped

RPP:


Duplicated -- this is because of the media start offset on that item. If you reset it to 0, it will eliminate this problem. I'll see if we can fix this, but the problem isn't specific to changing the timemap -- if you have partial measure (a time signature marker that prematurely ends a measure), it will always mess up MIDI items that have start offsets where the underlying media crosses that boundary.

Justin 01-14-2015 02:55 PM

Quote:

Originally Posted by G-Sun (Post 1455936)
Some tempo-bugs:

Midi export is not behaving correctly:
Linear transition
from 46.1 100bpm
to 47.1 99,449bpm

becomes this when imported again
https://stash.reaper.fm/22847/Tempo1.png

Thanks, fixing!

G-Sun 01-15-2015 12:46 AM

Quote:

Originally Posted by Justin (Post 1459786)
Thanks, fixing!

Thanks a lot!

maxdis 01-15-2015 01:12 PM

Quote:

Originally Posted by Justin (Post 1459780)
Duplicated -- this is because of the media start offset on that item. If you reset it to 0, it will eliminate this problem. I'll see if we can fix this, but the problem isn't specific to changing the timemap -- if you have partial measure (a time signature marker that prematurely ends a measure), it will always mess up MIDI items that have start offsets where the underlying media crosses that boundary.

Thank you for looking into this Justin; actually, I didn't noticed that the item had a media start offset, but I'm 100% sure I never changed it in this project (neither I can remember a single time I did it in my entire Reaper usage life :-)), so I think it happened by itself, after moving items and/or time signatures/regions. I really hope you can fix this.

Regarding the other issue in my report, you can see that when I try to extend/reduce the time signature, apparently nothing changes, and I have to insert/remove space to make the measure as long as desidered, shifting the subsequents items and markers to the correct place. Now, wouldn't it better if, when changing time sigs, all of this could be done automatically? I think it would be more intuitive, and similar to various notation editors behaviour, where the subsequents measures shift back and forth seamlessy and transparently when you change a measure's time signature. Eventual items of the same length as the measure could be truncated at the end (not glued) when shortening the time sig, or the necessary space added after them (not looping them) when extending the time sig.

Sorry for the duplicated, didn't noticed that :-)

Justin 01-15-2015 06:58 PM

Quote:

Originally Posted by maxdis (Post 1460501)
Thank you for looking into this Justin; actually, I didn't noticed that the item had a media start offset, but I'm 100% sure I never changed it in this project (neither I can remember a single time I did it in my entire Reaper usage life :-)), so I think it happened by itself, after moving items and/or time signatures/regions. I really hope you can fix this.

Regarding the other issue in my report, you can see that when I try to extend/reduce the time signature, apparently nothing changes, and I have to insert/remove space to make the measure as long as desidered, shifting the subsequents items and markers to the correct place. Now, wouldn't it better if, when changing time sigs, all of this could be done automatically? I think it would be more intuitive, and similar to various notation editors behaviour, where the subsequents measures shift back and forth seamlessy and transparently when you change a measure's time signature. Eventual items of the same length as the measure could be truncated at the end (not glued) when shortening the time sig, or the necessary space added after them (not looping them) when extending the time sig.

Sorry for the duplicated, didn't noticed that :-)

Did you ever split the item? That could create the offset. In any case, I'll look at if we can make it autodetect when it has an offset that would be better treated as 0 (very close to the source length)...

Fixing the behavior of insert/remove time in project so that they make the timemap happier (creating shorter partial measures) -- there was actually code written to do that, but it didn't seem to be working right. Here's one of my (many) tests:

http://1014.org/shiz/shup/timemap_fix.gif

FnA 01-15-2015 07:56 PM

That's exciting boss. Throw us a bone.


All times are GMT -7. The time now is 06:37 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.