Thank you all for the help with the midi file issue, or rather the update that there really is no basic midi file tool yet. I will investigate seq in cyclone! In the mean time if someone starts to code, I might suguest that they merge qlist and midifile(in|out) in functionality. For example the midifile tool reads in a midi file like a qlist so that you can rewind, jump to points, insert and delete entries as well as save the file. It might be as easy as starting with the qlist.c file, renaming it and adding .smf and .mid file format serializers. (I say this as if I know what I am talking about...)
Anyway, just a suguestion. Thanks again! -thewade
thewade wrote: ...
In the mean time if someone starts to code, I might suguest that they merge qlist and midifile(in|out) in functionality. For example the midifile tool reads in a midi file like a qlist so that you can rewind, jump to points, insert and delete entries as well as save the file. It might be as easy as starting with the qlist.c file, renaming it and adding .smf and .mid file format serializers. (I say this as if I know
that is how xeq project started and it was a mistake. It took me some effort to get rid of qlistness there... otoh, adding mifi i/o to Pd as a built-in feature could be handy for some people, even if most would still prefer to connect Pd to a real sequencing program. The easy way of adding that is to patch the qlist itself and forget about random access, loops, overdubs and such. Forking out yet another qlist clone is a bad idea.
Btw, you can read a midi file into seq, open its editor by clicking on the object, copy the contents into a text file, pipe the file through awk '{$1 = $1" target"; print}', and read a new file into a qlist...
Krzysztof
Krzysztof Czaja wrote:
thewade wrote: ...
In the mean time if someone starts to code, I might suguest that they merge qlist and midifile(in|out) in functionality. For example the midifile tool reads in a midi file like a qlist so that you can rewind, jump to points, insert and delete entries as well as save the file. It might be as easy as starting with the qlist.c file, renaming it and adding .smf and .mid file format serializers. (I say this as if I know
that is how xeq project started and it was a mistake. It took me some effort to get rid of qlistness there... otoh, adding mifi i/o to Pd as a built-in feature could be handy for some people, even if most would still prefer to connect Pd to a real sequencing program. The easy way of adding that is to patch the qlist itself and forget about random access, loops, overdubs and such. Forking out yet another qlist clone is a bad idea.
That's what I'm trying to do with midifile. It just outputs each MIDI packet as a list from one outlet, with the current tick number on another. (It doesn't parse the MIDI since that can be done externally with [route].) It should be easy to pack those into a qlist and later edit the qlist, then play it back into a midifile to save it in .mid format. If the writer part only writes type0 files it can be quite simple, since there is only one track (and I will have time any day now to actually write it...type1 needs preallocation of unknown amounts of memory). Another object could always be made that generates type1 (multitrack) from type0 files.
Martin
hi Martin,
Martin Peach wrote:
program. The easy way of adding that is to patch the qlist itself and forget about random access, loops, overdubs and such. Forking out yet another qlist clone is a bad idea.
That's what I'm trying to do with midifile. It just outputs each MIDI packet as a list from one outlet, with the current tick number on another. (It doesn't parse the MIDI since that can be done externally with [route].) It should be easy to pack those into a qlist and later edit the qlist, then play it back into a midifile to save it in .mid
no, that was not what I meant. I do not think there is any reason for using qlist, other than getting rid of externals altogether. Now I am not sure you I aware of seq's (not xeq's) existence...
Krzysztof
Krzysztof Czaja wrote:
hi Martin,
Martin Peach wrote:
program. The easy way of adding that is to patch the qlist itself and forget about random access, loops, overdubs and such. Forking out yet another qlist clone is a bad idea.
That's what I'm trying to do with midifile. It just outputs each MIDI packet as a list from one outlet, with the current tick number on another. (It doesn't parse the MIDI since that can be done externally with [route].) It should be easy to pack those into a qlist and later edit the qlist, then play it back into a midifile to save it in .mid
no, that was not what I meant. I do not think there is any reason for using qlist, other than getting rid of externals altogether. Now I am not sure you I aware of seq's (not xeq's) existence...
Krzysztof
Oh. What is bad about qlist? I haven't used it much but it seems like a neat idea. There is no obligation to use qlist with midifile, it just appears to be one way to get the MIDI from the compressed smf into a format that could be manipulated by a pd sequencer patch. As for seq, I don't have any help patches in mine, maybe I need to download another copy. If it's the same as seq in max then I don't like the fixed playback rate, and its inability to play just part of a file, but that's just me.
Martin
Le 16 Novembre 2005 11:11, Martin Peach a écrit :
If it's the same as seq in max then I don't like the fixed playback rate, and its inability to play just part of a file, but that's just me.
13 years ago (yes, that long ago), I hacked some sequencer object (on Max for the Mac Plus) to play at any rate, in reverse, with pointers, jumps, loops, etc... But I lost the source code on a floppy that erased itself after a few years... What I remember was the flexibility of using chained lists for the data structure. -- Marc
Martin Peach wrote: ...
If it's the same as seq in max then I don't like the fixed playback rate, and its inability to play just part of a file, but that's just me.
yes, seq is part of cyclone... it is simple, dumb and basic, but it does support variable playback tempo. The max-compatible way is to send it "start -1" followed by a stream of "tick" messages (slave mode). The incompatible extension of Pd version is that in playback mode it interprets "start <whatever>" as a tempo change.
Another incompatible extensions are the "goto <sec>" message for jumping to a time position in the sequence (also in the form "goto <sec> <ms-offset>"), and "scoretime <target>" for reporting current score time. Setting and controlling loops with these two is relatively easy.
Yet another incompatible extension is that Pd version does read format 1 files.
There are two major drawbacks of cyclone's seq: it does not handle sysex messages, and I have never tested it, neither methodically nor in a regular use (I prefer xeq...)
Krzysztof
-
Krzysztof Czaja -
Marc Lavallée -
Martin Peach -
thewade