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

Fernando Lopez-Lezcano nando@ccrma.Stanford.EDU
Thu, 15 Dec 2005 13:17:09 -0800


On Thu, 2005-12-15 at 09:22 +0000, Immanuel Litzroth wrote:
> Try setting the slime connection type to :FD-HANDLER and 
> see if that makes the problem go away. I have had similar 
> problems (with earlier versions though).

Thanks!! That worked just fine. I'm running all the rts examples from
within slime with an :FD-HANDLER connection type. Good. I wonder if I
should build slime with that connection as the default - one less thing
for users to configure. 

-- Fernando

> "Fernando Lopez-Lezcano" <nando@ccrma.Stanford.EDU> writes:
> 
> > 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 2 :NAME "Gina3G" :TYPE :OUTPUT :OPEN NIL)
> >  (:ID 3 :NAME "Gina3G" :TYPE :INPUT :OPEN NIL)
> >  (:ID 4 :NAME "qjackctl" :TYPE :OUTPUT :OPEN NIL)
> >  (:ID 5 :NAME "ZynAddSubFX" :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*))
> >                *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
> >
> >
> > _______________________________________________
> > Cmdist mailing list
> > Cmdist@ccrma.stanford.edu
> > http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist