[CM] CM in SBCL 0.9.3 and CLISP 2.34
Sun, 21 Aug 2005 14:35:58 -0500
> CM does appear to be working well in SBCL 0.9.3 under a Debian system
> (Demudi 1.2.1). However:
> WARNING: Cannot build GUI because GTK2 interface will not build in
> SBCL 0.9.3.
> :( Will that be possible soon ? Or am I missing something else ?
i dont know, its out of my hands. i saw on the sbcl list yesterday that
there is a 0.9.4 release planned for the end of this month but i dont
know if callbacks will be part of it or not. thats all im waiting for
i think. maybe ill send a note to the sbcl list and find out.
> Also, does any version of CMUCL support the whole CM enchilada
> (realtime, PortMIDI, MidiShare, GUI) ?
used individually they should all work now, in one form or another. the
main problem with cmucl is that there are no native threads -- at least
that i can find -- which means that everything has to be done as a
periodic task: the GTK event loop, rts scheduling and midi input
receiving. as far as i can tell there is only one "global" periodic
task manager so all this servicing will have to be done in the same
loop. i can easily add this (the code is actually already there) but i
dont think the results will be good. it also might be worthwhile
testing cmucl's lisp threads to see if they would be responsive enough.
the code is actually in place to do that as well
you should be able to run rts and receiveing right now (without using
the gui) and see how it works in cmucl. it might be good enough for
interactive work that doesnt push alot of data, i dont know.
as far as pushing data goes, we are sort of comparing midishare vs
portmidi right now on macos. the advantage with midishare is that it
has the noteType event, which means you only have to deal with half the
data that you do with portmidi, which requires noteOn+noteOff
transmissions. on the other hand, portmidi works with the underlying
"host" midi system, and so if being ALSA-based is important to you then
portmidi is the way to go on linux.
another unknown is how the threaded rts implementation will work if
slime is also running...
my problem is i simply dont have enough time to really learn all the
apps on linux so i can test all this stuff and see how good it really
works there, ie see if one could actually do a concert using it. its
easy for Todd and I to test on the mac becuase we have machines at home
and at work and have midi Monitors and Max to help determine how good
the scheduler is actually doing (and its looking good there). but i
dont have a linux box at home and when im at work im basically
teaching. so i test what i can but its really going to be up to people
with linux chops to stress test.