I’m just trying out the new MidiFile and MidiTrack nodes in vvvv_50beta35.2_x64 and testing it with a bunch of midi files. I noticed that MIDI Format 1 files seem to work just fine, but MIDI Format 0 files make vvvv hang. Midi Format 0 uses channels instead of tracks to separate different instruments.
I’ll attach one of the files that are not working.
Also I noticed that MidiFile doesn’t have a “filename” input, but a “file path” input, which is just a string. So to get the IOBox that you can right-click to open a file you need to take one from somewhere else, but cant just use the convinient middle-click way.
the format isn’t the problem here. i found two other problems though:
the files you provided are using sysex-commands which were not properly implemented.
i’d argue the files are corrupt. here is a sample of the ap1212h.mid you provided that shows two consecutive note-ons for E5 without a note-off in between.
the above is only one such example, when ignore those, the files load…
did you create those files yourself? i tried to repair the files using gnmidi.exe but it says “no hanging notes found”, which i cannot confirm (see picture).
and of course the filepath/filename issue was an oversight, thanks for pointing that out.
alpha>=35.4 now parses the sysex of those files correctly. there are still other sysex that are not parsed correctly. waiting for a file that has those…
also any corrupt notes are now ignored so that the files open. let me know if you find other files that fail to open…
Just gave it a spin and the files that crashed it yesterday are working now. I actually think its not crashing, it just takes extremely long. I tried with the attached file (again, one that we bought) and thought it crashed, but left it. After coming back to the computer after a few minutes suddenly it was there.
As soon as I change the track index in MidiTrack of a format 0 Midi file, vvvv freezes for about 2 minutes. Of course a Format 0 Midi file only has 1 Track, so MidiTrack should always output the same track regardless of Track selection. I noticed that the indexes dont seem to wrap like they do normally. If there are 16 tracks then track 17 should be the first one and -1 the last one.
I actually think that MidiFile and MidiTrack should be just one node and not have a Track Index, but just output the Track like you do the channel. Or at least MidiFile needs to output the indexes of the tracks, not just the count.
But I would just not have a track index selection, but just output all the tracks. That way we just get all the data from the midi file and can then sort out what we want after that. Normally I would have it so that for a format 0 the channels are used to separate information between the different instruments and if its a format 1 I use the track and just switch between them.
indeed now it still takes very long for larger files. this can still be improved at least by running the parsing async to not block vvvv completely. still to come…
good point, thats fixed now.
cannot confirm. for me the behavior is exactly as you expect it.
if this was only one node it would be quite a big node (too many outputs). and the data that comes out of the MidiTrack node now isn’t even all data! there are a lot of meta-events and sysex that could still be added. and i’d not want to have them all in the same node. even the text-stuff that is now returned should probably be moved to a separate node.
The speed is a real issue right now. You make it sound like thats expected speed, but something like GNMidi does the conversion in a split second!? What sort of time are you expecting once its working fine? Even for very large files it should take less then a second to be usable.
Hm, maybe I just thought the index wasnt working right, when it actually was. Its hard to tell because especially where there is just 1 track, then you cant really test it, because only index 0 should have any information on it. There is no definitive limit on the number of tracks, like there is with channels, thats why I think its much better to not have a track selector, but just parse the whole midi file and have one more output for track like you do for channel. Is the track index spreadable?
I agree that text and sysex stuff should be seperate from note and controller information, much like it is with the current midi nodes in vvvv are. One for everything related to notes, one for CC, Program Change and Pitchbend stuff and one more for text, sysex and per-track information like trackname, track type (like a tempo track) and programm. MidiFile should output: ticks, bpm, format, duration and number of tracks.
Really looking forward to these. I have so far used a Max4Live tool I coded to export multi-track midi in readable format directly from Ableton Live or used GNMidi to convert existing files, but this would make many things much easier.
