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