Subject: Re: [linux-audio-dev] Musical language / OO design questions...
From: Paul Winkler (slinkp_AT_ulster.net)
Date: to tammi 06 2000 - 00:39:21 EST
Bill Gribble wrote:
>
> Paul Winkler <slinkp_AT_ulster.net> writes:
> > I'm hoping people on the list will comment on the following text.
> > It's the current state of my "thinking" about pysco, my python
> > module for composing in python. I'm not sure if this will all make
> > sense without looking at pysco... I hope so.
>
> I'm working on a similar project for a composition language based on
> Scheme. Just out of curiosity, what "prior art" do you find
> inspirational?
all kinds of things... currently I'm fascinated with repetitive
evolving music, not so much "minimalist" composers, but rather dance
stuff (particularly jungle/ drum'n'bass) and "ambient", especially
my current fave, Aphex Twin. But I also have had a desire for years
to compose beat-less music with the sonic equivalent of a spray can:
making clouds of events, mostly working with timbre and, for lack of
a better word ,varying "density" of sound. For this I'm more
inspired by visual art, particularly a couple Kandinsky paintings (I
don't remember titles) that have always looked like music to me.
> I have limited experience with computer composition
> tools and haven't found anything that is much more than a syntactic
> transformation of the csound score language.
The reasons I started this project are
a) trying to compose csound scores by hand drives me nuts
and
b) I haven't found a sequencer for Linux that I like yet. (Though I
haven't looked at Brahms since it became Brahms.) And some of my
ideas would be very hard to do with a midi sequencer, for instance
the cloudy stuff, or simultaneous independent tempo changes in
different event streams (already working in pysco!).
and
c) I'm too perverse to learn already existing languages like KeyKit
or CM, I'd rather spend 10X the time re-inventing it myself.
and
d) I never met a MOD tracker I liked
Since you're interested in scheme I wonder if you've looked at
Common Music / Common Lisp Music, which are (if I understand
correctly) dialects of common lisp intended for composition and
synthesis, respectively. Personally I still haven't got over the
"lisp is an alien language" stage, hence pysco. But I have been
looking over the CM documentation for cool ideas for pysco.
> Notes about your ideas:
>
> > I think I can reduce everything (chunks, events) down to subclasses
> > of a superclass, let's call it Event.
>
> Well, of course you CAN do this; the question is, do you really want
> to? If so, why?
I think it will make it easier to invent new kinds of events as the
situation arises. For instance a "cloud" event which takes some
parameters and generates a bunch of events from them. Sure, that
could be done with a cloud() function, but I'm getting interested in
the object-oriented approach.
Let me shoot a question back at you: If not, why not?
> What I see in your document is a blueprint for the
> structure of the code, and for the data structures that represent the
> passage of time/events in the score, not for the structure of the
> composition metaphor you are trying to implement. How do you think
> the composer will interact with the tool?
So far, by importing the pysco module into a python script which
generates a csound score.
The main problem I've found with this approach is that it is very
easy to quickly lose track of what parts of your script correspond
to what parts of the resulting sound.
In the future, I think a lot of the same data structures and
functions / objects / whatever would be useful in interactive
applications, such as sequencers. I think that would be a neat
trick: a sequencer that comes with a built-in well-developed
extension language because it IS that language.
> How much of the score do
> you see being automatically generated versus manually composed?
Well, if I wanted to manually compose *everything* I wouldn't bother
with python at all, I'd just use Csound.
> > track.play.repeat( count, [args to play()...])
> > track.playlines.repeat(5, my_event.get_beats(...))
>
> I don't know Python, but I presume this is Python code,
Yes, although the particular example above is, I think, nonsense.
> meaning you
> are trying to write a Python library/API for generating scores, not a
> new language that's implemented within Python.
Right.
> That's a perfectly
> valid decision, but be aware that it *is* a decision; you have the
> alternative of designing the syntax you want from scratch and then
> writing code to implement it.
Pysco started as Pscore, a Perl module with some of the same goals.
Originally Pscore was intended to be a sort of score-compiler that
would read a score file in a new little language and go from there.
But then I realized that every time I want to try something new,
even if it's a one-time throwaway automation of some process, it
would have to be implemented in the module before I could put it in
the score. Instead, I design a module instead of a language, and
automatically get access to everything that language offers.
While I flatter myself that I know enough to write an ambitious
python module, I'm pretty sure that any language I designed from
scratch would be pretty clunky and shortsighted.
> This is one reason I'm using Scheme;
> it's easy to use the syntactic transformation abilities of the
> language to implement "mini-languages" that can be as sophisticated as
> you want as long as you can handle having parentheses around things.
Sounds cool. But yeah, all those parentheses confuse me.
> > play() and the like: are these methods of tracks that play events?
> > Or methods of events that play IN tracks???
>
> Make sure that you don't get the PLAYING of a score too tangled up
> with (1) the program that generates it, or (2) the data structures
> that represent it. These are very separate questions,
Aha, I think (2) is where I was getting a bit garbled. So far pysco
has been written with functions, not methods, and when I want to
generate a note with a certain timestamp I say something like
"playnote(blah blah...)" and variants of that. I think this is a
conceptual error. Maybe it should be more like "makenote(blah blah
blah)", or in OO terms "event.make(blah blah blah)"...
hmmm, is there a better term than "make"? Maybe I should explain
what I expect this function / method to do. It should place an event
in an output stream. I hope to eventually be able to use this for
EITHER generating a file with timestamped events (a csound score or
MIDI file or whatever), OR for sending streams of realtime events to
a device (MIDI device, and/or a pipe for Csound to get score events
from, and/or controlling a Mucos plugin, or ...). Selecting the
output destination(s) should be as simple as setting a cmd-line flag
to the python script, or changing a line in the script, or ticking a
button on a GUI yet to be developed... pysco should take care of
what to do with events automatically based on this selection.
So when the current version of pysco says "play()" it was intended
that this should eventually mean "either send this event to a
device, OR write it into a file." Currently due to my confusion it
does neither: it places the event in a new data structure called
Out, so I can post-process time parameters according to tempo maps;
once there, I call play_Out() to actually write the output file,
which really goes to show that I mean way too many different things
by "play".
I think I had better start playing with realtime output quickly or I
will code myself into a corner. There are a lot of things that do or
don't make sense depending on what type of output you're generating,
and I need to make sure I can handle both streams and files...
(yes, I am fully aware that some events that work with writing to a
file are impossible in realtime, and probably vice versa. For
example, my current implementation of tempo warping would not work
at all in realtime streams.)
-- ................ paul winkler .................. slinkP arts: music, sound, illustration, design, etc. A member of ARMS -----> http://www.reacharms.com or http://www.mp3.com/arms or http://www.amp3.net/arms personal page ----> http://www.ulster.net/~abigoo
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST