MidiFile to MidiBuffer

Is there a way to read a midiFile directly into a midiBuffer, and not have to deal with midiSequences? I am assuming that would be more efficient, and I could use the buffer iterator to tie midi events from a file and play them the same way I currently do with a midiSequence.

My concern is that loading to a sequence is very slow. For a 3 minute midi file with 11 tracks, the following code takes about 20 seconds:

[code]

double lastTime = midiToPlay->getLastTimestamp();

for (short i=0; i < midiToPlay->getNumTracks() ; i++)
{
Logger::outputDebugString(“loading track …” + String(i));

	mySequence.addSequence(*midiToPlay->getTrack(i),
				0, // time adjust
				0, // first allowable time
				double( lastTime)); // last allowable time
}[/code]

Have you tried it in release mode? Most of what it’ll be doing is memory allocations, so if you’re running on Windows, it’ll be far slower in a debug build.

Currently this is on an iphone. But that might be at the root of it.
Using the simulator its significantly faster. Still takes a bit longer than I would like … but it’s down to 4~5 seconds instead of 20~30.

Just checking if there was some way to get it faster.

Well, if there was an easy way to make it faster, I’d have used it! It does sound a bit odd that it’s so slow though, there’s not really much going on there. If you profiled it, I’d be interested to see where all the cpu is being used.

It seems to get slower the more tracks there are (more than just lineary slower that is).

Really, pretty fast on Mac and for most files on iphone, just some longer midi files take much longer than expected. First thought was maybe it was because it resorted for each new note or something, but your sorting code is pretty optimized in my experience, so I don’t know. Very possible that it’s just that the iphone can’t allocate memory very quickly.

It guess it’s because all the insertions need to shuffle the array along - so the first track will be very fast to add, but subsequent ones will need to keep shifting up all the data that’s already there when they insert each event. To get around that, it’d need to use a linked list to hold the events, or to read each track separately and then collate them in one operation… Both would involve quite a lot of rewriting though.