View Issue Details
|ID||Category||Date Submitted||Last Update|
|0007193||bugs||2017-01-01 19:55||2017-01-23 13:48|
|Platform||PC / Linux||OS||Linux Mint||OS Version||18 KDE5 64-bit|
|Fixed in Version|
|Summary||0007193: MIDI regions are misplaced when changing meter|
|Description||I have changed the meter of a session from 4/4 to 8/8 to have the click hit twice as often. The tempo is 55 BPM, so it was difficult for me to play along.|
Later I realised some of the MIDI regions were moved backwards and overlapped with another MIDI regions.
The audio clips were not affected.
Not all MIDI clips seem to have been moved and automation data related to the MIDI clips was distorted - points were moved around not maintaining the original shape - I guess because parts of the automation data were located under different regions.
I expected all the regions to stay in place, I only wanted the click to change.
|Steps To Reproduce||1. Load a session with multiple MIDI tracks and regions|
2. Change the initial meter from 4/4 to 8/8 or even 16/16 and observe what happens.
|Additional Information||Changing the tempo also moves all the MIDI regions (and squeezes them) which is somewhat understandable, but I'd like Ardour to ask me what to do here - maybe I want my song to not change anything about the timing, just be expressed with a different tempo instead of scaling the MIDI events time?|
In this case I wanted to double the tempo to change the measures, but I wanted to keep all the events timing the same.
|Tags||No tags attached.|
i think the issue is that the midi regions are (by default) glued to bars and
i think this report is a good reason why they should be glued to pulse instead.
would having both options be too much?
I'm not clear why anyone would expect glued-to-pulse. Changing the meter from 4/4 to 8/8 totally changes the bar positions. The region was at bar N, beat M. The position of bar N beat M has changed because of the meter change.
What compositional tool says "ah, the region is actually at beat B, we'll leave it there even when you change the meter" ?
lets take PT as an example.
When creating a new track, the user can select the timebase as 'samples' or 'ticks'.
the PT way is to adjust the number of ticks per beat in order to achieve
a meter (ticks are thus pulse based), so i believe there is a precedent.
i guess the user problem is that a region containing a long sequence
behaves differently than the same region which has been split into smaller ones
when changing the meter.