Subject: Re: [linux-audio-dev] Musical language / OO design questions...
From: Bill Gribble (grib_AT_cs.utexas.edu)
Date: ke tammi 05 2000 - 09:56:03 EST
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? 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.
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? 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? How much of the score do
you see being automatically generated versus manually composed?
> 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, meaning you
are trying to write a Python library/API for generating scores, not a
new language that's implemented within Python. 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. 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.
> 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, and you might
want to consider the ramifications of live performance control via
MIDI or other control means. You might have sequences/programs tied
to midi signals or keypresses or other means that you can't predict
right now, so keeping the policy of how and when to play separate from
the score is a good idea.
Good luck! Keep the list informed on how it goes.
Bill Gribble
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST