cmdist first contact

[Rick Taube]

>builded CM to ACL, but it did'nt work. (Q.: Could anybody install CM under
>ACL light version?)

this is not possible because of the limited heap size of ACL Lite.

>(Q: How can I let automatically execute <STELLA> with CM start?)

create a file cminit.lisp in the same directory as the cm image with the
following lines:

  (in-package :cm)
  (stella)

cm tries to autoload this file if it exists. if for some reason that doesnt
work in clisp/dos, then  i think clisp takes a -i argument that will load
an init file. check the clisp docs for a description of what arguemnts you
can pass it from the shell.

>
>6. I hope to have soon ACL 3.0.1 or 3.0.2, the complete version. (ACL
>standard costs $595 + shipping, but there were also a discount price of
>$446.25; the professional version costs $1250). I knew, that's the best for
>CM in WIN95, but - as I read in cmdist - MIDI real time 'must be
>theoretically OK', but nobody has this already proved...
>
>7. I informed myself about LINUX on Pentium: there are problems with most
>MIDI (only MPU standard is OK, but I have Voyetra MIDI), some Graphic and
>Sound cards, even with some CDs. So is LINUX - sorry! - conceptually 'older'
>than WINDOWS, which handles e.g. all MIDIs, cards etc. through one and well
>documented API and DLL.


the next release of CM will hopefully be OMS compliant. if so, it should be
possible to compile cm's macintosh midi code under windows, too.

>Actually I am interested 'to put musical material (i.e. algorithms) in time',
>so I tried 2 methods:
>(1) to give to ALGs absolute start and end times values as variables from a
>table and to places them on a time scale, controlled through a globale
>counter
>(2) to add simply the ALGs times: the end of an ALG will be start for the
>next

either is possible, the second one is more interesting -- define the
algorithm inside a lisp function that calls itself again just before it
stops:

(defun make-it (name beg len off rep)
  (algorithm (name name) midi-note (length len start beg)
    (setf note (between off (+ off 12)))
    (setf rhythm (pickl .1 .2))
    (when (and (> rep 0) (= count (1- length)))
      (format t "~%Sprouting #~D." rep)
      (sprout
       (make-it nil (+ time rhythm)
                (between 20 40)
                (pickl 20 30 40 50 60)
                (1- rep)))))))

Stella [Top-Level]: (make-it 'top 0 20 60 6)
#<ALGORITHM: Top>

Stella [Top-Level]: mix top 0
Sprouting #6.
Sprouting #5.
Sprouting #4.
Sprouting #3.
Sprouting #2.
Sprouting #1.
Stella [Top-Level]:


>worked, so the result is unforeseeable. It seems, this times interact free
>between different MERGEs. Here the simplest example to prove that:
[...]
>This is my most actually and the last question: is it here something false?
>Is MERGE not maked to be nested? I tried also other possibilities to insert
>different containers in other (super)containers, but MERGEs and ALGORITHMs
>are the most flexible combination.


im not sure what you mean -- your example works correctly from cm's point
of view. note that except for the top level merge you dont need to name the
internal ones. also your example really doesnt need the internal merges. it
could be more simply written so:

(merge m ()
  (algorithm nil midi-note (start 0 end 8 amplitude .5 channel 0)

    (setf note (item (steps 1 -1 2 -2 in random initially-from 'a4)))
    (setf rhythm (item (rhythms 16 32)))   	)

  (algorithm nil midi-note (start 13 end 21 amplitude .2 channel 1)
    (setf note (item (notes bf3 gf ef in random)))
    (setf rhythm (item (rhythms 16 8)))  )   )