View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004313 | ardour | bugs | public | 2011-09-06 09:12 | 2020-04-19 20:15 |
| Reporter | acolomb | Assigned To | cth103 | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 3.0-beta1 | ||||
| Summary | 0004313: Inconsistent meter info after inserting time at track start | ||||
| Description | When using Track - Insert Time with option "Move tempo and meter changes" at the beginning of a track (timecode 00:00:00:00), the tempo track seems to be missing information about the initial meter. This causes a crash when the grid is set to something meter-dependent: ardour-3.0: ../libs/ardour/tempo.cc:1753: Timecode::BBT_Time ARDOUR::TempoMap::bbt_add(const Timecode::BBT_Time&, const Timecode::BBT_Time&, const ARDOUR::TempoMetric&) const: Assertion `meter != 0' failed. Aborted | ||||
| Additional Information | Steps to reproduce: - Locate the playhead to timecode 00:00:00:00, set Edit Point = Playhead - Enable Grid and set to "Beats" - Select a track - Choose Track - Insert Time - Enter e.g. five seconds (NOTE: clock widget looks white-on-black-weird instead of themed, makes it hard to see what you're editing!) - Check "Move tempo and meter changes" and Insert Time - Move the playhead using the mouse on the timeline - Ardour aborts with the failed assertion (see console output above) This does not happen when manually moving the default meter and tempo marks, as they somehow still apply to the timeline before. In that case, they jump back to timecode 0 after re-opening the session. | ||||
| Tags | No tags attached. | ||||
|
|
Fixed in SVN 10057. |
|
|
Just for the record: Previously corrupted sessions can be manually fixed in the XML by resetting the "start" values under <TempoTrack>. Tested the fix, it works nicely. As mentioned above, there is still a possibility to move the initial tempo and meter marks manually on the timeline although they have the movable="no" attribute set. They are saved as and do jump back to 1|1|0 when closing and re-opening the session. Is this intentional or should they rather not be "movable" by any means? |
|
|
You're right. This should be fixed in SVN 10067. |
|
|
Tested and I like it :-) The whole "moving / dragging tempo and meter markers" approach could use some rethinking though, IMHO. Using the editing dialog works alright but dragging with the mouse yields some unexpected behaviour. Probably an issue of converting the timestamp between bars|beats and frames using the current versus the resulting tempo map. I've had some pretty weird issues in 2.8.11 with that lately - bar numbers jumping around wildly and a totally messed up timeline when using several tempo changes in one bar. I saw "tempo ramps" is a related post-3.0 goal which would need an improved model anyway. If there's time I will add another / several issues after working out the issues in more detail. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-09-06 09:12 | acolomb | New Issue | |
| 2011-09-06 09:35 | cth103 | cost | => 0.00 |
| 2011-09-06 09:35 | cth103 | Target Version | => 3.0-beta1 |
| 2011-09-06 22:41 | cth103 | Note Added: 0011447 | |
| 2011-09-06 22:41 | cth103 | Status | new => resolved |
| 2011-09-06 22:41 | cth103 | Resolution | open => fixed |
| 2011-09-06 22:41 | cth103 | Assigned To | => cth103 |
| 2011-09-08 17:13 | acolomb | Note Added: 0011473 | |
| 2011-09-08 17:49 | cth103 | Note Added: 0011475 | |
| 2011-09-08 18:43 | acolomb | Note Added: 0011476 | |
| 2020-04-19 20:15 | system | Note Added: 0022741 | |
| 2020-04-19 20:15 | system | Status | resolved => closed |
