[CM] CM in SBCL 0.9.3 and CLISP 2.34

[Rick Taube]

>  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.

--rick