Kraku wrote:Hmm, the ease of writing the values in a list editor sounds like a logical reason for the smaller PPQN values to become standard during the years.
Reading your description, the float64 sounds like a logical step forward.
I've been thinking of writing a simple sequencer. Maybe I should try how it works out if I don't use the PPQN but maybe map the floating point range of 0..1 to a whole note or even the full measure (4/4, 3/4, etc.).
Sequencing began when cpu's were slow and memory was small. I worked with a company long ago where internal timestamps were uint32 and duration was uint16 because it seemed too "memory wasteful" to use int32 for the duration field. And it was a serious worry about the size of memory-resident MIDI tracks at the time. Not just silly "saving bytes where its not worth worrying about".
But nowadays they are trivially small compared to the size of the audio data even if you might throw everything including the kitchen sink into yer private MIDI event object.
Using only a uint16 for duration meant that it was low-probability but not uncommon that a user might want to play a longer-duration note than the uint16 could handle. So there had to be annoying kludges to handle the occasional exceptions of very long notes, all in the name of saving 2 bytes per MIDI event.
Just saying, at 32000 PPQN, maybe there could be long songs that overflow a uint32 "too soon" for some uses, and so if using int timestamps, perhaps advisable to use an int64 for timestamp and duration. Computers are commonly 64 bit nowadays, but int64's were a bit annoying to me on 16 bit or 32 bit computers. Not to mention 8 bitters such as Commodore 64.
I haven't looked at the float resolution issue for a long time, but even with float64 it may be that very long songs might get somewhat "numerically fuzzy" toward the end at 32000 PPQN. Or maybe not, can't recall.
So far as I recall, such as MIDI file tempo mapping was oriented to "make the best sense" based on quarter notes. So assigning float One Tick Per Whole Note might (or might not) be more brain damage depending on the time signature. In 3/4 or 6/8, bar 2 would have a timestamp of 1.75 rather than a nice 2.0. Bar 3 would start at 2.5, etc.
Even with 1 tick per quarter note, it might be slightly awkward with timesigs such as 5/8. I mean, the computer would play just fine, but timestamps might not make a lot of sense in a list editor unless the timestamp and duration fields are parsed to some more musically-understandable format.
Maybe could use "1 tick per bar" regardless of the timesig, but that would probably hurt my brain. Which is not very difficult to do.
I was thinking if float 1 tick per quarter note works good enough for internal resolution, it would be simple to display list editor data or other locations to whatever resolution the user wants. If he wants 96 PPQN, just multiply all the float 1 tick per quarter note values by 96 for display. The innards would always work exactly the same regardless of the user's preferred PPQN.
As best I recall, you typically do PPQN conversions when loading or saving MIDI files anyway. On file load, you would scale the MIDI file PPQN to whatever PPQN the sequencer is running at. So if using a float 1 tick per quarter note or whatever seems to make sense, it would be the same conversions when loading or saving MIDI files.
Maybe somewhat similar to the advantage of always using float audio internal to a program. Regardless whether you load an 8, 16, 24 or 32 bit file, you convert to float. So all the internal operations handle any audio file the same way with no cumbersome exceptions, just To-Float conversion on the way in and From-Float conversion on the way out.
Maybe float Tempo Ticks would offer the same advantage. Or maybe not.