I’m trying to work with the midifile in juce. I want to play midifile and after study the example of Vinnie on his github github repository i noticed the loading of midifile it’s qutie slow (at least on Windows).
there is some bottleneck in the framework or others problems ?
Perhaps Jule can give his point of view of the problem.
JUCE limits MIDI files to 2 megabytes on input, and it loads the entire file into memory in a single call:
juce_MidiFile.cpp
const int maxSensibleMidiFileSize = 2 * 1024 * 1024;
// (put a sanity-check on the file size, as midi files are generally small)
if (sourceStream.readIntoMemoryBlock (data, maxSensibleMidiFileSize))
I want to say … not so much time of delay, few ms, i think due to loading midifile. It’s not so much but thinking about multimedia application and realtime sequencer it’s not so good. Understand me ?
I’m testing midi on other platform and libraries for example Delphi and Lazarus and i must admit here loading it’s faster and more responsive.
Another problem found on the MidiPlayer of Vinnie is tempo: not all midifile are played in the correct tempo. if you want i can send you some midi example i’ve tested where Vinnie’s Midiplayer fails and other client like Windows media player or similar play them on the right tempo.
Probably Here must be change something on Vinnie’s MidiPlayer.
MidiPlayer in AppletJUCE doesn’t pretend to be a perfect MIDI player, its just example code that you can use as a starting point. Or, if you would like to work on it you can try to fix it and submit your changes via Pull Request.
AppletJUCE was designed to be a community project…
if you have time try for example Sweet Midi Player : http://www.ronimusic.com/swmipl.htm and load some midifiles. Test must be made with midifile with empty blank space at the beginning so you can observe it better!
I have no doubt that there are bugs in the AppletJUCE MidiPlayer, like I said it is just a starting point. You should improve it and then submit a pull request.
I know ! Mine is not a criticism ; since i’ve not so much experience in development expecially in c++ i’m asking to you and other help and possible solutions.
What makes you so sure that this delay is caused by loading the file, and not something else?[/quote]
because i notice a small peak in CPU using when i load the file. Probably it’s due to assign of midi event to midibuffer? I don’t know. How i can profile the app ? Is a way to measure the time of loading of midi events ? Tnx Jules!
I guess that loading a midi file and parsing it to fill a buffer are two different things, anyway if you think it’s slow you could do that job in another thread.
I guess that loading a midi file and parsing it to fill a buffer are two different things, anyway if you think it’s slow you could do that job in another thread.[/quote]
I’m thinking so, too… i’ll try to work on another thread but… my knowledge of c++ it’s quite basic so … if someone can give me a point of start i would like it
The MidiPlayer that on Vinnie’s Github was written by me. Very immature and childish, only for learning and test JUCE those days (temporary). That code for playing MIDI data’s ideas have a big problem, and not take into account the speed change event and so on.
I have asked Vinnie to remove it, but apparently he ignored my strong demand. It makes me feel angry and embarrassed.
Now I can responsibly say: If you only play MIDI files and other more purpose, use JUCE MIDI classes will convenient and simple, should without any problems, you can rest assured to use. but, you should to look the Jules’ source code first.
the sendBlockOfMessages function doesn’t allow to change bpm while the sequence play… so if here is a midifile with tempo changes your app keeps only the last tempo; i think must be avoid the sendBlockOfMessages.
the sendBlockOfMessages function doesn’t allow to change bpm while the sequence play… so if here is a midifile with tempo changes your app keeps only the last tempo; i think must be avoid the sendBlockOfMessages.[/quote]
It’s only designed to send small blocks, not whole files.