I have created a new MIDI format to overcome both the limitations of the current one and the unwillingness of the International MIDI Consortium to develop a MIDI 2.0 file format. So I made my own for my game engine. I even added some primitive scripting features.
But here comes the big problem: now I need to develop an editor. While I created a textual representation of it, which is a weird mix of assembly with Lua influences and essentially musical notes and rhythm as values, but eventually it should have a full GUI editor.
The format so far has the following kind of commands:
- Flow control commands
- MIDI emit commands which can be either:
- Note on and off commands
- Velocity change (aftertouch)
- Program change
- Control change
- Pitch bend
- A few other less important commands (SysEx, etc.)
- Commands for the scripting (Arithmetic commands on writable registers, compare and branch, etc.)
- The ever important
waitcommand, on which the whole system depends, as it tells the sequencer how much clock cycles have to wait between two commands
I have to process these commands for two display widgets, one displays the notes in a piano roll format, one displays any other commands. However, thanks to the way things work, I usually cannot just process MIDI commands directly. For example, notes are defined by a note-on and note-off event (often with aftertouch), no duration. And then comes editing. And then comes to editing around various wait commands. And then comes to editing around various conditional jump commands.
I started to work on a system that converted and separated each command for display, but it’s a bit time consuming, and adds extra complexity. But modifying it a bit and adding a “transpiler” to the two systems would make editing pretty easy to implement. I already added “macro”-like features to the textual representation of the format. Could this work?
You must log in or register to comment.
Well, first I gotta ask, is any of this really necessary or worth it? You want to resolve some limitations with the standard MIDI format, but are those limitations worth this much trouble to fix? “Buy dont build” is an important principle for any developer to take to heart because we all want to just do it ourselves, dive into the challenge, fix the little gripes, etc. But sometimes good is good enough and there’s no reason to retread the same ground someone else has. If you absolutely need something standard MIDI format can’t give you or available editors dont meet your needs, then sure, build away. But otherwise, save yourself the trouble, put your focus on the more important aspect of your project and just use the standard format.
And dont fall for the sunk cost fallacy. You have already invested time into this, and that time is gone. But that doesn’t necessarily mean that you should sink in more time if the outcome is not going to justify the additional time cost. It is okay to just shelf it for now. You can always come back to it if you need to later as well.
Man I have no idea but I read your entire post and it seems like you need to pause that work for a day or two. Do something else, touch grass, then come back and I’m sure you’ll have your answers.
Also sounds like one of those rare times when talking to a yellow duck would help. And splitting it all into smallest possible problems. Then solve one after another without thinking of the whole.
I did the “do something else”, and I’m still stuck…🙁
By creating your own format, you now have to create your entire ecosystem, or add functionality to existing systems to deal with your format. That is a huge undertaking and why media consortiums exist for stuff like JPEG, MP3, MP4, etc etc.
I don’t know the music ecosystem at all, so I don’t know what open source programs you could modify to support your format, but realistically that could easily be a year+ project.
If you’re having fun, keep going, but it’s a big challenge
