Re: [Pythonsound-devel] Re: Python and music [was Re: New work, new tools] (fwd)

[Paul W. <sli...@ya...>]

Maurizio, I know you said you won't have time to deal with design
issues this month. That's OK. I'm using this forum to think out
loud... I hope you don't mind.

Some of this is redundant with previous posts I've made. I'm still
trying to get this all clear.

As I see it, pmask has no notion of "tempo" in the traditional
sense. "Density" serves a similar purpose, and can be made to change
over time, but traditional modes of composition are not supported.

OMDE seems to be a more general compositional framework, of which
pmask is only one specialized part. OMDE could conceivably support
many different approaches to composition. Therefore, I think it should
provide powerful tools for working with tempo, since time is the one
element common to all music.

I'd like to hear discussion of whether the following features are
desirable, and proposals for alternative ways to deal with tempo,
before we start talking about implementations.

What I want to be able to do with tempo
---------------------------------------

1) All tempo calculations are performed at run time ... i.e. not until
you ask omde/pmask for some output. Aggregates think of time in beats.

 Rationale: Maximum dynamism and introspective ability. You can always
 find the Events at the Nth beat of an Aggregate no matter what
 time-warping will eventually  be done to it. There should also be a
 method for asking what the absolute time of any particular event would
 be, so we can find out before we generate output.

2) Tempo control: The syntax is not so important to me, as long as
it's easy to specify both simple and sophisticated tempos. The stuff
you have in rythm.py looks nice. The csound t statement works pretty
well... it can be used for things as simple as "the tempo is now 120"
and as complex as "the tempo is 120 for 2 beats, then interpolates to
130 between beats 3 and 5, then suddenly is 40 at beat 5..." etc.

 Rationale: should be obvious - we want power!

The math for doing such time warping is not obvious, but fortunately
thanks to linux-audio-dev, I have working python implementation in my
old, pre-OO versions of pysco. This could be adapted to OMDE.


3) I want to be able to place a tempo control in an Aggregate that
will apply to the start and duration times of all enclosed events or
aggregates, RECURSIVELY. This makes things more complicated. To find
the clock time for any given event, its beat value must go through the
time-warping function of all its parent Aggregates.

 Rationale: I want the power to create complex rhythmic relationships,
 and I want it to still be easy to do trivial things. This is the best
 basic structure I've been able to think of. If only the top-level
 Aggregate is given tempo controls, then we can easily do traditional
 kinds of composition. If an Aggregate consists of Aggregates whose
 tempos are defined as ratios to the parent's tempo, we can do nice
 polyrhythms even with global accelerando and decelerando. And if each
 layer of Aggregates have their own accelerando and decelerando, we
 could have very interesting, complex, evolving time relationships.


4) An Aggregate should also be able to declare itself immune to tempo
alteration by its parent Aggregate, in case it wants to skip the
procedure described above and exist in an independent time stream.
This would mean that, while this Aggregate's start time is still
affected by tempo changes in its ancestors, nothing inside it is so
affected; as far as its children know, this Aggregate provides the
"top level" tempo control.

This behavior could simply be toggled by an attribute, such as
Agg1.use_parent_tempos = 1

 Rationale: OK, this one may not be very important, and it's hard to
 explain. But it could be a powerful feature. An Aggregate could thus
 say to its children, "You are free to do anything you wish... but
 don't start until I tell you."


5) Events could conceivably have other time parameters besides start
time and duration. How will these be affected by tempo
transformations?  This is the responsibility of the particular Event
class, but one useful framework might be if the class had a list of
which attributes are time-sensitive. At performance time, the Event
could go through this list of attributes and calculate the absolute
time for each.

-- 
................    paul winkler   ................
 custom calendars:   http://www.calendargalaxy.com
   A member of ARMS:   http://www.reacharms.com
        home page:  http://www.slinkp.com