ACL 3.1 on NextStep 3.1
Thu, 19 Aug 93 20:13:31 PDT
FYI:
Don't know if it's come up already, but I thought I'd share:
If you wish to continue using ACL 3.1 on NeXTStep 3.1, just rebuild the
lisp image you've already patched to work with 3.0, and add
-lsys_p to the LIBRARIES line in the config file: the _alloca call
apparently has been moved from libsys_s.a to libsys_p.a .
At least it seems to work for me!
Hope this is helpful!
Charlie
---
*_________________________________________________________*
Charlie Baker
Center for Computer Music Research and Composition
University of California at Santa Barbara
baker@waltz.ccmrc.ucsb.edu
*_________________________________________________________*
From: hkt@zkm.de (Rick Taube)
Date: Tue, 12 Oct 93 07:59:58 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: cm bug fixes
Cc: hkt@zkm.de
a few bug fixes in the latest cm.tar.Z:
1) clm instruments using sound-let and instument-let are now handled correctly by Write and Listen.
2) Import now handles midifiles that have no initial tempo change.
3) building the old system (defscorefile etc) now works.
3) The Rehash command is no longer needed.
>From hkt@zkm.de Mon Nov 8 05:31:40 1993
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
To: cmdist@ccrma.Stanford.EDU
Subject: graph streams and higher order Markov processes
Cc: hkt@zkm.de
Nicky Hind recently asked me for higher order Markov processes in graph streams. Ive got this working now, with some nice additions like pattern matching on the the previous N choices instead of straight lookup. If anyone wants to play around with Markov chains send me a note and ill mail the patch file, which includes documentation and the Stephen Foster example (2nd order Markov) from chapter 8 in Dodge/Jerse. othewise, this stuff will get encorporated into the next release.
I can also send out a #i read macro that helps shorten item streams definitions a bit:
#i(a b c) = (items a b c)
#ir(a b c) = (items a b c in random)
#irn(a b c) = (notes a b c in random)
and so on.
-hkt
>From bil@ccrma.Stanford.EDU Mon Nov 8 09:23:05 1993
Return-Path: <bil@ccrma.Stanford.EDU>
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
To: "Eric M. Mrozek" <mrozek@horowitz.eecs.umich.edu>
Subject: Re: help for cmdist
cmdist is a mailing list for discussions and announcements
related to Rick Taube's Common Music, and Bill Schottstaedt's
Common Lisp Music and Common Music Notation programs. To
subscribe or unsubscribe send your e-mail address to
cmdist-request@ccrma.stanford.edu.
(That's a stab at a blurb describing cmdist -- we haven't
automated this in any way, so mail to cmdist-request goes
to me. We patterned the name after mkdist. Up to now it
has averaged about 3-5 messages per month).
>From bil@ccrma.Stanford.EDU Wed Nov 24 14:15:23 1993
Return-Path: <bil@ccrma.Stanford.EDU>
From: Bill Schottstaedt <bil@ccrma.Stanford.EDU>
Date: Wed, 24 Nov 93 10:39:05 -0800
To: cmdist@ccrma.Stanford.EDU
Subject: new clm, reorganization of ccrma-ftp
I re-wrote the C unit-generator code in clm. The ccrma-ftp
pub directory that used to have all the Common Music related
files has been reorganized (mostly to make the MusicKit more
manageable). All our stuff is now on the Lisp sub-directory,
including pcl and libdsp.a. (That is, clm.tar.Z is now
ccrma-ftp:pub/Lisp/clm.tar.Z and so on).
>From bil@ccrma.Stanford.EDU Mon Jan 3 13:41:40 1994
Return-Path: <bil@ccrma.Stanford.EDU>
From: bil@ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Mon, 3 Jan 94 10:30:27 -0800
To: cmdist@ccrma.Stanford.EDU
Subject: new clm
I've started re-porting CLM to the Macs; currently CLM
reads/writes/plays both NeXT and AIFF files, and I hope
to add more file types as time goes by. CLM runs on
the Mac currently only with Lisp unit generators, so
it's slow as molasses, but someday I'll re-implement
the Digidesign code, and maybe do a port to the "av"
model's 3210. The other path to future hardware
appears to be the Turtle Beach board on the PC.
Other changes in the new CLM: I've added a "volume"
function (setf-able) to replace get/set-volume with
one whose range is 0 to 1.0 across all platforms
(the old one went to #x43 on the NeXT, 7 on Mac, 100
on SGI), and I'm in the midst of regularizing the
DAC function to work on all supported file types
on all platforms, including start/end args, and
hopefully, arbitrary srate support (via srate
conversion on-the-fly). The port of the C unit
generators to MCL failed due to disagreements
between MCL and MPW about C floats. I had also
planned to include BICSF headers, but they have a
fixed comment length which makes them unusable.
>From bil@ccrma.Stanford.EDU Tue Feb 1 11:32:37 1994
Return-Path: <bil@ccrma.Stanford.EDU>
From: bil@ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Tue, 1 Feb 94 08:05:56 -0800
To: cmdist@ccrma.Stanford.EDU
Subject: clm and cmn changes in January
clm runs in akcl on the NeXTStep-Intel platform, currently
using C unit generators; it's not yet very useful because
we can't play the output, but the timing info might be of
interest: clm on the Pentium runs about twice as fast as on the
68040, but still 4-5 times slower than on the 56000.
Other changes involved Mac-related improvements, mostly
courtesy Tobias Kunze.
cmn changes include title spacing; various Mac-related bugfixes;
proportional notation; quarter tone symbols; Ps-level is now
a variable, not a compile-time switch; and the justification
code tries to be smarter about line breaks.
>From hkt@zkm.de Thu Feb 3 06:05:02 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Thu, 3 Feb 94 11:07:32 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: new cm.tar.Z
Cc: hkt@zkm.de
ive put a new cm.tar.Z on ccrma-ftp.stanford.edu and ftp.zkm.de, mostly bug fixes. new clm stuff: direct-to-soundfile output now works much better thanks to bil. you must use clm.tar.Z from feb 2 or later. also all with-sound options now available to Open. other new stuff: a new Run command updates object times without producing any output; current time values can then be used for editing, ie
run foo,bar
map foo while (< $time 50) when (> $time 20) transpose note -3
set bar amp (interpl $time 0 .9 50 .1)
see changes.text for more info.
>From hkt@zkm.de Fri Feb 4 06:23:46 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Fri, 4 Feb 94 11:41:29 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: Re: new cm.tar.Z
ive just made up a newer cm.tar.Z (Feb 4) with some enhancements from last december that i forgot i implemented and didnt include in yesterday's release! markov selection for graph streams, chords in multiple items, new #i read macro for item stream definition, new repeat macro for repeating whatever pattern was last produced. see changes.text. the file stella/examples/markov.lisp contains the markov example from dodge/jerse. it composes endless stephen foster tunes, which is really frightening if you think about it.
>From hkt@zkm.de Tue Feb 15 10:36:04 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Tue, 15 Feb 94 15:49:30 GMT+0100
Subject: new implementation of defscale
ive reimplemented defscale to allow the creation of gapped and general scales in addition to equal tempered. its also now more flexible and easier to use than the original version and lets you layout a scale's frequencies three different ways: directly, as pitch values, or indirectly as scalers or interval distances between degrees. ive made a patch file:
ftp.zkm.de:/pub/defscale.tar.Z
that includes three files: a new version of scales.lisp, a new file contrib/defscales.lisp containing a bunch of different types of scales (ie flavors of javanese, bohlen-pierce, pythagorian, stretched octave, microtone etc etc etc), and a new doc/dictionary.rtf with updated entries for defscale and news ones for cent, centify, find-scale and list-all-scales
>From bil@ccrma.Stanford.EDU Tue Feb 22 11:24:11 1994
Return-Path: <bil@ccrma.Stanford.EDU>
From: bil@ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Tue, 22 Feb 94 07:20:35 -0800
To: cmdist@ccrma.Stanford.EDU
Subject: new CMN
CMN now can produce Quickdraw output -- there's a little
previewer for the Mac; also added a primitive previewer
for the NeXT. On the Mac, set (output-type :quickdraw)
and on the NeXT, (setf *cmn-preview* t) -- the latter
is not a "real" NeXT application, but it's faster than
Yap or Preview. Also, CMN now runs on NeXTStep/Intel --
on the 66MHz Pentium here, it's about 3 times as fast
as on the 68040 NeXT.
>From bil@ccrma.Stanford.EDU Mon Mar 7 12:40:29 1994
Return-Path: <bil@ccrma.Stanford.EDU>
From: bil@ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Mon, 7 Mar 94 08:09:31 -0800
Subject: headers/data types in CLM
I've added support for more header types and data formats to CLM.
Currently supported read/write: NeXT/Sun/DEC 16-bit linear, with AFsp extensions to the header
AIFF 16-bit linear
RIFF 16-bit linear
Currently supported read-only:
NeXT/Sun/DEC 8-bit mulaw, 8-bit linear, 24-bit linear, 64-bit double,
32-bit linear, 32-bit float, 8-bit alaw, 16-bit emphasized
AIFF 8-bit signed, 8SVX 8-bit signed
IRCAM 16-bit linear
NIST-SPHERE 16-bit linear
INRS, ESPS 16-bit linear
RIFF 8-bit alaw, 8-bit mulaw, 8-bit unsigned, 32-bit linear
VOC 8-bit signed(?)
no header (will prompt for info it needs)
Sound Tools 8-bit unsigned(?)
Turtle Beach SMP 16-bit linear
Unsupported:
Sun/NeXT compressed
AIFC compressed, HCOM, MOD, Mus10, SAM
RIFF ADPCM
Sound Designer formats
In some cases, I haven't been able to test the code yet --
many sound files don't seem to match the documentation, and
I am still looking for examples of some of these formats.
If one you like is not supported, send me a description of
it and preferably an example. The only limitations I have
are that CLM needs to be able to write an arbitrary length
comment in the header, and it needs random access to the actual
data -- the latter means that complicated compression schemes
involving blocked data are out, the former means that the only
header format I know of that I can use but don't already is
NIST-SPHERE.
Also, CLM can now take advantage of the Ariel PC56D under
NeXTStep/Intel.
>From hkt@zkm.de Wed Mar 30 09:59:40 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Wed, 30 Mar 94 14:59:23 GMT+0100
Subject: new cm release
Cc: hkt@zkm.de
ive placed a release of cm with lots of new stuff on ccrma-ftp.stanford.edu and ftp.zkm.de. see changes.text for full details....
1) New RT output syntax + playnote object for using with Paul
Lanksy's rt.app sound file mixing program. The file
stella/examples/barnyard.stella contains a demo mixing example using
standard NeXT sounds. See the implementation file stella/rt.lisp for
info on the rt output stream and playnote object; the dictionary.rtf
entries for RT and INFILES; and online Help Open topic.
2) Item streams completely reimplemented - 25% faster with several
new features:
a) zero length periods - a substream that sets its period length
to 0 "disappears" in its superior's pattern until it is encountered
again and sets its period > 0. This enables all sorts of
patterns that were formally impossible or very hard to describe.
b) new ROTATION pattern. see dictionary.rtf for more info. the
file contrib/change-ringing.lisp implements a bunch of rotation
values to produce various sorts of change ringing patterns such
as Plain Hunt, Plain Bob, etc. The change ringing idea is
courtesy of Nicky Hind.
c) item streams can now count either periods or elements, and can
traverse their patterns either depth or breadth first.
d) Stream creation is now much simpler, and you can create any
type directly using make-instance.
e) No more voicing stream - instead, either steps or intervals
can incerement their offsets in parallel to the data.
3) defscale now defines gapped and general scales in addition to
equal tempered. the file contrib/defscale contains a bunch of unusual
scales and tunings.
4) Algorithms now have initializer and finanalier slots to hold
optional functions to be funcalled just before and after the
algorithm or generator is scheduled.
5) New global variable *compile-algorithms* controls if stella should
compile an algorithm's code upon definition (when the code doesnt
result in a lexical clousure). the default value is nil, but a t
value may speed up exection by orders of magnitude.
*compile-algorithms* has no effect in mcl, which always compiles
code anyway.
>From bil@ccrma.Stanford.EDU Mon Apr 11 13:20:51 1994
Return-Path: <bil@ccrma.Stanford.EDU>
From: bil@ccrma.Stanford.EDU (Bill Schottstaedt)
Date: Mon, 11 Apr 94 09:38:37 -0700
To: cmdist@ccrma.Stanford.EDU
Subject: new clm
In 1990 when I started work on CLM, DSP chips were faster for sound
synthesis than main processors, and much work was being done to
develop multi-DSP hardware. At the time it was not unreasonable to
suppose that special purpose chips of that sort would continue to
offer better performance at a better price. I set up CLM to make it
easier to support whatever DSP chips came along. Even as late as last
December, I was preparing to provide CLM support for the AT&T 3210 on
the Mac. But the world has gone in a different direction: the 3210 is
no longer included in Macs, the 56000 has not improved much in the
last 4 years, the Ariel QP has been taken off the market; the final
straw from my point of view is that timing tests indicate that a
Pentium running C can outperform the 56000 by a factor of at least 3.
In some cases, it outperformed a NeXT with 2 QP boards!
So, the new version of CLM is different from previous versions.
I've flushed the c56 and clu packages, collapsing everything into the
clm package. The 56000 code is still available, but even on the NeXT,
the 68040 matches the 56000 except when you have an Ariel QP board.
To avoid name conflicts, and to reflect the new structure of CLM,
several functions and structs have been renamed. The C unit generator
option has been completely rewritten, increasing CLM's speed on
non-DSP systems by factors of 10 or better. Because the C unit generators
live in the same memory as the main lisp program, many ugly
limitations of the 56000 version have been removed. The main name
changes are that blk is now rblk, *cl-music-date* is *clm-date* (and
others similarly), and describe-structure-for-run has been replaced by
a slightly different macro def-clm-struct. User defined C functions
can be called in run without any overhead. There are no memory
limitations that I know of, so C-side instruments can be any size and
make use of long delay lines, for example, without an enormous speed
penalty. README.clm has the new benchmarks. AKCL users need to load
the clm library into AKCL before running. This version of CLM is not
backwards compatible with previous versions -- you'll have to
recompile your instruments, delete any references to the c56 or clu
packages, and fix up references to obsolete functions and so on.
I got simple cases of the new C version to run on the Mac, but
it was still 10 times slower than the NeXT, so I haven't yet found
the energy and desire to tackle the remaining bugs -- they appear
to be related to the Mac's stupid floating point implementation.
From: hkt@zkm.de (Rick Taube)
Date: Fri, 22 Apr 94 10:20:37 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: Common Music for Windows 3.1 and ACLPC
I've placed a new release of Common Music on ftp.zkm.de and
ccrma-ftp.stanford.edu containing a full port of the system to
Windows 3.1 under Franz ACLPC Common Lisp. The low level driver
interface for MIDI real time was implemented by Joe Fosco
(email b38669@anl.gov). This release also has some new analytical
operators for the Map command, see changes.text for more info.
-hkt
>From hkt@zkm.de Fri Apr 22 07:55:21 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Fri, 22 Apr 94 12:58:39 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: FYI, Please Post - ZKM Computer Music Workshops 1994
ZKM Computer Music Workshops 1994
Institute for Music and Acoustics
Center for Art and Mediatechnology, Karlsruhe Germany
1) Algorithmic Composition, September 25-October 5, 1994
Ten day workshop focuses on the computer as a compositional tool
independent from its role in digital synthesis. The course provides
an introduction to the basic principles and procedures in algorithmic
composition and covers such topics as pattern generation, composing
with random processes, scheduling, and algorithmic score editing.
The workshop is open to composers with previous experience in
computer assisted composition or digital synthesis. Familiarity with
at least one computer language (C, Pascal, Lisp, Smalltalk, etc) is
desired but not required.
The workshop will be taught using Common Music, which provides a
hardware independent environment supporting a number of synthesis
packages such as the Music Kit, Common Lisp Music, CSound, and MIDI.
To remain as general as possible, concepts will be introduced and
demonstrated using MIDI, but composers who wish to work with one or
more of the other synthesis possibilities during the workshop are
free to do so.
ZKM will provide a mixture of NeXT machines and Macintoshes;
composers may bring their own machine as well. Source code,
documentation, and directions on how to install the system at remote
sites will be free to the participants at the end of the workshop.
The course will be lead by Rick Taube. He developed Common Music and
Stella, is a composer and works as a software specialist at the
Institute. Tobias Kunze, a Berlin composer, will assist and support
the participants.
The workshop is limited to ten participants. Classes will be
taught in English and German; the handbooks are in English. The
registration fee for the course is 500 DM, for students 250 DM.
Introduction to Digital Sound Synthesis, October 6-9, 1994
This workshop provides an introduction to many of the synthesis
and sound editing techniques commonly in use today, and covers such
topics as frequency modulation, additive and subtractive synthesis,
linear transformations (sampling and frequency shifting) and
non-linear transformations (phase vocoding and physical modelling).
Participants will be able to augment their theoretical knowledge with
some "hands on" experimentation using the various synthesis models.
The workshop is open to composers with previous experience in
electro-acoustic music and in digital synthesis. Familiarity with at
least one computer language (C, MAX etc) is desired but not required.
The workshop will be taught using MAX and the ISWP (Ircam Signal
Processing Workstation) running on NeXT computers. But the aim of the
workshop is to provide an introduction to general technical and
acoustic principals rather than an introduction to a machine specific
environment.
The course will be lead by Pierre Dutilleux, who received his PhD
in signal processing and acoustics and is currently the Research and
Development Ingenieur at the Institute for Music and Acoustics. His
main interest is designing digital (software) instruments for
composers. The workshop is limited to ten participants, and may be
taken together with the workshop on Algorithmic Composition. Classes
will be taught in German and English; the handbooks are in English.
The registration fee for the course is 250 DM, for students 125 DM.
For further information and registration contact:
Zentrum fuer Kunst und Medientechnologie
Institut fuer Musik und Akustik
E-Mail: music@ zkm.de
Ritterstr. 42 76137 Karlsruhe
Tel. 0721/ 9340-300
Fax 0721/ 9340-39
>From penrose@silvertone.Princeton.EDU Fri Apr 22 11:38:56 1994
Return-Path: <penrose@silvertone.Princeton.EDU>
Date: Fri, 22 Apr 94 11:11:49 -0400
From: "Christopher Penrose" <penrose@silvertone.Princeton.EDU>
To: cmdist@ccrma.Stanford.EDU
Subject: clisp port of cm, clm, cmn etc.
Cc: penrose@silvertone.Princeton.EDU
Howdy folk! Is there any likelihood that cm, clm, cmn etc.
will be ported to the wonderfully compact gnu clisp?
Christopher
penrose@silvertone.princeton.edu
>From hkt@zkm.de Sat Apr 23 10:57:52 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Sat, 23 Apr 94 16:46:19 GMT+0100
To: Christopher Penrose <penrose@silvertone.princeton.edu>
Subject: Re: clisp port of cm, clm, cmn etc.
Cc: cmdist@ccrma.Stanford.EDU
>Howdy folk! Is there any likelihood that cm, clm, cmn etc.
>will be ported to the wonderfully compact gnu clisp?
If GNU Clisp is the same thing as CLISP developed by Bruno Haible, a port would be easy. If not, then if Gnu Clisp is a Common Lisp (which i doubt given your statement that its "wonderfully compact" ...), and if it supports CLOS, then porting cm (and cmn and clm as well, i believe) would be fairly trivial at this point. the only real problems i encounter in porting now is the lack or weakness of the target lisp's foreign function interface, which isn't part of CLTL1 or CLTL2, but which is nevertheless supplied by almost every vendor in some form or another. if GNU Clisp doesnt have a foreign function interface, or if its a weak one, then connecting to a midi driver for real time interaction would be impossible in cm, and calling low level c rountines in clm might also be difficult.
>From penrose@silvertone.Princeton.EDU Sat Apr 23 11:38:38 1994
Return-Path: <penrose@silvertone.Princeton.EDU>
Date: Sat, 23 Apr 94 11:31:05 -0400
From: "Christopher Penrose" <penrose@silvertone.Princeton.EDU>
To: cmdist@ccrma.Stanford.EDU
Subject: clisp
Cc: penrose@silvertone.Princeton.EDU
gnu CLISP is indeed the CLISP that was developed by Bruno Haible (and
Michael Stoll). It seemed attractive to me because it is much smaller
(in data size) than Franz, which might make cm, clm, etc. easier to
wield on a system with low memory (16m for me, and 8m for others).
Christopher
penrose@silvertone.princeton.edu
>From hkt@zkm.de Mon Apr 25 03:32:44 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Mon, 25 Apr 94 09:21:40 GMT+0100
To: Christopher Penrose <penrose@silvertone.princeton.edu>
Subject: Re: clisp
Cc: cmdist@ccrma.Stanford.EDU
I dont have any firm plans for a CLISP port but it would certainly be a reasonable thing to do. When I last looked at CLISP (about a year ago), its CLOS implmentation was non-standard and its foreign fuction interface was funky. I think there is a version of PCL that works in CLISP, so all the Lisp code for cm (and clm and cmn for that matter) should port very smoothly. As to the low-level C side, the docs i had were cryptic so im not sure how easy implementing midi real time would be, or if it is even possible.
-hkt
>From baker@jitterbug.ccmrc.ucsb.edu Mon Apr 25 14:57:58 1994
Return-Path: <baker@jitterbug.ccmrc.ucsb.edu>
Date: Mon, 25 Apr 94 11:28:03 PDT
From: baker@jitterbug.ccmrc.ucsb.edu (Charlie Baker)
To: cmdist@ccrma.Stanford.EDU
Subject: name conflicts
Hi!
Little problem with using latest clm with (next to most recent) cm....
I needed to shadow mix, filter, and env out of clm into stella...
will this cause problems with stella? I guess I could go into stella and
put stella::filter, stella::mix, etc., but whatta pain, sigh.
Any ideas?
Thanks!
Charlie
---
*_________________________________________________________*
Charlie Baker
Center for Computer Music Research and Composition
University of California at Santa Barbara
baker@waltz.ccmrc.ucsb.edu
*_________________________________________________________*
>From hkt@zkm.de Tue Apr 26 02:42:14 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Tue, 26 Apr 94 07:06:58 GMT+0100
Subject: Re: name conflicts
Cc: cmdist@ccrma.Stanford.EDU
shadowing those symbols should work, but since clm changed package structure in its last release, you might still have problems trying build an older version of cm with it. the older cm will still be trying to use old, defunct clm packages when it is built. err...clear as mud?
-hkt
>From baker@waltz.ccmrc.ucsb.edu Tue Apr 26 03:16:59 1994
Return-Path: <baker@waltz.ccmrc.ucsb.edu>
Date: Mon, 25 Apr 94 23:54:44 PDT
From: baker@waltz.ccmrc.ucsb.edu (Charlie Baker)
To: hkt@zkm.de
Subject: Re: name conflicts
Cc: cmdist@ccrma.Stanford.EDU
Yeah, think I already found & removed a few references
to :clu package & :c56 package... seems to work now...
wierd thing happened with clm io, though (it's in
Bill's new io code...) if you use his DSP clean-up
routine (end-run) with sound-let (tmp sound files)
you get only the first file...looks like the DSPjust sits there ,,,(on (DAC-IS-OPEN))
Well, it's ok now!Thanks, Charlie
>From philp@access.digex.net Tue Apr 26 08:15:11 1994
Return-Path: <philp@access.digex.net>
Date: Tue, 26 Apr 1994 07:34:26 -0400 (EDT)
From: Phil Perucci <philp@access.digex.net>
Subject: Linux?
To: Common Music LISTSERV <cmdist@ccrma.Stanford.EDU>
Is anyone out there using cm (and related packages) on Linux? If so,could you please comment on:
1) Were any modifications required for use on Linux?
2) Is AKCL better to use than CLISP?
==============================================================================
Phil Perucci | "All postings are my own opinion - all comments
Systems Integrator | are intended for research/educational purposes"
==============================================================================
>From hkt@zkm.de Thu Apr 28 08:15:04 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Thu, 28 Apr 94 13:47:15 GMT+0100
To: Phil Perucci <philp@access.digex.net>
Subject: Re: Linux?
Cc: cmdist@ccrma.Stanford.EDU
>Is anyone out there using cm (and related packages) on Linux? If
> so, could you please comment on:
> 1) Were any modifications required for use on Linux?
> 2) Is AKCL better to use than CLISP?
I dont know of anyone using cm on linux, but as there is almost no OS specific code in the system it shouldn't be a problem. I'm currently in the midst of a port to CLISP (hopefully completed today...) at which point linux would be possible using either AKCL or CLISP. I don't have access to linux so I can't test the system. I also don't even know if anyone has written a midi driver for linux!
-hkt
>From philp@access.digex.net Thu Apr 28 17:54:21 1994
Return-Path: <philp@access.digex.net>
Date: Thu, 28 Apr 1994 17:17:39 -0400 (EDT)
From: Phil Perucci <philp@access.digex.net>
Subject: CM vs CLM?
To: Common Music LISTSERV <cmdist@ccrma.Stanford.EDU>
Hi,
I am in the process of getting Common Music up under AKCL/PCL on Linux.
Before I get too excited... Is Common Music WITHOUT CLM sufficient to
generate MIDI files? I want the flexibility of LISP for generating
MIDI files, and am under the impression that CLM is *not* required.
Can anyone verify this? It would be real easy for me to get "off-track"
at this point!
==============================================================================
Phil Perucci | "All postings are my own opinion - all comments
Systems Integrator | are intended for research/educational purposes"
==============================================================================
>From baker@jitterbug.ccmrc.ucsb.edu Sun May 8 15:25:32 1994
Return-Path: <baker@jitterbug.ccmrc.ucsb.edu>
Date: Sun, 8 May 94 12:18:41 PDT
From: baker@jitterbug.ccmrc.ucsb.edu (Charlie Baker)
To: cmdist@ccrma.Stanford.EDU
Subject: csound play
Cc: hkt@zkm.de
Well, it's not great, but if you want to play the output .sco files in csound syntax, try
replacing the last method in stella/csound.lisp with the following:
(defmethod play-using-syntax ((syntax csound) file &rest args)
(declare (ignore args))
#+mcl (format t "Sorry, can't play csound from Lisp on the Mac.~%")
#-mcl (let* ((ofile (ask-file :prompt "Output Sound File name?: " :direction :output))
(orc (ask-file :prompt "Orchestra File name?: "))
(command (format nil "csound -o ~A ~A ~A" ofile orc
(namestring (truename file))))
(plcmd (format nil "play ~A" ofile)))
(cm::shell command)
(tell-user "Playing ~A ." ofile)
(cm::shell plcmd)))
This assumes that unix can find csound somewhere in your paths...also I should work out a way to keep the output snd file and .orc files as slots in the io-stream object...is there a way to access other slot values of the io-stream, when all you are passed is the file slot? Rick? Bill?
Best,
Charlie
>From hkt@zkm.de Mon May 9 11:27:29 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Mon, 9 May 94 15:00:51 GMT+0100
Subject: Re: csound play
Cc: cmdist@ccrma.Stanford.EDU
>is there a way to access other slot values of the io-stream,
>when all you are passed is the file slot?
the Play command currently operates on file names without creating an internal io-stream, so play-using-syntax never sees an io-stream. i should change this so that io-streams are always created and play-using-syntax is passed a stream. ill fix this when i have some time, certainly before summer, but until then the function FIND-STREAM returns the stream for a specified file name.
so the solution is to add the slots Output and Orchestra (or whatever) to csound's io-stream so that you can set them via Open:
open foo.sco output "/tmp/x.snd" orchestra "x.orc"
then use find-stream inside your play-using-syntax method to get the values from the stream structure
also, there is a unix/ subdirectory under cm source dir where you might want place a csound invoking script; see the rt and music kit entries current kept there. send me what you get working and ill incorporate it into the system when i get time to fix play-using-syntax.
-hkt
>From baker@jitterbug.ccmrc.ucsb.edu Mon May 9 17:41:31 1994
Return-Path: <baker@jitterbug.ccmrc.ucsb.edu>
Date: Mon, 9 May 94 14:02:26 PDT
From: baker@jitterbug.ccmrc.ucsb.edu (Charlie Baker)
To: hkt@zkm.de
Subject: Re: csound play
Cc: cmdist@ccrma.Stanford.EDU
OK- for csound syntax after write play:
then the fix would be (& it checks out on my Next...)
In stella/csound.lisp:
The defclass becomes:
(defclass csound-score-file (event-file header-mixin)
((orchestra :initarg orchestra :initform nil)
(output :initarg output :initform nil)
(syntax :initform (find-syntax ':csound))))
and the play-using-syntax method is now:
(defmethod play-using-syntax ((syntax csound) file &rest args)
(declare (ignore args))
#+mcl (format t "Sorry, can't play csound from Lisp on the Mac.~%")
#-mcl (let* ((ofile (slot-value (find-stream file) 'output))
(orc (slot-value (find-stream file) 'orchestra))
(command (format nil "~Aunix/playcsound -o ~A ~A ~A"
*common-music-directory* ofile orc
(namestring (truename file))))
(plcmd (format nil "~Aunix/playsnd ~A"
*common-music-directory* ofile)))
(cm::shell command)
(tell-user "Playing ~A ." ofile)
(cm::shell plcmd)))
AND the TWO shell scripts (one to compile sound, other to play it...):
1) (Place in unix directory as playcsound and chmod a+x playcsound. Edit for your site!)
#!/bin/csh -f
if (-e /usr/local/bin/csound) then
/usr/local/bin/csound $*
else if (-e /LocalApps/CSnd/csound) then
/LocalApps/CSnd/csound $*
else echo "Can't find csound! Fix unix/playcsound in Common Music's directory."
endif
2) (Place in unix directory as playsnd and chmod a+x playsnd. Edit for your site!)
#!/bin/csh -f
if (-e /musr/bin/newplay) then
/musr/bin/newplay $1
else if (-e /usr/bin/sndplay) then
/usr/bin/sndplay $1
else echo "Can't find sound player! Fix unix/playsnd in Common Music's directory."
endif
Thank you for the help! (I didn't know about find-stream!)
Charlie
---
*_________________________________________________________*
Charlie Baker
Center for Computer Music Research and Composition
University of California at Santa Barbara
baker@waltz.ccmrc.ucsb.edu
*_________________________________________________________*
>From hkt@zkm.de Tue May 10 03:17:55 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Tue, 10 May 94 08:32:21 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: port to clisp native clos finished
Cc: dennismi@lynx.dac.neu.edu, hkt@zkm.de
I've finished porting cm to clisp's native clos and put new archives on ftp.zkm.de and ccrma-ftp.stanford.edu. This port allows cm to build on dos and reduces the overall size of the saved lisp image by about 2 meg. Btw, clisp compilation takes forever on dos, expect about a 3 hour wait.
The port also uncovered 2 clisp bugs, README.CLISP explains what you have to do before building the system.
I didnt do any timings but there does not appear to be any execution speedup using clisp's clos and it seems to take longer to initally build its methods than pcl. This appears as a pause the first time you execute something new; once it caches its methods performance seems ok.
if you take cm.zip, unzip using -d: PKUNZIP -D CM.ZIP
-hkt
>From hkt@zkm.de Mon May 23 09:40:42 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Mon, 23 May 94 15:26:49 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: lisp intro texts
ive just finished writing two short introductory texts on lisp and lisp style that i intend to use as part of future workshops. i would be happy to send them to anyone that is interested -- im particularily interested in getting feedback in the form of corrections, opinions on what i omitted that you feel important or have a better explaination for, etc. if you want one or both texts indicate if you can receive NeXT mail or can read .rtf text.
-hkt
>From hkt@zkm.de Wed Jun 15 21:59:38 1994
Return-Path: <hkt@zkm.de>
From: hkt@zkm.de (Rick Taube)
Date: Thu, 16 Jun 94 06:55:49 GMT+0100
Subject: Re: common music mailing list
Cc: cmdist@ccrma.Stanford.EDU
>I'd like to receive the cm newsletter at this address;
its best to send requests like this to the administrator at
cmdist-request@ccrma.stanford.edu
>in addition, I'm
>curious about the popularity of cm -- could you give me an idea of how
>many people are on this mailing list?
there are currently 67 people on the list. im not sure what this info
actually tells one, but certainly nothing about how useful (or not) some
software will be for you! for comparison, the ispw (ircam signal processing
workstation) mailing list has 40 people and mkdist (music kit) has 182
people.
>From mrozek@horowitz.eecs.umich.edu Wed Jun 29 10:35:03 1994
Return-Path: <mrozek@horowitz.eecs.umich.edu>
Date: Wed, 29 Jun 94 13:32:00 -0400
To: cmdist@ccrma.Stanford.EDU
Subject: wierdness compiling cmn
I recently recompiled CMN in akcl on a NeXT, and actually read some of the messsages. Although CMN seems to work properly, I noticed that gazonk0.o was compiled over and over again, and usually 6 times in a row at any given time. I did a file name search, and it's not in the cmn, pcl, akcl, or kcl directories. Does anybody know what this file is and why it is recompiled so many times?
I also noticed that the cmn image takes up roughly 16MB. Is it really supposed to be that large?
Eric
>From bil Thu Jun 30 07:27:30 1994
Date: Thu, 30 Jun 94 07:27:30 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: Re: wierdness compiling cmn
The gazonk0 file is a temporary file created by akcl when
something causes it to call the "compile" function. I think
pcl use "compile" for various things like method definitions.
On cmn's size -- I'm not sure how to ask Lisp where the space
is going, but cmn has a zillion methods and instance variables.
Perhaps I could make it smaller at the start by leaving the
instance variables unbound until they're actually used.
Date: Thu, 21 Jul 94 12:58:35 -0700
From: <hkt@ccrma.Stanford.EDU>
To: cmdist@ccrma.Stanford.EDU
Subject: buildcm script
Cc: hkt
several people have written to me asking what happened to the buildcm script. i removed it becuase the script disallowed error backtraceing when something went wrong in the building process. to build the system, just boot your lisp image and then load build.lisp, ie:
% cd /lisp/cm/build
% cl
Allegro CL 3.1.20 [NeXT] (3/7/91)
Copyright (C) 1985-1990, Franz Inc., Berkeley, CA, USA
<cl> (load "build.lisp")
if you still want to use buildcm, here it is in all its glory:
---------------------------buildcm-------------------------------
#!/bin/csh -f
#
# build script for installing Common Music
#
if ($#argv == 1) then
set lisp_image = $1
else
echo "buildcm needs a base lisp image file specified"
exit
endif
if (-e $lisp_image) then
$lisp_image -qq -batch < build.lisp
else
echo "$lisp_image does not exist."
endif
echo All done!
From: hkt@zkm.de (Rick Taube)
Date: Wed, 10 Aug 94 12:43:46 GMT+0100
Original-Received: by NeXT.Mailer (1.87.1)
Pp-Warning: Illegal Received field on preceding line
Original-Received: by NeXT Mailer
(1.87.1)
Pp-Warning: Illegal Received field on preceding line
To: cmdist@ccrma.Stanford.EDU
Subject: new release of common music
Cc: hkt@zkm.de
I've placed a new version of CM on ccrma-ftp.stanford.edu and
ftp.zkm.de. Several people have reported difficulty restoring Unix
tar.Z files on the Mac so I'm now maintaing 3 different versions of
the archive:
cm.tar.Z Unix compressed tar archive.
cm.sit.hqx Macintosh binhexed Stuffit archive.
cm.zip DOS zip archive (use pkunzip -d)
Also, the old macunix.sit.hqx file was somehow corrupted so I've
placed a new version on the server as well.
As of this release CM no longer contains defscorefile and with-part.
As a result of removing this stuff some directory and file names have
changed so its best to restore the archive to an empty directory.
---
Highlights:
1 New CMix and CMusic syntaxes (Thank you, Charlie Baker!)
2 Musical notes can now be given absolute starting times.
3 Code walking made smarter; algorithm slots can now dynamically
affect item streams and be referenced inside vars expressions.
5 Run command optionally caches output to new or existing threads.
6 New :decimals option to formatting-slots macro does floating point
and integer formatting, new :print-if :always option automatically
shows unbound slots as "-unset-"
See changes.text for a complete listing of new features and bug
fixes.
-hkt
From: hkt@zkm.de (Rick Taube)
Date: Fri, 12 Aug 94 10:54:31 GMT+0100
Subject: emacs indentation for common music forms
Cc: hkt@zkm.de
I finally figured out how emacs indentation works (sort of...) and
was able to get all of common music's "special forms" indenting
properly in Franz Inc's fi:common-lisp-mode. if anybody wants these,
send me a message. in the future, ill keep emacs stuff in a file
contrib/cm.el.
-hkt
From: hkt@zkm.de (Rick Taube)
Date: Tue, 16 Aug 94 09:09:16 GMT+0100
Subject: cm in gcl1.0
Cc: hkt@zkm.de
FYI, the current Common Music release works fine in GCL-1.0 without
any changes. GCL is the new, free Gnu Common Lisp (formally AKCL)
developed by Free Software Foundatain. I've got a tarfile of patches
for porting GCL to NeXTStep/Pentium and for building CM and CLM in
GCL 1.0 on both NeXT and NeXTStep/Pentium:
ftp.zkm.de:/pub/gcl-1.0-next.gz.
CLM and CM run very fast on the Pentium -- the clm stuff im doing now
runs about as fast on a pentium as on my cube with 2 quint boards!
you get gcl from math.utexas.edu:/pub/gcl
gcl-1.0.tgz
pcl-gcl-1.0.tar.gz
here are the various GCL ports:
* 386-linux: 386 or 486 running linux
* 386-bsd: 386 or 486 running bsd
* dec3100: Decstation 3100,5000, OS=Ultrix V3.1C-0 (Rev. 42) [akcl
505]
ULTRIX V4.2 (Rev. 96)[akcl 602] (VOL= )
* hp300-bsd: Hp 350, 370 [motorola 68K] under 4.3 BSD (mt xinu)
* hp300: Hp 350, 370 under HPUX.
* hp800: Hp 720,730 under HPUX (version 8). Possibly hp 800 also
* mac2: Macintosh under AUX (unix)
* mp386: intel 386 under System V 3 (eg microport,interactive)
* NeXT: NeXTStep 2.1 Motorola 68030,68040.
* NeXT386: NeXTStep 3.2 Intel
* ncr: intel 386 under System V 4 (loader sfasl not done).
* ps2_aix: ibm ps2 under aix
* rios: Ibm risc 6000 under aix3.
* rt_aix: ibm rt under aix release 2.
* sgi4d: 4d silicon graphics (IRIX System V Release 3.3.1)[akcl 600]
* sgi: silicon graphics 3d versions
* sun3-os4: sun3 under os 4.03, 4.1, 4.1.1
* sun3: Sun 3 (motorola 68K) Sun OS 3.5
* sun4: Sun 4,(sparc) sparctations, sun os 4.03, 4.1, or 4.1.1
Date: Wed, 24 Aug 94 00:44:11 EDT
From: peter@bio01.bio.uottawa.ca (Peter Foster)
To: cmdist@ccrma.Stanford.EDU
Subject: pesky digits
Cc: peter@bio01
cm folk
I have been dabbling with the rt syntax with cm under akcl on a NeXTstation.
However, I have been having a problem with significant digits. It seems that
cm gives lots of digits when it writes reals, but rt doesn't want more than 10
or so.
To illustrate, I use cm (stella) to write out two crows in rt syntax, one loud,
the second made quiet using
set 2 gain 0.2
and then I write it out and use rt to play it. I hear 1 crow.
(To duplicate the problem, save the following to a file called "crows.rt"
and load it into rt.app, or just use the rt driver)
// Stella output from 23-Aug-94 21:28:21
infile=/NextLibrary/Sounds/Crow.snd
gain(1,1,1,1,1,1,1,1,1)
timescale=0.01
tracks=8
turntrackson(1,1,1,1,1,1,1,1,0)
setlefttrackgain(1,1,1,1,1,1,1,1,0)
setrighttrackgain(1,1,1,1,1,1,1,1,0)
setoutputgain(1,1,0)
playnote(at=0.0,snd=1,track=1,gain=1)
playnote(at=0.5,snd=1,track=1,gain=0.20000000000000001)
mix(0,9999)
If I decrease the number of zeros in gain=0.20000000000000001 from 15 to 8,
I hear 2 crows.
How can I ask akcl or cm to give me fewer digits when it writes reals?
Peter Foster
University of Ottawa
peter@bio01.bio.uottawa.ca
From: hkt@zkm.de (Rick Taube)
Date: Wed, 24 Aug 94 07:17:05 GMT+0100
Original-Received: by NeXT.Mailer (1.87.1)
Pp-Warning: Illegal Received field on preceding line
Original-Received: by NeXT Mailer
(1.87.1)
Pp-Warning: Illegal Received field on preceding line
To: peter@bio01.bio.uottawa.ca (Peter Foster)
Subject: Re: pesky digits
Cc: cmdist@ccrma.Stanford.EDU, hkt@zkm.de
As of the last release of cm (10-Aug-94) the formatting-slots macro supports
a :decimals formatting control. Here is a patched version of rt's
write-event method that rounds to 3 decimals. This code should be compiled
before using. There isnt any way to automatically load a patch file in akcl
that I know of, so you should either:
1) Replace the write-event method in rt.lisp with the one below, then
recompile rt.lisp, then quit lisp and rebuild cm to save a new image.
2) Compile as a patch file and load by hand each time you start up cm.
-hkt
;;;-------------------
(in-package :stella)
(defmethod write-event ((object playnote) (stream rt-file))
;; output prefers last= or overlap= values over at=time.
;; this complicates things enough so that we dont try to use
;; formatting-slots on these values.
(let ((file (slot-value stream 'stream)))
(write-string "playnote(" file)
(let ((last (careful-slot-value object 'last))
(overlap (careful-slot-value object 'overlap)))
(cond (last
(when overlap
(error "LAST and OVERLAP are mutually exclusive."))
(format file "last=~S," last))
(overlap
(when last
(error "LAST and OVERLAP are mutually exclusive."))
(format file "overlap=~S," last))
(t (format file "at=~S," (slot-value object 'time)))))
(formatting-slots (object file :postamble ")" :eol t
:prefix (lambda (slot)
(format nil "~(~A~)=" slot))
:delimiter #\, :print-if :value)
(snd :print-if t) (track :print-if t)
(gain :decimals 3) (transp :decimals 3) (skip :decimals 3)
(dur :decimals 3) (end :decimals 3) (rev :decimals 3)
(last :decimals 3) (overlap :decimals 3) (pan :decimals 3)
(amp :prefix "amp(" :suffix ")"
:printer rt-envelope-printer)
(ampl :prefix "ampl(" :suffix ")"
:printer rt-envelope-printer)
(ampr :prefix "ampr(" :suffix ")"
:printer rt-envelope-printer)
(gliss :prefix "gliss(" :suffix ")"
:printer rt-envelope-printer))))
Date: Wed, 24 Aug 94 07:17:31 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: clm.tar.gz
clm.tar.Z has reached the size where it barely fits on
a floppy, and that's causing trouble, so I've added
clm.tar.gz to the ccrma-ftp pub/Lisp directory --
it's a lot smaller, and presumably has all the same
data. gzip -d clm.tar.gz or use gunzip to undo the
compression.
Date: Wed, 24 Aug 94 07:07:08 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: patch file in akcl (was pesky digits)
If the file init.lsp exists in the current directory, it
is automatically loaded "immediately after system initialization",
whatever that means. Perhaps it could stand-in as a patch file.
Date: Thu, 8 Sep 94 09:12:25 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: clm minor updates
I added support for AVR sound files, and fixed BICSF/EBICSF.
Thanks to Tobias Kunze, the Mac version of CLM can finally
play its output (i.e. the dac function works). libdsp.a
is no longer used by any version of CLM.
Date: Fri, 9 Sep 1994 07:58:51 -0500
From: clefort@unix1.sncc.lsu.edu (Clinton R Lefort)
To: cmdist@ccrma.Stanford.EDU
Subject: clm & CM
Bill ,
I would still like to run clm on my Mac 650, but need guidance in how to get it up and running on my Mac...the Instructions in the package are not quite
simple enough for me; that is, step by step....I have CM running, but have not been able to run stella properly...
Any responses are welcomed...
Clint LeFort
Date: Fri, 9 Sep 94 07:35:35 GMT-0700
From: bil (To: clefort@unix1.sncc.lsu.edu (Clinton R Lefort))
To: clefort@unix1.sncc.lsu.edu (Clinton R Lefort)
Subject: Re: clm & CM
I've been getting help from several Mac experts lately, so the
Mac version of CLM is slowly becoming usable, but it's still
very slow and tedious -- I wish I could recommend it, but...
Anyway, if you have the latest clm (or at least one where
mac.lisp has a working "start-dac" function), then the
following steps should get it to run:
fire up MPW, set the directory to the clm directory, then
in the MPW window:
C -d MAC headers.c<ENTER> -- "<ENTER>" = the enter key
C -d MAC merge.c<ENTER>
C -d MAC -s CLIO io.c<ENTER>
C -d MAC -s CMUS cmus.c<ENTER>
start MCL, open all.lisp, fix the pathnames to point to
your versions of:
clm = the clm directory
clib = the MPW CLibrary
mpwlib = the MPW main library
These are set in statements like:
(setf (logical-pathname-translations "clm") '(("**;*.*.*" "Macintosh HD:bil:clm:**:")))
which means that I put the clm sources in a folder called clm
itself in a folder called bil, itself on a disk called
Macintosh HD.
Then save all.lisp, and in the MCL window,
(load "clm:all.lisp")
I hope eventually to get the C stuff precompiled and loaded
into a library, so nobody will have to run MPW explicitly,
but that currently seems to confuse MCL. Also, I'd like
to make the instrument C compilation automatic like it is
on other machines, but that appears to mean using "events"
and "scripts" on the Apple.
From: "Tobias Kunze" <tkunze@vader.kgw.TU-Berlin.DE>
Date: Sat, 10 Sep 1994 01:40:22 -0600
To: clefort@unix1.sncc.lsu.edu (Clinton R Lefort), cmdist@ccrma.Stanford.EDU
Subject: Re: clm & CM
>I have CM running, but have not been able to run stella properly...
You can't have cm loaded without stella, except for the degenerate
case that you wrote a build script of your own.
cm/build/build.lisp loads clm by loading ~clm/all.lisp so you should
edit this file first.
on my system, I load a custom file that defines lots of logical
hosts instead of the 'generic'
#+CCL (load "bil:lisp:clm:mac-pathnames")
that's all. I don't use any 56000 code, just the 'default'
settings in all.lisp.
If you run into any specific problems, feel free to mail me the
MCL error output.
Hope that helps...
From: "Tobias Kunze" <tkunze@vader.kgw.TU-Berlin.DE>
Date: Sat, 10 Sep 1994 01:52:11 -0600
Subject: Re: RE:clm & CM
>Could I run it on Mac IIx?
I'm not the person you wanted to speak to, but while i'm on the mic...
clm, as well as cm and cmn, runs on ANY mac that is supported by
MCL (that is, as far as i can remember any mac from the Mac+ on
running SSW 6.0.7 or higher with 4 MB RAM or higher--check the
file MCL-README in the cm source directory). Of course, you won't
want the whole package to run with only 4 MB of physical RAM.
The IIx, then differs from the 'normal' 68030 machines in that
it has a 68020 CPU which CAN be accompanied by a MMU to support
paged Virtual Memory (a 68020 WITH MMU is exactly equivalent to
a 68030 CPU [which in fact is a 68020 with buildt-in MMU]).
Thus, be sure to have AT LEAST 8 MB of RAM set aside for the MCL
image and off you go...
From: areece@merle.acns.nwu.edu
Subject: CM Build help needed: 486/Clisp/MS-DOS
To: cmdist@ccrma.Stanford.EDU
Date: Sat, 10 Sep 94 1:32:26 CDT
Hello. At the risk of coming across as an insufferable dullard in my very
first message to this distribution, I must make a plea for help. I have a 486
running Clisp under MS-DOS, and I would like to run CM. I have not met with
success thus far. If anyone has successfully installed using this
configuration, please send me detailed instructions.
Even if you have not done this exactly, but have an idea as to the problem(s),
anything would help at this point. So that you may better understand the
problem, a brief statement of the error:
I have tried using both Portable Common Loops and the CLOS patch included with
CM. I inevitably come up with the error "EVAL: undefined function
HANDLER-BIND."
I suppose the possibilities are 1) I have not correctly installed either PCL
or the CLOS patch (possible - the installation of PCL was a lengthy and
painful process not unlike whelping); 2) I have incorrectly configured the
build files in CM; or 3) I am not correctly loading the CLOS or PCL packages
prior to loading build.lsp.
I should have prefaced this by saying that I am a complete novice as regards
lisp - I can so far define a function to perform simple arithmetic on two
numbers, but not far beyond. I used the CM package at school and really liked
stella, and after several months of C, lisp was really more enjoyable. Was.
Thank you for taking the time to read this my message. If I ever do get this
running, I will document my success for all who would follow in this quest.
Cheers,
Aaron (areece@merle.acns.nwu.edu)
From: hkt@zkm.de (Rick Taube)
Date: Sat, 10 Sep 94 13:55:27 GMT+0100
Original-Received: by NeXT.Mailer (1.87.1)
To: areece@merle.acns.nwu.edu
Subject: Re: CM Build help needed: 486/Clisp/MS-DOS
>CM. I inevitably come up with the error "EVAL: undefined function
>HANDLER-BIND."
welcome to the wonderful world of public domain software! I dont know
which version of clisp you installed, and you didnt include a trace
of what you actually did, but my guess is that you are using an old
verion of clisp since it doesnt seem to contain handler-bind error
handling. so as a shot in the dark i would suggest that you get the
latest clisp binaries from:
ma2s2.mathematik.uni-karlsruhe.de
in the file:
pub/lisp/clisp/binaries/dos/clisp.zip
-rw-r--r-- 1 haible 1369912 Aug 28 12:28 clisp.zip
i would recommend that you NOT use pcl with clisp - cm can use the
native clisp clos and that results in a much smaller image.
i built cm in Clisp here on a 486 and at stanford on a pentium, both
times without problems so i know its possible. (I should warn you
that although clisp works, on my 486 it runs like a dog.)
If for some reason you still have problems, I could probably put a
tar of whatever clisp version i have on my ftp sever for you.
-hkt
Date: Fri, 16 Sep 94 08:30:53 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: clm and cmn
The new clm version fixes a bug in both src and resample
in the C case which would cause unwanted changes in the
sampling rate. Unfortunately this required a change to
the data layout in cmus.c, which means any instruments
using src or resample need to be recompiled, and users
of gcl/kcl need to remake libmus.a and gcl/kcl -- sorry
for the inconvenience.
At several people's request I'm in the process of making
a European (or rather, non-American) version of cmn --
I've added centimeters as a default unit, and the
default paper size in that case is 21 x 29.7 cm, which
I'm told is the norm; let me know of other such things.
"h" as a pitch name is problematic since "h" already
means half-note rhythm.
Also, *cmn-preview* changed so that it is easier to call
up Preview (or Yap) automatically from cmn. Other changes
recently involve rest names, subdivision brackets, and
complex meters.
From: Tobias Kunze <tkunze@gigant.kgw.TU-Berlin.DE>
Date: Sat, 17 Sep 1994 15:05:20 -0600
To: cmdist@ccrma.Stanford.EDU
Subject: hp box
does anyone have experience with the new hewlett-packard
712/60 or 712/80i workstations running nextstep 3.2 and
cm/clm/cmn under gcl or the like?
i had a look on the machine last week (but, alas, no lisp)
and it seems to be pretty fast (zooming)but still cheap.
(64 MB RAM, 300 MB HD, 20" RGB Monitor == $7,700)
From: E.G.Newton@iti.salford.ac.uk
Date: 21 Sep 94 13:25
To: cmdist@ccrma.Stanford.EDU
Subject: Beginner needs help!
Thanks alot to <areece@merle.acns.nwu.edu> for posing the question about
his problems building cm. I had the same problem to and many many thanks
to Rick Taube for suggesting the error. It came up with an error in the
:csound syntax and so I deleted that and the :midi build worked fine
much to my amazement since I have been trying since June.
Anyway now that it works I have just a few questions if anyone could help
me out I would be very grateful:-
1. None of the manuals for clisp are in ASCII so I am kind of at a loss.
Does anyone know of a translator/viewer program or does anyone have files
already in ASCII?
2. Is it possible to call a DOS shell from within stella/clisp? If so
could it run csound, or would there be memory problems?
3. When I type quit from stella I get placed at '>' prompt. Whatever
I then type seems to put me in the debugger Break-1 >. How do you
exit at this stage. I'm sure I've tried everything, and I always
have to reset the machine, which is not very practical!
4. I know little about this but is it possible to do anything with channel
information of MIDI ie. channel = instrument. I think MIDI 0 is
'channel-less', and MIDI 1 is not supported? Is this correct and if so
what do most users do? It said in the manual that channels were about
to be supported as threads. Does anyone know anything about this?
Stella is just what I have been looking for in terms of a composition
system and I hope that I can sort out these problems. Congratualations
to the people who have worked on making it so flexible and usable.
--Liz.
E.G.Newton@iti.salford.ac.uk
From: hkt@zkm.de (Rick Taube)
Date: Thu, 22 Sep 94 16:25:11 GMT+0100
To: E.G.Newton@iti.salford.ac.uk
Subject: Re: Beginner needs help!
Cc: cmdist@ccrma.Stanford.EDU
>1. None of the manuals for clisp are in ASCII so I am kind of at a
> loss.
Im not sure what manuals you are referring to, here is a listing of
the clisp documents that came with my version (Unix):
-rw-r--r-- 1 hkt 4873 May 1 01:06 README
-rw-r--r-- 1 hkt 4883 May 1 01:06 clisp.1
-rw-r--r-- 1 hkt 5830 May 1 02:27 clisp.man
-rw-r--r-- 1 hkt 14813 Mar 15 1994 clos-gui.txt
-rw-r--r-- 1 hkt 14156 Mar 15 1994 cltl2.txt
-rw-r--r-- 1 hkt 63603 May 1 01:08 inotes.txt
All of the .txt files are ASCII. Only the clisp.1 and clisp.man files
need nroff to format. I've included an ascii version of thses at the
end of this message.
>2. Is it possible to call a DOS shell from within stella/clisp? If
> so could it run csound, or would there be memory problems?
Boot clisp and then type: (apropos "SHELL"). If it shows the SHELL
function defined then it is theoretically possible. You will be able
to invoke csound, but I don't have any idea about memory limitations.
Also, my guess is that in DOS I the csound shell will have to finish
before clisp resumes.
>3. When I type quit from stella I get placed at '>' prompt. Whatever
>I then type seems to put me in the debugger Break-1 >. How do you
To quit CLISP use the (exit) function. Control-D also works in Unix,
try Control-Z on DOS.
-hkt
From: Tobias Kunze <tkunze@gigant.kgw.TU-Berlin.DE>
Date: Thu, 22 Sep 1994 17:40:36 -0600
To: E.G.Newton@iti.salford.ac.uk, cmdist@ccrma.Stanford.EDU
Subject: Re: Beginner needs help!
on the (4) topic:
Stella doesn't support the Midi type 1 File format. However, that
doesn't imply that you are stuck with "channel-less" midi files!
Format 0 means only that all events go straight into one single
track. That is, there is no Conductor track or the else. Channel
information will be preserved, however (tracks aren't "real" Midi
runtime messages nor a core Midi notion).
You can convert any format 0 file to format 1 using any commercial
available sequencer s/w.
Sorry, no idea regarding the clisp/dos problems.
From: areece@merle.acns.nwu.edu
Subject: Re: Beginner needs help!
To: cmdist@ccrma.Stanford.EDU
Date: Fri, 23 Sep 1994 02:26:53 -0500 (CDT)
Sorry for the poor formatting - I trust everybody remembers who said what.
>2. Is it possible to call a DOS shell from within stella/clisp? If
> so could it run csound, or would there be memory problems?
>. . . You will be able
>to invoke csound, but I don't have any idea about memory limitations.
csound would probably run in the generic DOS shell, but I wouldn't recommend
it. Calling command.com from clisp will not, in all likelihood, allow access
to extended memory. In fact, it will probably have to share low memory with
clisp, and so it would run VERY slowly (lots of disk caching). Exit clisp
first - it wastes enough time as it is.
>Also, my guess is that in DOS I the csound shell will have to finish
>before clisp resumes.
If you are lucky enough to be running Novell DOS 7, you could call another
shell and run csound there. Otherwise, this is true, so you may as well exit
clisp.
>3. When I type quit from stella I get placed at '>' prompt. Whatever
>I then type seems to put me in the debugger Break-1 >. How do you
>To quit CLISP use the (exit) function.
No such luck. This doesn't work in clisp/dos. My uneducated guess is that
clisp doesn't like the fact that Stella is exited (excited?) by typing "exit."
The actual error says that EXIT is not a defined function. Go figure. I will
try disabling stella's EXIT function next time I compile her, and see what
happens in this arena.
>Control-D also works in Unix,
>try Control-Z on DOS.
Control-Z works ok in DOS; at first glance, it appears to exit fairly
gracefully - all files properly closed, memory cleared, etc. Not that I have
_any_ clue about lisp's file-handling protocols!
By the way, I downloaded cm.zip about 4 days ago (from zkm, not stanford) and
it compiled in clisp ok, no errors, but tons o' warnings. Rick-I will send
you the warnings I got, but the phone lines are really awful here right now,
and it's a decent-sized file, so uploading will have to wait for now. Also by
the way, csound.lsp compiled fine this time, but when I tried to output to
.sco, I got a bunch of garbage. It looks like binary data - umm, it isn't
_supposed_ to do this, is it? Midi-file output works fine, though.
Regards,
-Aaron (areece@merle.acns.nwu.edu)
>From david@jaffe.com Thu Sep 22 11:33:42 1994
To: Tobias Kunze <tkunze@gigant.kgw.TU-Berlin.DE>
Subject: Re: Beginner needs help!
Cc: cmdist@ccrma.Stanford.EDU
>You can convert any format 0 file to format 1 using any commercial
>available sequencer s/w.
anyone with a NeXT machine can use the convertscore utility to change from level 0 to level 1 MIDI file (this is part of the Music Kit, but an old version is still included with NeXTstep for backward compatability. Or you can get a more up-to-date version as part of the Music Kit package from ccrma-ftp)
Example:
convertscore -m -o level1.midi level0.midi
This reads level0.midi and converts it to level1.midi (convertscore always writes level1 midi files, but can read any format.)
You can also convert to various other formats:
convertscore -s -o scorefile.score any.midi
to converts to musickit scorefile.
convertscore -m -o midifile.midi scorefile.score
to convert from musickit scorefile.
Date: Fri, 23 Sep 94 10:24:54 PDT
From: baker@jitterbug.ccmrc.ucsb.edu (Charlie Baker)
To: cmdist@ccrma.Stanford.EDU
Subject: clisp/cm
-Aaron (areece@merle.acns.nwu.edu) wrote about clisp/cm:
>(stuff deleted...) Also by
>the way, csound.lsp compiled fine this time, but when I tried to output to
>.sco, I got a bunch of garbage. It looks like binary data - umm, it isn't
>_supposed_ to do this, is it? Midi-file output works fine, though.
>
>Regards,
>-Aaron (areece@merle.acns.nwu.edu)
I ran into the same problem when I tried clisp to run cm on our sun (I went to akcl/gcl)
Thg problem seemed to be in the format to file commands of clisp.... don't remember exactly what
command was the culprit, but when I tried just outputing a line of text with that command, I got the same garbage,(looked like there was an extra byte of stuff on the front of every character)...rather
than hack clisp, I just changed the cm output routine to use another output command...this worked ok. Then I just got sick of it , and went to using akcl/gcl.
Good luck!
Charlie
---
*_________________________________________________________*
Charlie Baker
Center for Computer Music Research and Composition
University of California at Santa Barbara
baker@waltz.ccmrc.ucsb.edu
*_________________________________________________________*
From: hkt@zkm.de (Rick Taube)
Date: Sat, 24 Sep 94 06:25:11 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: Re: clisp/cm
E.G.Newton writes:
>No such luck. This doesn't work in clisp/dos. My uneducated guess is that
Maybe you are forgetting to quit the editor before attempting to exit lisp?? To exit from clisp when
inside the editor, first use the QUIT command to return to the clisp prompt, then use the EXIT funtion:
Stella [Top-Level]: quit
> (lisp:exit)
Charlie Baker writes:
>-Aaron (areece@merle.acns.nwu.edu) wrote about clisp/cm:
>>(stuff deleted...) Also by
>>the way, csound.lsp compiled fine this time, but when I tried to output to
>>.sco, I got a bunch of garbage. It looks like binary data - umm, it isn't
>>_supposed_ to do this, is it? Midi-file output works fine, though.
>>
>>Regards,
>>-Aaron (areece@merle.acns.nwu.edu)
>I ran into the same problem when I tried clisp to run cm on our sun (I went to akcl/gcl)
>Thg problem seemed to be in the format to file commands of clisp.... don't remember exactly what
If someone would send me a simple fail case I'll figure out what's going wrong.
-hkt
From: E.G.Newton@iti.salford.ac.uk
Date: 28 Sep 94 11:07
To: cmdist@ccrma.Stanford.EDU
Subject: Thanks..
X-Mailer: University of Salford cc:Mail/SMTP gateway 1.71
Encoding: 18 TEXT
Hi,
Thanks alot for all the help I got on my questions. They have proved
absolutely invaluable, and are all sorted out now. Special thanks
to areece for the DOS specific help; I can run csound from the shell
and it didn't seem too slow (not for short pieces anyway). Where is
the latest .zip file stored? I tried to compile the csound syntax
again but got the message :-
Compiling file c:\cm\stella\csound.lsp
*** - DEFCLASS: Cannot redefine class CSOUND-SCORE-FILE
1. Break>
Any clues as to this problem would be well appreciated, thanks everyone,
--Liz.
E.G.Newton@iti.salford.ac.uk
From: hkt@zkm.de (Rick Taube)
Date: Wed, 28 Sep 94 12:22:21 GMT+0100
To: E.G.Newton@iti.salford.ac.uk
Subject: Re: Thanks..
Cc: cmdist@ccrma.Stanford.EDU
>*** - DEFCLASS: Cannot redefine class CSOUND-SCORE-FILE
>1. Break>
this is a typo bug in stella/csound.lisp that i introduced by
copy-pasting. the problem is that there are now 2 definitions of that
class and for some reason this gets clisp so nervous that it breaks.
The version you want is this one:
(defclass csound-score-file (event-file header-mixin)
((orchestra :initarg orchestra :initform nil)
(output :initarg output :initform nil)
(syntax :initform (find-syntax ':csound))))
The fix is to delete the other one, then recompile the file an
rebuild the system. this bug has already been fixed in my sources .im
currently in the middle of an algoritmic compositino workshop ans the
participants have already uncovered 2 more bugs so ill wait till the
dust settles before putting new a new cm on the server -- probably
in about 2 weeks.
-hkt
From: royst@ERE.UMontreal.CA (Roy Stephane)
Subject: Lisp GCL on SGI
To: cmdist@ccrma.Stanford.EDU
Date: Wed, 5 Oct 1994 10:04:59 -0400 (EDT)
I would like to use CLM on Indy. Fernando
told me that there is a Lisp for Unix on SGI (the name
is GCL and it's public domain software) but I cannot
find it, does someone could tell me on which ftp site
is it?
Thanks
Stephane
Date: Wed, 5 Oct 94 12:14:03 PDT
From: baker@jitterbug.ccmrc.ucsb.edu (Charlie Baker)
To: royst@ere.umontreal.ca
Subject: Re: Lisp GCL on SGI
Cc: cmdist@ccrma.Stanford.EDU
It is formerly known as AKCL (Austin/Kyoto Common Lisp)...it can be found
at rascal.ics.utexas.edu. Compiles using your local c compiler, and actually,
it compiles all the lisp code into c before compiling and dynamically linking
it into the lisp image...
Good luck, and have fun!!
Charlie
Date: Thu, 6 Oct 1994 17:34:48 +0100
Content-Identifier: Re: Lisp GCL ...
From: Tobias Kunze <tkunze@vader.kgw.tu-berlin.d400.de>
To: " (Roy Stephane)" <royst@ERE.UMontreal.ca>, cmdist@ccrma.Stanford.EDU
Subject: Re: Lisp GCL on SGI
> does someone could tell me on which ftp site is it?
math.utexas.edu:pub/gcl/gcl.x.x.tgz
but be aware that gcl 1.0 does NOT run ounder Irix 5.2 or higher.
the problem is with unixsave.c and unixfasl.c, which expect coff object
files, but SGI has switched to the elf format.
you might try usings emacs' unexec.c and load (execld.c ?) files instead.
From: hkt@zkm.de (Rick Taube)
Date: Fri, 14 Oct 94 14:01:21 GMT+0100
Subject: cm release
I've put a new release of CM on ccrma-ftp.stanford.edu and ftp.zkm.de.
I'll always try to save archives in .Z, .gz, .zip and .sit formats. (If i
can get a copy of Stuffit Deluxe I'll switch from .sit to .sea for the Mac).
Date: Fri, 14 Oct 94 10:16:27 GMT-0700
From: bil (To: cmdist)
To: cmdist
Subject: parallel instruments in CLM
I've added a new kind of instrument to CLM: parallel, or
"sample-synchronous" to speak jargon. Each call on such
an instrument spawns a sort of C process, all such processes
running together on the same sample. See defpinstrument
in the documentation. These instruments are completely
compatible with normal (overlayed) instruments, and appear
to run just as fast. From the user's point of view the
only difference is defpinstrument for definstrument and
the calls in the note list have to be ordered by begin
time. The point of this was to make it possible for
instruments to communicate at run-time, but it may also
make it easy to add real-time controls.
Date: Wed, 2 Nov 94 06:53:25 PST
From: bil (To: cmdist)
To: cmdist
Subject: clm/cmn news
Nicky Hind has contributed a physical model flute.
CLM and CMN (as well as excl and gcl) appear to be
running fine in NeXTStep 3.3. CMN is now compatible
with case-sensitive-lower lisps.
Date: Wed, 2 Nov 94 10:30:51 PST
From: bil (To: cmdist)
To: cmdist
Subject: more clm news
Fernando Lopez Lezcano's dlocsig has been added to clm --
it provides simulation of moving sound sources. See either
dlocsig.wn or dlocsig.rtf for details.
Date: Thu, 3 Nov 1994 8:37:58 UTC
From: jjor@piec.xtec.es
Subject: Linux and CM/CLM
To: cmdist@ccrma.Stanford.EDU
Hello,
What about Linux and CM/CLM? Has somebody implemented the packages
with CLISP? I'm working with Linux and I find the system exciting, very
complete and CHEAP. If somebody is somewhere working with Linux and
music aplications I will be glad chatting with it.
JJOR <jjor@piec.xtec.es>
From: Rick Taube <hkt@guido.zkm.de>
Date: Fri, 4 Nov 94 06:11:36 GMT+0100
To: jjor@piec.xtec.es
Subject: Re: Linux and CM/CLM
Cc: cmdist@ccrma.Stanford.EDU
>What about Linux and CM/CLM? Has somebody implemented the packages
with CLISP?
cm runs in clisp as well as in gcl or akcl. i think all of these lisps have linux ports so cm should work fine in linux except that there is will be no midi dirver support. (i dont even know if linux HAS a midi driver!)
-Rick Taube
From: Rick Taube <hkt@guido.zkm.de>
Date: Wed, 9 Nov 94 08:39:36 GMT+0100
To: cmdist@ccrma.Stanford.EDU
Subject: cm release
Cc: hkt@guido.zkm.de
ive placed a new version of cm on ccrma-ftp and guido.zkm.de. Main new features are (1) a new pattern type called Rewrite implements rule-based term rewriting. useful for implementing musical finite automata, l-system etc. See dictionary.rtf and stella/examples/rewrite.lisp. (2) All the documentation under doc/ has been reworked and checked (thank you Tobias Kunze for helping): dictionary.rtf has a new format and many new entries, ditto midi.rtf. item-streams.rtf has been completly rewritten and serves as a sort of tutorial now. Most of the other docs have been encorporated or thrown out.
The macintosh archive is now cm.sea.bin, which should be easier to ftp and restore. Transfer in binary mode, then on the mac use "Download->Application" in BinHex5.0 to restore cm.sea, then just double click cm.sea to restore. You no longer need stuffit or have to debinhex mcl-midi.c.o.hqx.
-hkt
Date: Thu, 8 Dec 94 08:26:42 PST
From: bil (To: cmdist)
To: cmdist
Subject: CLM on Sun, etc
Thanks to Juan Pampin, CLM now runs on the Sun. Also, the
new version is compatible with case-sensitive-lower lisps.
Minor bugs fixed related to extremely long sound files,
Hawaii time, etc.
Date: Wed, 28 Dec 94 10:41:11 PST
From: bil (To: cmdist)
To: cmdist
Subject: float output from CLM, etc
CLM can now write any of the data formats it can read, including
32-bit float, mulaw, 32-bit linear, etc. New with-sound options
data-format and scaled-to -- the latter causes CLM to write 32-bit
linear output, then does a second pass scaling that file to the
scaled-to argument, so the composer doesn't have to worry about
clipping or figuring out how to juggle amps to get a particular
output maxamp. Fasmix has been extended to handle all possible
combinations of 1,2, and 4 channels in and out -- some of its
arguments have new names. Another new with-sound option is
save-stats -- it causes the file stats printed at the end of the
with-sound run to be inserted into the comment in the output
file's header.