Writing/reading a MIDI file with CC events
I’m hoping to be able to write and read a MIDI file with CC events, without having to record it in real time. In other words, I want to dump all of the data from a coll and use it to immediately write a MIDI file, and similarly to read a MIDI file and immediately dump all of the data into the coll.
[detonate] won’t work because I don’t think it supports MIDI CC. [seq] won’t work because when reading a MIDI file and stepping through the contents with the ticks message, the resolution is only 48 ticks per second according to the help file. The external object [midifile] might do the trick, but I can’t tell by looking at the help file whether or not MIDI CC events can be recorded via the dump method… i.e., it looks like they would need to be recorded in real time.
Perhaps a combination of [seq] and [midifile]? [seq] could be used to write MIDI files, and [midifile] could be used to read them. I’m not sure if a more elegant solution exists.
I’m also not sure if [seq]’s low resolution is only when stepping through a MIDI file with the tick message, or if that’s how it writes them too.
Check out the ‘read’ message to the seq object. (N.B. The manual lies a little; I think you need to end each line with a semicolon.) You can just generate a text file by whatever means you want, save it as .txt (not .mid, ’cause it won’t have a proper MIDI file header), and read that into seq to play it back.
Thanks for your response. Assuming I understand you correctly, I think the problem with that is that once I read a file with [seq], I need to dump its contents into a coll right away. I can do this by using an [uzi] to rapidly send the "tick" message to [seq], but according to the docs, it results in a resolution of 48 ticks per second, which is just too low. :(
If you want to come out of a coll, and then later put it back in a coll, why do you need MIDI files at all? Clearly I’m missing something.
I’m working on (finished with, except for this part) a MIDI sequencer, which needs to be able to write/read MIDI files for/from other sequencers, and I have it set up so that the notes get stored in a coll. I could get rid of the coll, but I don’t think it would change anything. For example, if I were to use the external [midifile] to store notes instead of the coll, I would still need to be able to input notes and MIDI CC events not in real-time (the latter of which is not possible), and to be able to dump all of the notes and MIDI CC events at once in order to draw them.
Have you looked into this?
I don’t know anything about it, but there it is.
Thanks for the idea. I’ll keep it in mind for the future, but for now I don’t think it will work because it doesn’t seem to support more than one MIDI channel.
I’m actually trying to do what you suggested in this thread: http://cycling74.com/forums/topic.php?id=18202
I’ll keep posting on this thread though, because that one was solved with the [detonate] object, which doesn’t support MIDI CC.
I have what you suggested in the example below. It works beautifully for writing a MIDI file. Unfortunately, I tried to do the reverse as well (read a MIDI file with [seq] and dump its contents into [text] via an intermediary text file) and got stuck. Apparently when you send [seq] the message "write filename.txt," it writes a MIDI file, except with a .txt extension. The only way to get [seq] to write a proper text file is to send it the "read" command, select "text" from the dropdown menu, and type the filename with a .txt extension. I wonder if this is a bug?
Thanks again for the help.
----------begin_max5_patcher---------- 1199.3oc0ZszaiaCD9rWf8+.gPNzEPqf3C8v6dp.8xdn+BxFTHKSGqVIRuRz MocQ+uW9P1QIFNhV1lLAAvzZDI8LebdwYxO+3GlErf+HsK.7EvsfYy9ojxLM MEkY6HLKno3wx5hN8DCJ4MMTlHHr+kB5iB8KvQfk7sKpofx5px+BH3fNJEHV WHjePAUrUbPUGnl28zpYaapX0Tgdug6ntoPTtthc+ezRKEF1CAiihCAovD0. BMWOHoAtavdw2J1sYw6HuhyDrhFplI+01ph58+5UK0D4K9yOmlELbAcU+qdA PTTrl7+8wOnFkCgmOT8Kszhk.0ifUU0zOMY3HISOfvwWZ3H0kvwCsUBJnX.h .9rVmYSKWpP0nTaVSaoeEbaG8G2I0ync.FW.NXggfpdpcRx+929suoICdnRr VMO4zjSkx5p3r8LRcEiVx2xzbCdpmEj4ICNKH41bVzd+Byd.UqId+GvgK1xS rjmArk7Zdqc6808vEEAVTvtW4NPq0u+LYxJ83zqkRO4xqzuXqPLPUyZY03ma mnNpjteqLzD+yFpYeBTfevSKan3hClrXwnOH2hCOs0eYhBauucR5XBK9nBaP Xu.KGqT1ympQD5xqAbTnBrP+WYMsncpXFIVO.iGMdH400PBObzvXmLDBcGDt jth1VyeXpnWBwDEMc5lWmN9D+d.eHFsqb2iOIyu73SCsqq3d5g.jNhzZZcMG EINlmKz35Qlzvx03DL2M3TtCwISdVmCPYTnRLQvyybIPk4EEpnlpkUmNNkYL 7RL3zbWhSItywjLK9S2mT1Pe1XTTxq6SBcTnQkYP3AYFYIJQb+EiTZRm4EEw wWoblSv96dyla0ouR3zQFD4ZgLH+3fdhNd5uvgQOYdrCc7Phe+jwHJy8YDg8 SFQmSb9dipLWF+Bm+9Iw5ckuyopQouwiuafFL1qw2wI9svmSNNFL+JEGCice MQNyphXpZFDOZQQRN4hhbdEGAibo10JdaSgTuh2BtUQ8LxRBlbsztftDQ5JZ 1HyajwkVcbVnIy5xR.8ukyOrm9pUQQQfMsTAkIy1bcUmp+CRQbyVIX1xajFr k75ZSqs5D7VcyFVrkUtVuEce5B2Zg48fOw9NKXG3G6vLKfww.HIQZbJ+ATA+ TOmkJUljeUUBymde7ofeuZRslxi1mNaLbW8kcP3VjKqOyMPvMHvMXvMju+8u FBJaClJV0aoO2oknwkcaD9TCoLgeO+NRAStNNGIu4ZHUujdU5GE4L5GkUWLd RWnwT0o9rqxgNzp.RbXhWSquc3g2lwmMtCZcRplcVGX4k+munkP0KdAB1w21 VtiS20iKv.obIsSTwJDp+oBFLq3mOq0UKWRYOyMfL+iMbo71yIf6N9A6owbv wXNUaV7EygFk4R7GygG8XEcpLGDRTWlkXrVfYXs0xydJsu9r5Ipe3xHQXqTT gdAtUcvxBlC4GlKyFlS0M.ennFaEyk6GjatULWleXtj2vGqDqNVw9w4H1piU heh4gQVgb9IlGN+s7wZpULWt+NVGMUlWJBtj4HiwbPrebkXUfeLxeH2n4Yg7 nN2nYnB8SDBjUtRR7iAwKwj2TFDIoNh4TDjC+OXKxC7B -----------end_max5_patcher-----------
only [detonate] can read files with more than 1 track i think
Yes, but I only need one track with multiple MIDI channels, which [seq] supports. Thanks though.
If you can get Peter Swinnen to update his psw.midifile-parser to Max 5 then this might be what you’re looking for.
Hi everyone! I’m wondering if anybody knows of any new ways to handle these midi files.
I just need to get the program change numbers from type 1 SMF headers, and having a hard time with these externals. Ideally I could get it working w/ minimal externals as it will ultimately be an M4L device.
Forums > MaxMSP