03-20-2018, 12:38 PM
John,
1) Remember that a MIDI file is not an audio file like an MP3 or WAVE file. It is a file filled with MIDI commands with timestamps. In order to produce audio from the file, something has to process those commands and produce audio from them. This is what I refer to when I say a sequencer - something that tracks time and figures out when to execute each MIDI command during playback. In order for audio to be produced, something has to process the MIDI note on/off commands and figure out (based upon whatever instrument is being used) what kind of audio data to generate. That is why you can play the same MIDI file with whatever instrument you want. It's also why the MIDI file on Android is going to sound different than the same file played through a different application that might choose different instruments. As you found with the "Midi Keyboard" app, a poorly implemented sequencer is going to produce erratic MIDi commands (as they will vary from the timestamps specified in the file) and that will change the audio output. I mention this because if you are going to convert your MIDI files to mp3 or wav, the result you get is determined by a lot of factors including what instruments the chosen application decides to use. I also want to further explain why it's not a simple problem to solve on the Windows 10 version.
2) If the scrolling reaches the end of the song, then it is stopped. Pressing a link point after the scrolling has stopped is not going to start it up again. That would require a completely new kind of feature where you could associate additional actions with a link point such as "start scrolling".
5) You phrased it perfectly fine. I was just trying to explain that playing a file, in this case, means sending commands from that file to an external device (which is potentially going to be a subset of the data found in the file as not all MIDI data in a MIDi file is supported by the messaging MIDi specification). I also wanted to explain that the file itself couldn't be sent in its entirety to a connected device unless that device has a custom interface for that. Much like #1, I have to implement my own sequencer so that each MIDI command in the file
is sent at the appropriate time to the connected device. It will be interesting to see how the Windows 10 version handles the very tight timing requirements for this.
Mike
1) Remember that a MIDI file is not an audio file like an MP3 or WAVE file. It is a file filled with MIDI commands with timestamps. In order to produce audio from the file, something has to process those commands and produce audio from them. This is what I refer to when I say a sequencer - something that tracks time and figures out when to execute each MIDI command during playback. In order for audio to be produced, something has to process the MIDI note on/off commands and figure out (based upon whatever instrument is being used) what kind of audio data to generate. That is why you can play the same MIDI file with whatever instrument you want. It's also why the MIDI file on Android is going to sound different than the same file played through a different application that might choose different instruments. As you found with the "Midi Keyboard" app, a poorly implemented sequencer is going to produce erratic MIDi commands (as they will vary from the timestamps specified in the file) and that will change the audio output. I mention this because if you are going to convert your MIDI files to mp3 or wav, the result you get is determined by a lot of factors including what instruments the chosen application decides to use. I also want to further explain why it's not a simple problem to solve on the Windows 10 version.
2) If the scrolling reaches the end of the song, then it is stopped. Pressing a link point after the scrolling has stopped is not going to start it up again. That would require a completely new kind of feature where you could associate additional actions with a link point such as "start scrolling".
5) You phrased it perfectly fine. I was just trying to explain that playing a file, in this case, means sending commands from that file to an external device (which is potentially going to be a subset of the data found in the file as not all MIDI data in a MIDi file is supported by the messaging MIDi specification). I also wanted to explain that the file itself couldn't be sent in its entirety to a connected device unless that device has a custom interface for that. Much like #1, I have to implement my own sequencer so that each MIDI command in the file
is sent at the appropriate time to the connected device. It will be interesting to see how the Windows 10 version handles the very tight timing requirements for this.
Mike