View Issue Details
|ID||Category||Date Submitted||Last Update|
|0007194||features||2017-01-01 20:26||2017-01-05 16:41|
|Fixed in Version|
|Summary||0007194: Convert between 4 and 3 division based meters|
|Description||I've noticed that a song I'm working on actually better suits a 6/8 meter than a 8/8 that I have.|
When I set the 6/8 meter - the measures are shorter, and I would need to change the tempo to actually get the same measures "stretched" to fit the new 6/8 meter.
What it does is it cuts of 2 beats from every measure.
What I'd like to do is to make every measure start and end in the same place, but to be divided differently - instead of 8 divisions, I want 6, which will give a 3-based pulsation that'll suit the music better and make it easier to edit and play along to click.
It looks like I could get (roughly) what I want if I changed from 8/8 55 BPM to 6/8 73.(3) BPM.
The problem is, once I change the BPM - the MIDI data is shuffled around (while audio stays in place) destroying the sync.
Could there be a way to make the bars divide differently instead of becoming longer or shorter, as I change the meter?
|Tags||No tags attached.|
commit cee85c34b225584 introduced a preference so that you can define the pulse
in terms of note divisions other than a quarter note when editing a tempo.
in other words, you can now define a tempo in terms of one third of a whole note,
which is i think what you want.
||That's 5.5-309-gcee85c34b (still unreleased)|
I'm not sure if it'll solve my problem.
That'd solve the small tempo change rounding error of 73.33 != 73.(3).
The big trouble is the fact that Ardour moves the MIDI data around when I change tempo (which is quite understandable - it thinks I want to speed things up). What I want is the old MIDI data to stay in place, reinterpreted to fit the new tempo and meter.
I think there is a need for a separate procedure to change the meter of the song, reinterpreting the existing data to make sure bars stay where they were, only changing their internal structure.
if you change the meter, it won't (or shouldn't) move the midi data, but i get
i suppose i'd approach it from the side of 'get the rate correct' and then
'divide the rate into the correct measures'.
..but what you mentioned is worth thinking about.