Loading all GM instruments for midi file

[Boscop]

Hi, thanks for this library, it seems very useful :)
I'm looking for a GM soundfont player js lib that supports all GM instruments, so I'm wondering:
When loading a GM file, why aren't all the instruments that loaded that the file uses?
In other words, why is this line commented out?

MIDI.js/js/midi/player.js

Line 116 in a8a8425

// instruments: midi.getFileInstruments(),

[page200]

Commenting this line back in adds more instruments, but they play wrong parts. So there are probably other bugs. Possibly related: issue #226

I'm looking for the other bugs. Feel free to help. The events in the eventQueue have more diverse channelIds than the final sound output (I see about 10 channel IDs, which seems correct, but I hear only about two instruments that play the wrong parts/tracks of the file). So I'm trying to find what part of the code plays the events from the eventQueue. So far, I wasn't able to break on change of eventQueue.

[page200]

Maybe MIDI.js doesn't properly use the info contained in programChange events for selecting appropriate instruments from the SoundFont.

[page200]

In case you want to check whether someone fixed this in their fork of this repo, there are several ways to find repos that made changes: https://stackoverflow.com/questions/54868988/how-to-determine-which-forks-on-github-are-ahead

[page200]

If I understand issue #256 correctly: the branch called "abcjs" fixes this, but introduces other problems (playing one or two notes 3 or 4 seconds after resuming from a pause).

So looking into the changes made in that branch might help.

[hmoffatt]

js/midi/player.js contains the sequencer (the code that plays the event queue).

[page200]

The newest branch of this repo (named "abcjs") plays all instruments of a MIDI file correctly, but plays several unexpected notes in the first few seconds instead of the first notes of the song (when playing the song for the first time). Fixing that seems more promising than fixing wrong instruments in older branches.

The player.js of that branch is at https://github.com/mudcube/MIDI.js/blob/abcjs/js/player.js

1. Fixed problem: I successfully removed two of the unexpected notes by commenting out the calls to MIDI.noteOn() at https://github.com/mudcube/MIDI.js/blob/abcjs/examples/MIDIPlayer-v2.html#L157 and https://github.com/mudcube/MIDI.js/blob/abcjs/examples/MIDIPlayer-v2.html#L198. (Details: Those note played at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L138, even if I keep source.buffer at null then instead of initializing it. The caller is at https://github.com/mudcube/MIDI.js/blob/abcjs/examples/MIDIPlayer-v2.html#L149.)

2. Remaining problem: When https://github.com/mudcube/MIDI.js/blob/abcjs/js/player.js#L262 is reached for the first 4 times, the respective notes (first four notes of the song) don't play. After that line of code is reached for the 5th time, the 5th note plays with the wrong instrument. After a few more "silent notes", player.emit() in player.js is reached for the 1st time. The subsequent notes play correctly. So player.emit() (or some code near it) fixes the sound problems? And it should be called earlier somehow?

   The line that plays notes (including the note with the wrong instrument) is https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L250. This line is never reached by the "silent notes".

   The condition if (buffer) is skipped at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L236 during the "silent notes". Maybe something's wrong with that buffer. Or rather something's wrong with the programId that is used to index into _buffers at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L234-L235

(Maybe the remaining problem has something to do with promise and timeout in player.js? Where is galactic defined?)

[page200]

During the problems, the values MIDI.channels[channelId].program are wrong. They are equal to the respective channelId, but they shouldn't be. Where do they get initialized? They have those values as early as in the begining of onPageReady().

After a few seconds, they get updated, and the problems stop. They get updated at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors.js#L145-L151. Why is this code reached too late? In the MIDI file, programs/instruments get defined, and then the notes play. In MIDI.js, several notes attempt to play and only a few seconds later the program values get set correctly.

A place in the code where you can see the wrong program values initially (causing trouble such as skipping if (buffer)) and correct values later on is https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L232-L236

[page200]

Replacing if (delay) by if (false) at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors.js#L145 so that the program values are set correctly too early (as a temporary workaround) reveals more about the problem:

The following things are executed too late and in the wrong order:

• Program changes. They are scheduled via setTimeout at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors.js#L146-L148
• First notes of the song. Like all notes, they are scheduled via start() of an AudioBufferSourceNode at https://github.com/mudcube/MIDI.js/blob/abcjs/js/adaptors-AudioAPI.js#L250

Do these scheduled tasks trip over each other? What's weird is that there are no such problems anymore after clicking "stop" and "start" again.

Or is delay computed wrong for these tasks? delay values seem very similar after stopping and restarting the song, where the problem don't appear.

[mk-pmb]

setTimeout is not meant to have precise timing. The delay argument it takes is meant as the minimum delay. It might thus not be appropriate for music events.

[page200]

@mk-pmb:

As far as I know, requestAnimationFrame might have more reliable timing than setTimeout, but the music would get interrupted when the user switches to another window or browser tab, which is not desired. The user might want to enjoy the music playing in the background.

Overall, setTimeout has reliable timing in MIDI.js: restarting the song works well. Only the first seconds of the first start are problematic. The question is what happens there. If we identify the difference between the first and second start, we might find solutions.

So far, I couldn't find the cause of the differences in the Chrome Profiler etc. Maybe you can help.

[urobot2011]

Maybe MIDIPlayerJS and SoundFont-Player are useful. As far as I know, that doesn't seem to be the problem.

[urobot2011]

Oh, I forgot the link. The link is here:

• MidiPlayerJS
• soundfont-player