[linux-audio-dev] Musical language / OO design questions...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Musical language / OO design questions...
From: Paul Winkler (slinkp_AT_ulster.net)
Date: ti tammi  04 2000 - 01:30:30 EST


Hi,

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.

OOP IDEAS for Pysco
-------------------

I think I can reduce everything (chunks, events) down to subclasses
of
a superclass, let's call it Event.

An Event has only 2 required characteristics (stored as attribures):
1) start time.
2) a list of events nested within this event. This list can, of
course, contain any number of events (including none).

Subclasses of Events
--------------------

1) events with no duration: useful for function tables,
interpolation
   markers (see below), etc. This may not require a separate
subclass;
   we could treat it as one of the 2 others, simply ignoring the
   duration information.

2) events with a known fixed duration: useful for events which have
   characteristics that depend on duration (e.g. csound-style
   envelopes, tempo maps (like csound t statements), etc.)

3) events with unknown duration: useful for held notes, or for
realtime
   streams such as MIDI streams, when we don't know when the note
will
   turn off until it's off. Also useful for my tempo_marker() and
other
   similar things (e.g. anything else you might want to
interpolate).

What's in an Event?
-------------------

Events contain any number of any of the following:

1) other events, nested to any depth.

2) function or method calls that return events. Useful if some
   parameters of events depend on such things as the current beat
   time or other dynamic global data.

3) anonymous events (raw data to use for events; you don't want to
always
   have to have a name for every note!) ... needs more thought.

Event attributes
----------------

Event.start is a float that gives the starting time (assumed to be
in
raw beats) of this event.

Event.dur is a float that gives the duration (in beats) of this
event. If the event contains more events, this does NOT have to
equal
the time at which the last contained event ends; it is possible to
use
Event.dur to specify, for example, a phrase that leaves the clock 4
beats after it starts but keeps playing for any length of time after
that (or before, for that matter!).

Event methods
-------------

Event.sort() should by default sort all contained events by start
time. But
you should be able to specify other things to sort by (other
attributes, etc.)

get_beats() and the like become methods of container events.

***************************************************************
QUESTIONS:

Now[Track] is accessed as Track.cur_beat??

Out{} could be replaced with a class, output_sco, which provides
warp_all(), sort_all(), and play_all() methods, replacing those
functions.

namespace question:
play() and relatives could be subclasses that define a repeat
method:
        track.play.repeat( count, [args to play()...])
        track.playlines.repeat(5, my_event.get_beats(...))

In this case, play.__init__ would do the work? Does that work??
I think not.
Or maybe: see "Learning Python" pp. 187-188 re. methods, classes, &
nested scopes .... not sure if that helps?
maybe it could look like:
       repeat(3).track.play(chunk)
????

...hmmm, there still needs to be a way to conveniently repeat more
than 1 statement. Sure, I can always do that with "for..." loops,
but I want
nicer syntax since I do it so often.
I could pass the funtions / class-methods to repeat as strings, and
eval them, but that looks a bit ugly. Can't think of another
solution.
Might not be so bad... like this:

        repeat(3,
        """
        track.play()
        track.rest(8)
        """
               )

BIG QUESTION:
play() and the like: are these methods of tracks that play events?
Or methods of events that play IN tracks???

e.g.:

        verse = event(a bunch of notes...)
        basses = track()

Now, is that going to be:

       verse.play(track="basses")
OR
        basses.play(event="verse")
?????

I really need to take the time to think over the ramifications of
each
way of doing it...

e.g. if play() is a method of tracks: then set_track() will be
obsolete, as you'll always specify the track...

          track1.play("break")
          track1.play()
          track1.play.repeat(2, "chorus") # not sure about this...
                                          # repeat as a class???
          track1.playlines(chorus.get_beats(3, 4))
          track1.tempo.mark(tempo)

but if play() is a method of chunks: something like set_track() is
still needed. Also, the idea of "current chunk" disappears... so we
always have to type chunk name.

       Track.set("track1")
       break.play()
       break.play() # no more default chunk name...
       chorus.play.repeat(2) # don't know how to do that...
       chorus.playbeats(3, 4)
          track1.play("break")
          track1.play()
          track1.play.repeat(2, "chorus") # not sure about this...
                                          # repeat as a class???
          track1.playlines(chorus.get_beats(3, 4))
          track1.tempo.mark(tempo)

but if play() is a method of chunks: something like set_track() is
still needed. Also, the idea of "current chunk" disappears... so we
always have to type chunk name.

       Track.set("track1")
       break.play()
       break.play() # no more default chunk name...
       chorus.play.repeat(2) # don't know how to do that...
       chorus.playbeats(3, 4)
       track1.tempo.mark(tempo)
       
Looks like a tradeoff: one way, you always have to give the event
name; the other way, you always have to give the track name.
Question is, which is easier to read? Do we always want to know what
track we're in? Or would we prefer to always know what named event
we're playing?

-- 
................    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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST