Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Ok, that's a huge number of potential notes all at once, but is that actually ever gonna happen?
A midi file containing all that data would have to be stored somewhere in the first place, and ain't nobody got time to carry around a 200kTB midi file anyway.
Can't you insert a hardcoded (or even configurable) limit in your application that simply throws an error message if anyone ever tries to load >X number of notes/bytes all at once.
"Oops, your file is too big, the fuck are you trying to do anyway?"
One million notes should be <6MB, and I genuinely doubt that anyone would ever need far more than that for any non-destructive purpose.
(Unless I am severely misinterpreting what 'note' means here, from the little I recall about playing around with midi ages ago)
Surely whoever came up with that spec in the first place was not realistically expecting that any existing hardware to *actually* be able to handle all that data at once. So why should you? -
@endor Today is the day you'll learn about black MIDI: https://youtu.be/p_c6uQHlhZ0 (2.9 million notes, I believe)
-
@gronostaj so that's like what, 18MB?
(Also meh, too messy for my taste, it's just trying too hard to fill up with noise and speed up the tempo) -
@endor black MIDI community asked me for it, so I kinda HAVE to cater to them
-
@Parzi oh sure, my main point was that since 1M notes ~= 6MB, you can easily fit plenty of notes on a regular computer.
10M notes ~= 60MB
100M notes ~= 500MB
Let's say you impose a 1GB memory limit (or maybe make it configurable with a lower sane default) and you'll have far more than any sane person will ever need. -
@endor the black midi community would need no cap as someone will eventually make the absolute max size and will wanna play it.
The process of making my paging MIDI player has ground to a halt IMMEDIATELY:
Format 1 MIDIs.
There are 3 MIDI types: Format 0, 1, and 2.
Format 0 is two chunks long. One track chunk and the header chunk. Can be played with literally one chunk_load() call in my player.
Format 2 is (n+1) chunks long, with n being defined in the header chunk (which makes up the +1.) Can be played with one chunk_load() call per chunk in my player.
Format 1... is (n+1) chunks long, same as Format 2, but instead of being played one chunk at a time in sequence, it requires you play all chunks
AT THE SAME FUCKING TIME.
65534 maximum chunks (first track chunk is global tempo events and has no notes), maximum notes per chunk of ((FFFFFFFFh byte max chunk data area length)/3 = 1,431,655,763d)/2 (as Note On and Note Off have to be done for every note for it to be a valid note, and each eats 3 bytes) = 715,827,881 notes (truncated from 715,827,881.5), 715,827,881 * 65534 (max number of tracks with notes) = a grand total of 46,911,064,353,454 absolute maximum notes. At 6 bytes per (valid) note, disregarding track headers and footers, that's 281,466,386,120,724 bytes of memory at absolute minimum, or 255.992 TERABYTES of note data alone.
All potentially having to be played
ALL
AT
ONCE.
This wouldn't be so bad I thought at the start... I wasn't planning on supporting them.
Except...
>= 90% of MIDIs are Format 1.
Yup. The one format seemingly deliberately built not to be paged of the three is BY FAR the most common, even in cases where Format 0 would be a better fit.
Guess this is why no other player pages out MIDIs: the files are most commonly built specifically to disallow it.
Format 1 and 2 differ in the following way: Format 1's chunks all have to hit the piano keys, so to speak, all at once. Format 2's chunks hit one-by-one, even though it can have the same staggering number of notes as Format 1. One is built for short, detailed MIDIs, one for long, sparse ones.
No one seems to be making long ones.
rant