View Issue Details

IDProjectCategoryView StatusLast Update
0003486ardourbugspublic2020-04-19 20:14
Reporterdanboid Assigned Topaul  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Target Version3.0-beta1 
Summary0003486: Additional tempo markers don't affect MIDI
DescriptionYou can successfully alter the speed of a full MIDI session by adjusting the default tempo marker at the start of a track but any additional ones you add in don't have any effect on tempo

7869
TagsNo tags attached.

Activities

cth103

2010-10-04 10:42

administrator   ~0009209

Probably has something to do with the FIXMEs in beats_frames_converter.cc.

cth103

2010-10-10 22:38

administrator   ~0009234

Hmm, actually, this seems to work to me. Can you give a recipe?

danboid

2010-10-11 00:35

reporter   ~0009235

When I insert a new tempo marker, all that seems to happen is it will change the grid spacing but nothing else- if its resizing the grid then it should probably also be resizing the notes too but that doesn't seem to be happening. Heres what I'm doing under 7887:

I create a MIDI region, say 8 bars long. I then insert a note on every beat of every bar and play it back. I then insert a tempo change marker at the beginning of the 5th bar, lets say 240bpm - because this is twice the tempo of the preceding bars you see the grid spacing half in size/double in frequency after the marker but when you play back the region it will play exactly as it did before inserting the tempo marker when I expected bars 5 onwards to be twice as fast.

cth103

2010-10-11 00:42

administrator   ~0009236

Ah right, thanks for the note. That's the FIXMEs I mentioned above; the code doesn't cope with tempo changing in the middle of a region.

paul

2010-12-14 04:26

administrator   ~0009621

i've done part of the work on this, but not entirely suprisingly, it doesn't have the desired effect to change tempo mid-region. i'm hoping that this doesnt' reveal a major limitation in the current backend design. more tomorrow or soon thereafter.

paul

2010-12-14 20:35

administrator   ~0009629

this is now nominally fixed in svn. i haven't tested it in any great depth but some basic tests worked as expected.

danboid

2010-12-17 19:48

reporter   ~0009653

Basic testing here says that this works as desired now - thanks Paul!

cth103

2011-01-03 18:56

administrator   ~0009802

Closing this as things seem to work. Please file separate reports for any troubles.

system

2020-04-19 20:14

developer   ~0022243

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
2010-10-03 17:47 danboid New Issue
2010-10-04 10:42 cth103 cost => 0.00
2010-10-04 10:42 cth103 Note Added: 0009209
2010-10-04 10:42 cth103 Target Version => 3.0-beta1
2010-10-09 18:00 cth103 Status new => assigned
2010-10-09 18:00 cth103 Assigned To => cth103
2010-10-10 22:38 cth103 Note Added: 0009234
2010-10-10 22:38 cth103 Status assigned => feedback
2010-10-11 00:35 danboid Note Added: 0009235
2010-10-11 00:42 cth103 Note Added: 0009236
2010-12-11 21:02 cth103 Assigned To cth103 =>
2010-12-13 22:09 cth103 Status feedback => confirmed
2010-12-14 03:40 paul Status confirmed => assigned
2010-12-14 03:40 paul Assigned To => paul
2010-12-14 04:26 paul Note Added: 0009621
2010-12-14 20:35 paul Note Added: 0009629
2010-12-14 20:35 paul Status assigned => feedback
2010-12-17 19:48 danboid Note Added: 0009653
2011-01-03 18:56 cth103 Note Added: 0009802
2011-01-03 18:56 cth103 Status feedback => resolved
2011-01-03 18:56 cth103 Resolution open => fixed
2020-04-19 20:14 system Note Added: 0022243
2020-04-19 20:14 system Status resolved => closed