MIDI has been on my mind since at least May of 2024. Here's a recap of the timeline of things I've accomplished:
Why am I doing all this?
-Fun programming challenge
-A very potent path to add rich music to game programming; no need to invent a format, piggy-back on this well-established one
-Solving this is probably harder than solving my very old dream of reverse engineering the Studio Session (1986) music file format and doing a playback with that.
May 2024: successful create a python script that loads a standard MIDI file (SMF) and plays it through windows' midi output bus. It was my way to finally dig in and learn python. https://github.com/Mu0n/PythonMidiPlayer
June 2024: The code was ported to Symantec THINK C++ 6 and could run on a SE/30 at first, I did later tests on a Plus. This requires an Apple MIDI interface box (or clone like I have) and an external MIDI module. You can see details about my struggles here and final resolution at the end of this thread: https://tinkerdifferent.com/threads...signal-from-modem-port-se-30.3666/#post-31251
August-October 2024: I designed my own set of MIDI selector switchboards that you can now purchase on jcm-1.com
October 2024: I get my hands on a F256K2 (Foenix Retro Systems) replacement board that I can swap into my F256K case. This new revision sports an integrated SAM2695 midi chip from Dream, it can receive real time midi command and produce the output itself. No need for interfaces, no need for an external midi module (though you can *also* route the signals to it if you wish). I port my C code during the following months with light difficulties, but I prevail in the end.
Output so far:
68000-68030 Macintosh side:
Type 0 and Type 1* SMF parsing and playback:
mixing of playback and graphical + player input together:
real time MIDI IN from a piano controller and have it analyzed and sent back to MIDI out: to be done in the future
6502 F256K2 side:
Type 0 and Type 1* SMF parsing and playback:
mixing of playback, graphics and player input together:
real time MIDI IN from a piano controller and have it analyzed and sent back to MIDI out: https://youtu.be/8oCGiYZ1eDQ
I'm especially excited to be able to create my own spin on using a full 88-keys midi controller to be able to drive my own 'jam loops' program. Everything I learn on one platform can be cross ported to the other. I will, in time, bring my F256K2 progress to the classic macs.
* type 0 midi file is just one track, so it's easier to parse and prepare your machine for playback, you already know in advance what the next event is and how far in the future it is.
type 1 midi file is for multiple tracks; they are more difficult to play since the full data of one track is read from the file before the next track is up. I figured it out by doing a first pass to get lengths and crucial data before commiting to reading the actual data on the 2nd pass.
Why am I doing all this?
-Fun programming challenge
-A very potent path to add rich music to game programming; no need to invent a format, piggy-back on this well-established one
-Solving this is probably harder than solving my very old dream of reverse engineering the Studio Session (1986) music file format and doing a playback with that.
May 2024: successful create a python script that loads a standard MIDI file (SMF) and plays it through windows' midi output bus. It was my way to finally dig in and learn python. https://github.com/Mu0n/PythonMidiPlayer
June 2024: The code was ported to Symantec THINK C++ 6 and could run on a SE/30 at first, I did later tests on a Plus. This requires an Apple MIDI interface box (or clone like I have) and an external MIDI module. You can see details about my struggles here and final resolution at the end of this thread: https://tinkerdifferent.com/threads...signal-from-modem-port-se-30.3666/#post-31251
August-October 2024: I designed my own set of MIDI selector switchboards that you can now purchase on jcm-1.com
October 2024: I get my hands on a F256K2 (Foenix Retro Systems) replacement board that I can swap into my F256K case. This new revision sports an integrated SAM2695 midi chip from Dream, it can receive real time midi command and produce the output itself. No need for interfaces, no need for an external midi module (though you can *also* route the signals to it if you wish). I port my C code during the following months with light difficulties, but I prevail in the end.
Output so far:
68000-68030 Macintosh side:
Type 0 and Type 1* SMF parsing and playback:
mixing of playback and graphical + player input together:
real time MIDI IN from a piano controller and have it analyzed and sent back to MIDI out: to be done in the future
6502 F256K2 side:
Type 0 and Type 1* SMF parsing and playback:
mixing of playback, graphics and player input together:
real time MIDI IN from a piano controller and have it analyzed and sent back to MIDI out: https://youtu.be/8oCGiYZ1eDQ
I'm especially excited to be able to create my own spin on using a full 88-keys midi controller to be able to drive my own 'jam loops' program. Everything I learn on one platform can be cross ported to the other. I will, in time, bring my F256K2 progress to the classic macs.
* type 0 midi file is just one track, so it's easier to parse and prepare your machine for playback, you already know in advance what the next event is and how far in the future it is.
type 1 midi file is for multiple tracks; they are more difficult to play since the full data of one track is read from the file before the next track is up. I figured it out by doing a first pass to get lengths and crucial data before commiting to reading the actual data on the 2nd pass.
Last edited: