I would like to make a MIDI editing program in Python.
Why Python and not JUCE?
Python programmers are far cheaper and more readily available.
Also, I found this Python script:
https://pypi.org/project/py-midicsv/
Which enables MIDI to be decoded to CSV data.
I have a few questions for you MIDI 2.0 experts!
1. Is there a guide to programming with MIDI, or MIDI 2.0?
2. How do I convert MIDI 1.0 to 2.0 exactly?
3. What is the correct format of the data in MIDI 2.0 (in CSV or other formats) at a programming level.
4. I am particularly interested in microtonality and how it would be programmed in MIDI 2.0
If this information is available somewhere, please link it for me.
I've been looking for this information for hours and not finding much, I am posting this with a slight feeling of desperation!
I 'm not sure you'll find anything regarding converting MIDI 1 to MIDI 2, as I don't think that this will be possible - or rather, I'm not sure there'll be any point to this. One of the main points of MIDI 2 is the ability to include extra information that is NOT present in MIDI 1. A conversion program will need to add this information, but from where? The whole point of a conversion prog is that the job gets done, automatically.
It may well be that sequencer software that supports MIDI 2 would be able to import a MIDI 1 file, and then highlight all the missing data and suggest that this will need to be added before the file could be saved as MIDI 2, but this could be a fairly tedious task.
Apart from this, what would you do with a MIDI 2 file. I don't think there is anything YET that would be able to PLAY such a file, and there may not be such a thing for some time. Years? The full spec for MIDI 2 files is not even published yet.
There is no spec as such for any of the 'other' formats for MIDI 1 files, i.e. CSV, text, XML, etc, other than the obvious requirements of the basic midi data and the format of the specific data type, so I don't expect that there will be anything for MIDI 2 either. The only requirements really are that the data comprises ALL the data from the midi file, so that nothing is lost, that new format is easily human readable, and ideally can be edited using a basic text editor, and that the file can then be used to regenerate a new midi file. If those requirements are met, then the precise details of the intermediate format don't matter.
Geoff
Thanks Geoff.
I was under the impression that the new VST3 protocol was designed with Midi 2.0 in mind, and that any DAW which uses VST3 would therefore be able to process Midi 2.0 using a VST3 plugin.
https://www.midi.org/midi-articles/vst-3-7-sdk-includes-midi-2-0-support
So I thought DAWs such as Cubase and Studio One would already be capable of playing MIDI 2.0.
Isn't this the official MIDI 2.0 specs?
https://www.midi.org/midi/specifications/midi-2-0-specifications
Why convert MIDI 1.0 to 2.0?
Because currently all DAWs create MIDI 1.0 and don't have microtonality.
Midi 1.0 is only capable of producing notes at equal temperament, as far as I am aware. (please correct me if I'm wrong).
To produce music in Just temperament (following the harmonics) the pitch would need to be given with finer control, which MIDI 2.0 offers.
Of course, MIDI 1.0 lacks the data needed for a MIDI 2.0 file, so my proposed program could add it and convert MIDI 1.0 to 2.0.
I appreciate your help in shedding light on this subject!
Hmm, there has been some misunderstanding here, my apologies.
I assumed your first message was referring to MIDI files. A number of your questions seemed to me MUST have been referring to MIDI files. BUT maybe you were NOT referring specifically to MIDI files, but generally to the MIDI Transport System (MTS).
My answer is referring to MIDI files ONLY. For example, while the spec has been published regarding the MIDI Transport System, the spec for MIDI Files is NOT yet published.
Geoff
I've just been reading the MIDI 2.0 documents and the section I found most interesting is 4.2.14.
It says that messages which set pitch by the Attribute #3 Pitch 7.9 will override the default pitch (found in MIDI 1.0).
This would be the key to making a MIDI file capable of microtonality.
Attribute Type #3 is defined as Pitch 7.9. The 16-bit Attribute Value field contains:
• 7 bits: Pitch in semitones, based on default Note Number equal temperament scale
• 9 bits: Fractional pitch above Note Number (i.e, fraction of one semitone)
I would have thought that if I made a program to change the header of a MIDI 1.0 file into the header of a MIDI 2.0 file, I could then add this extra pitch information and it would be understood by the DAW.
To change a MIDI 1.0 to 2.0, wouldn't it simply be a matter of changing the protocol byte 1 to 0x02, as per 3.3.3 Protocol Negotiation?
If the MIDI transport system is currently working, shouldn't it be possible to create MIDI 2.0 files that can be transported?
Here is the clearest description of the pitch data I have found:
There are several misconceptions in this thread.
There are plenty of reasons to convert from MIDI 1.0 to MIDI 2.0 (and vice versa). It is reasonably straight ahead, useful, and encouraged by the MIDI Association. The basic methods are described in the "Universal MIDI Packet and MIDI 2.0 Protocol Specification" which one of the core MIDI 2.0 documents here: https://www.midi.org/specifications/midi-2-0-specifications/midi2-core
If you are creating a new MIDI application software, I would encourage you to use the UMP Universal MIDI Packet (defined in that document) as your native data format. The UMP format supports both MIDI 1.0 messages and MIDI 2.0 messages.
There are multiple ways to achieve microtonality in MIDI:
In MIDI 1.0 you can use these for microtonality:
- The MIDI Tuning Standard
- MPE with Pitch Bend (or Mono Mode with Pitch Bend)
In MIDI 2.0 you can use those in MIDI 1.0 above and also use:
- Registered Per-Note Controller #3: Pitch 7.25
- Note One Attribute #3 Pitch 7.9 (you already mentioned)
- Per-Note Pitch Bend
See the Section 4.2.14 "MIDI 2.0 Notes and Pitch" in the UMP and MIDI 2.0 Protocol Specification.
Thanks,
Mike.
Chair of MIDI 2.0 Working Group