View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004200||ardour||bugs||public||2011-07-19 02:56||2020-04-19 20:15|
|Platform||Intel Core2 Duo||OS||Gentoo amd64 + Pro-Audio overlay||OS Version||stable|
|Summary||0004200: tempo change on non first beat problems|
|Description||when 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 Reproduce||1) 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 Information||basically, 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.
|Tags||No tags attached.|
||please see the comments on 0004183|
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
||If I understand correctly this is at least fixed in 2.8.12?|
||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|
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.
||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.|
||These problems should be helped, or maybe even fixed, in SVN 10816. Could you test?|
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.
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.
[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?
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.
||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?|
there is more work to do on tempo + meter, but this particular issue is now closed.
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.
|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|