View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0004200ardourbugspublic2011-07-19 02:562020-04-19 20:15
Reporterin0giro Assigned Topaul  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformIntel Core2 DuoOSGentoo amd64 + Pro-Audio overlayOS Versionstable
Target Version3.0 
Summary0004200: tempo change on non first beat problems
Descriptionwhen inserting a tempo change on a beat that is not the first beat of a bar, Ardour creates a new bar starting at that beat with the tempo change on the first beat of this new bar, shortening the original bar as if there was a meter change as well. this screws up the bar/beat count of the time line as follows: though clicking on tempo changes, meter changes, and markers (from here collectively called markers) after the non first beat tempo change will show the correct position in bars+beats (ditto in the Location window), their position on the bar/beat time line is not correct.
Steps To Reproduce1) create a new session
2) enable bar+beats on the time line
3) insert a tempo change on any non-first beat of a bar and see that a new measure is created instead of placing the tempo change on the requested bar+beat
4) create markers after the tempo change and see that while clicking on them, they have the correct bar+beat position displayed (also in the Locations window), though their time line position in bar+beats is off
Additional Informationbasically, it seems like tempo changes are forced to happen only at the first beat of a bar. perhaps this is the desired functionality? even if so, the remainder of the time line should have the markers agree with the time line on their position in bars+beats.

  also, removing these non first beat tempo changes causes problems with bars collapsing on each other, at least in the time line display.
TagsNo tags attached.

Relationships

related to 0003832 new involved Tempo Map causes bar number render error and scrolling crash 
related to 0000080 feedback Add meter marker dialog suggests (and accepts) also beats other than 1 
related to 0004183 closedpaul Setting a new tempo mark set also a new beat 

Activities

paul

2011-07-19 15:51

administrator   ~0011165

please see the comments on 0004183

in0giro

2011-07-22 17:31

reporter   ~0011190

after reading the related bugs, i realize the justification for this current "feature" (though some us *do* use tempo changes mid bar, much to the angst of our fellow musicians ;)

however, the issue remains that when Ardour creates this new meter for the one measure to force a tempo change on the first beat, the subsequent measures are off by 1 bar, comparing the visible timeline in the Editor window to the marker/tempo & meter changes position in bars/beats on the timeline (when clicked for example) or in the Location window. i believe this is related/causes this bug: http://tracker.ardour.org/view.php?id=3832

globin

2011-09-28 21:20

reporter   ~0011613

If I understand correctly this is at least fixed in 2.8.12?

in0giro

2011-10-26 15:48

reporter   ~0011807

unfortunately, 2.8.12 rev. 10183 is still exhibiting this problem: after a tempo change on a non-first beat of a measure, the bars+beats timeline is not in sync with the location window, marker locations, etc. i think this "out of sync" issue also causes the timeline drawing issue and possibly related scrolling crash, both of which i describe in this bug http://tracker.ardour.org/view.php?id=3832

cth103

2011-11-14 17:36

administrator   ~0012014

There's certainly a problem in 3.0 here; when adding a tempo change mid-way through a bar, the bar ruler understands the change but all the metric section walking code appears not to:

1. new session
2. add a tempo change at beat 2 of the 1st bar
3. now drag the playhead: the verbose canvas cursor gives the wrong BBT time.

in0giro

2011-11-21 03:15

reporter   ~0012150

as reported above by cth103, i am now seeing this same bug in A3 (SVN rev. 10722), though the bug was originally reported for A2.

cth103

2011-11-24 00:40

administrator   ~0012194

These problems should be helped, or maybe even fixed, in SVN 10816. Could you test?

in0giro

2011-11-24 12:54

reporter   ~0012201

OK, with SVN 10820

+ previously created 3.0 session with your test case above now shows correct beat/bar when dragging playhead and also in secondary clock. however, location markers, region locations, tempo changes, etc. still have incorrect locations in bar/beat. also, when scrolling right, the bar/beats seem to jump around and move (e.g. set end marker at bar 5 beat 1, then scroll right a bit and then back, and end marker has moved to bar 4 beat 1).

+ creating a new session from scratch shows none of the errors.

+ existing A3 sessions with tempo changes seem to be OK.


so it seems to have helped, though existing sessions with non-first beat tempo changes are still showing some of the inconsistencies.

thanks.

the_CLA

2011-12-12 00:29

reporter   ~0012386

As of rev. 10984 there is still something essentially wrong with tempo markers in A3 - even more so than in current 2.0-ongoing. I'll try to go through this with paul on IRC the next few days.

And BTW bug 0000080 is about meter markers wich should behave differently than tempo markers and hence is NOT related to this bug.

the_CLA

2011-12-12 01:18

reporter   ~0012388

From IRC:

[01:41] < cth103> | the_CLA: I don't quite follow your problem with bug 0004200
[01:41] < cth103> | the_CLA: you say that everything works fine with new sessions...?
[01:42] < the_CLA> | cth103: No, that comment was not from me. It doesn't work for me
                         in new sessions.
[01:44] < the_CLA> | cth103: For example when inserting a new tempo on a non beat 1
                         position it creates two new meter markers along the tempo marker.
[01:45] < cth103> | the_CLA: ah, right
[01:45] < cth103> | the_CLA: that's to get the tempo marker on beat 1
[01:47] < the_CLA> | cth103: But the general assumption that tempo changes can/should
                         only happen on beat one is essentially wrong. There are quite a
                         few use cases where you want to place a tempo change in a non
                         beat 1 position. In fact tempo markers should be fully floating.
[01:48] < Seablade> | Hmm I think I could make an argument for tempo that should be
                         locked to SOME sort of beat, butt hat is the extent of it, I
                         can't see changing tempo mid beat other than what would be
                         equivalent for ramps
[01:48] < Seablade> | Which is an entire new ball of wax;)
[01:49] < the_CLA> | Seablade: Yes, usually you would want to place a tempo mark
                         somewhere on a grid, whatever note value this might currently be
                         set to. But it shouldn't be limited to beat 1. ;)
[01:50] < Seablade> | the_CLA: Oh I do agree with you there
[01:50] < the_CLA> | And it shouldn't mess with meter markers at all. ;)
[01:52] < Seablade> | Yep agree with that as well

Maybe tempo markers should allways snap to the selected grid value?

the_CLA

2011-12-16 16:25

reporter   ~0012426

Last edited: 2011-12-16 16:25

 In current SVN (rev. 11013) a tempo marker wich is not on beat 1 doesn't create meter markers anymore, but it still starts a new bar.

in0giro

2012-03-26 01:20

reporter   ~0013039

as of SVN 11726 in a new session, a tempo change which is inserted not on beat 1 does NOT create a new meter marker, NOR a new bar, but behaves "as expected". i assume that this is the desired behavior and the bug can be marked fixed?

paul

2012-06-22 17:15

administrator   ~0013666

see notes.

there is more work to do on tempo + meter, but this particular issue is now closed.

system

2020-04-19 20:15

developer   ~0022675

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2011-07-19 02:56 in0giro New Issue
2011-07-19 09:58 cth103 cost => 0.00
2011-07-19 09:58 cth103 Target Version => 3.0-beta1
2011-07-19 15:47 paul Relationship added related to 0000080
2011-07-19 15:50 paul Relationship added related to 0004183
2011-07-19 15:51 paul Note Added: 0011165
2011-07-22 17:31 in0giro Note Added: 0011190
2011-09-28 21:20 globin Note Added: 0011613
2011-10-26 15:48 in0giro Note Added: 0011807
2011-11-14 17:35 cth103 Relationship added related to 0003832
2011-11-14 17:36 cth103 Note Added: 0012014
2011-11-14 17:36 cth103 Status new => confirmed
2011-11-14 17:36 cth103 Target Version 3.0-beta1 => 3.0-beta2
2011-11-21 03:15 in0giro Note Added: 0012150
2011-11-24 00:40 cth103 Note Added: 0012194
2011-11-24 00:40 cth103 Status confirmed => feedback
2011-11-24 12:54 in0giro Note Added: 0012201
2011-12-12 00:29 the_CLA Note Added: 0012386
2011-12-12 01:18 the_CLA Note Added: 0012388
2011-12-16 16:25 the_CLA Note Added: 0012426
2011-12-16 16:25 the_CLA Note Edited: 0012426
2012-01-10 20:45 cth103 Target Version 3.0-beta2 => 3.0-beta3
2012-02-14 17:20 paul Target Version 3.0-beta3 => 3.0 beta4
2012-03-26 01:20 in0giro Note Added: 0013039
2012-04-23 21:58 cth103 Status feedback => acknowledged
2012-05-23 15:08 cth103 Target Version 3.0 beta4 => 3.0
2012-06-22 17:15 paul Note Added: 0013666
2012-06-22 17:15 paul Status acknowledged => resolved
2012-06-22 17:15 paul Resolution open => fixed
2012-06-22 17:15 paul Assigned To => paul
2020-04-19 20:15 system Note Added: 0022675
2020-04-19 20:15 system Status resolved => closed