[CM] working with clm in cm-2.4.1

[Rick Taube]

My apologies for this rather long post  --  please hit delete if you dont
use cm with clm. But if you do, you might want to at least skim this message
before you start trying to use clm+cm to avoid possible confusion. cm-2.4.1
is a (first) step to a more "modular" cm, one that can coexits more
comforably with other systems and lisp packages. The biggest change is that
cm-2.4.1 no longer does an uncontrolled import of clm's symbols when it
builds. (of course, you can still do this yourself, see below). Instead,
when cm loads up it only uses the clm symbols that it actually needs to
compile itself.  And if clm is not around when cm loads up then cm uses a
"stub" clm package that it defines for just this purpose (see:
src/clm-stubs.lisp). This way if clm is loaded into a cm image at a later
point,  then clm will redefine the stubs to actual functions and all is
well. In addition, since clm's "all.lisp" itself does a use-package then
clm's symbols will  fold into your workspace when you load it. But in
earlier release people have done the reverse:

1    (load "clm")
2    (load "cm")
3    (save-cm)

In this case the sequence still works of course, BUT (unlike earlier
releases) now clm external symbols will NOT automatically be interned in the
cm package by the second step (load "cm") . So one possible confusion may
arise if you simply boot the saved cm image from step 3 and then try to
compile a .ins file willy-nilly like before.  If your .ins file does not
have an (in-package :clm) then lisp will try to compile the file in the
current package (cm) and this will break since the clm instrument needs
symbols in the clm package.

There are several (hopefully simple) ways to deal with this:

1. If you want cm and clm to share the same name space, then as soon as you
boot up cm and before you begin working or compiling clm, do this in the
listener:
    > (use-package :clm)
this will put all clm externals in the cm package just like before.

2. If that is too much work, then add the form '(use-package :clm)' in the
file "cm/etc/cminit.lisp " and it will happen automatically for you when you
start up.

3. Do the inverse, ie eval (in-package :clm) in the listener before you
compile the .ins file.

4. The most complex (but perhaps the cleanest) solution might be to put the
following 2 forms at the top of your ins file before you compile/load it:
      (in-package :clm)
      (export '(myins ...))
This way, when you compile "myins.ins" it will compile in the CLM pacakge,
and the export will allow you to  call it from the  cm package using CLTL's
normal package prefixing, ie (clm:myins ...).   In addition, clm+cm-2.4.1
will still define a cm event objects even for the defstrument defined
completely  in the clm package. So once your load that ins file compiled in
the clm package you can still do
    (new clm:myins :time 123 :dur 1)

If your DONT want cm events to be defined by definstrument just set the
variable clm::*definstrument-hook* to nil -- that will "cut" the only  link
from definstument to defobject, and hence, to cm.

I hope this is somewhat clear to those who use clm and cm.  Even though I
tested on all lisps using a test suite I would anticipate bugs for a bit and
I will try to do quick maintence for anyone (like me) starting to write
music.

The next release of CM will have a fully packaged (modular) CM with its
own -- hopefully minimal -- set of exported symbols.

-Rick