[CM] cm cvs, portmidi, threads (sbcl 0.9.7)

Fernando Lopez-Lezcano nando@ccrma.Stanford.EDU
Wed, 14 Dec 2005 16:20:44 -0800

On Wed, 2005-12-14 at 14:42 -0800, Fernando Lopez-Lezcano wrote:
> On Wed, 2005-12-14 at 14:29 -0800, Fernando Lopez-Lezcano wrote:
> > Anyone running sbcl 0.9.7 compiled with thread support and portmidi? 
> > 
> > Before activating threads in the 0.9.7 build I tried portmidi and
> > managed to get all the examples that do not depend on threads running
> > fine (the one that failed was "Using a receiver to trigger processes in
> > rts"). With a new build of sbcl (0.9.7) with threads enabled I cannot
> > even get the midi "thru" example going. I do this:
> > 
> > (set-receiver! (lambda (mm ms) ms (output mm :to *pm*))
> >                *pm*)
> > 
> > and nothing is echoed when I play, if I try to remove the receiver lisp dies...
> Apparently this has something to do with running lisp inside emacs with
> slime. If I run outside emacs the examples seem to work fine. I'll try
> with a newer slime, I guess...

Definitely an interaction with slime. 
This is with current slime cvs, sbcl 0.9.7 with :sb-thread. 

CM> (pm:getdeviceinfo)
((:ID 0 :NAME "Midi Through Port-0" :TYPE :OUTPUT :OPEN NIL)
 (:ID 1 :NAME "Midi Through Port-0" :TYPE :INPUT :OPEN NIL)
 (:ID 4 :NAME "qjackctl" :TYPE :OUTPUT :OPEN NIL)
 (:ID 6 :NAME "Virtual Keyboard" :TYPE :INPUT :OPEN NIL))
CM> (define *pm* (portmidi-open :input 6 :output 5 :latency 0))
; No value
CM> *pm*
#<portmidi-stream "midi-port.pm" (in:6 out:5)>
CM> (set-receiver! (lambda (mm ms) ms (output mm :to *pm*))
; No value

At this point nothing happens if I press keys in the MIDI keyboard...
Then I switch to the *inferior-lisp* buffer in emacs and typing any key
there causes the midi receiving process to start happening (ie: I press
keys in the keyboard and they are sent to ZynAddSubFX). So, cm seems to
be happy, and then I do:

CM> (remove-receiver! *pm*)

This is what I see in the *inferior-lisp* process:

;; Connection to Emacs lost.
;; [The function NIL is undefined.]

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "auto-flush-thread" {C591A81}>:
  #<SB-SYS:FD-STREAM for "a constant string" {C46F841}> is closed.

The sbcl process is somehow still there:

nando    32332  2.1  2.9 903692 61688 pts/4    Ssl+ 16:10
0:09 /usr/bin/sbcl --load /usr/lib/sbcl/cm/cm-load --eval (cm)

But that's it for the session.....
This was not happening for sbcl 0.9.7 without threading support. 
-- Fernando