Yeah, it's a 'recorder'. No concept of ticks, bars, beats.
I must have read the midi file spec a hundred times but I don't think I ever noticed this feature
This is soooo ironic and funny for me. Here's why:
I have a branch, basically long abandoned, where among many other changes the time-lines could be switched
from ticks (musical time) to frames (linear time).
My goal was to make MusE the ultimate editor, suitable for linear time based broadcasting, studio etc.
You'll notice a normally hidden column in the Arranger named 'Lock'. It has remained unused.
Whoever put it there I think was heading in this direction. My code centered around using that column to switch from ticks to frames display.
But recently I explained privately that since the branch is long forgotten, my philosophy (erm, justification for doing the easier thing?)
changed to that of "MusE is a musical editor so I'll concentrate on that". Too bad I didn't finish the branch.
So the irony comes from that fact that also, here I am trying to make our wave based tracks and parts behave like our midi based parts,
that is, instead of being frame based they'll be tick based and won't move around when tempo is changed.
But now it seems we'll need to make an MusE 'uber-editor'. Both midi and wave tracks, parts, and events will need to be switchable.
A bit of tech talk, thinking out loud, may not get to changes tonight or tomorrow, just to let you know and if you have feedback:
So... Yes indeed that code I mentioned that we have is
flawed. MusE is wrong.
A line attempts to use a full integer to negate the extracted short integer division value from the file. The value ends up incorrect.
Great. That gets me to the
correct division value, which in this file's case is: 1000 ie. 1 ms.
But now... At this point for MusE in its current form (a musical editor) a conversion of the division must take place: From ms to ticks.
At 1000 (1ms), left as such, the song appeared to be exactly half as long as required.
Tempo must be considered, and a conversion against a standard tempo value must be done. This standard value is 120bpm
which is the default for a midi file, and in MusE.
At 120 bpm there are
2 beats per second. In MusE by default there are
384 ticks per quarter note and the
default time signature says
quarter note gets a beat.
Thus I discovered that I simply needed to multiply the value 1000 by 2, to arrive at a tick based division of 2000.
The very last event in your song has a 'time' value of 112626. With a division of 1ms that means the song is
112.626 seconds long
or just under 2 minutes, correct? The conversion I described does that.
But now here are some concerns, and you may want to provide feedback here:
If your song has only one tempo - the default 120bpm, then great, we are good.
But what happens if you have one tempo different than 120bpm or several tempos, in an existing song (see our tempo map editor),
and then you import this particular midi file by choosing 'Add to song' instead of 'Replace'?
This leads me to say: You will want (have) to know beforehand any 'implied' tempo and key signature changes
in your recorded performance and enter them into MusE
before actually importing the file.
That's because editing the tempos and key changes
after importing will alter the song.
An important (no pun intended) consideration: I can provide one new possible import dialog option - a checkbox:
True: "Do you want the importation to adapt all the events' times to the existing MusE tempo map?"
(This means immediately after importing, the song's various passages will play faster or slower depending on the existing tempo map.)
False: "Do you want the importation to be unaffected by the existing MusE tempo map?"
(This means immediately after importing, the song plays at the original speed throughout, regardless of existing tempo map.)
Again note that in both cases further editing of tempos will alter the song.
All for now. Cheers.
Sir talk-a-lot.