On Thu, 27 Sep 2001, Paul Winkler wrote:

> My next big plan on this path is support for nested time
> relationships.  E.g. wild weird things like this:
>
> object X has a tempo of 1/2 its parent object's tempo.
>
> Object Y has a tempo of 2/3 its parent object's tempo.
>
> Wrap X and Y in a container object, C, whose tempo starts at 60 bpm,
> then takes 16 beats to accelerate to 120 bpm, then stays at 120 bpm.
>
> If each object, when played, merely makes a tick on each beat, you'll
> hear something like this (please excuse bad ASCII art):
>
>
>  time in seconds (approximate, I haven't done the math)
> 0           1           2            3            4            5
> ----------------------------------------------------------------------
>
> C         C         C      C     C     C    C   C   C  C  C  C C C CCC
>
> X                   X            X          X       X     X    X   X X
>
> Y            Y          Y        Y       Y     Y    Y   Y   Y  Y  Y YY
>
>
>
> Can you say polyrhythms?
>
> I don't know if that makes any sense to anyone other than me, but I'm
> pretty pysched about it... if only I can figure out the implementation!

If I understand correctly what you want, using OMDE/pmask you'd write this
way (more or less):

from omde.score import Aggregate, I
import pmask, pmask.bpf

begin, end = 0.0, 10.0
density = pmask.bpf.LinearSegment((begin, 1.0), (end, 0.5))
duration = 0.1

r1 = pmask.cloud(begin, end, 1, density, duration)
r2 = pmask.cloud(begin, end, 2, density * 0.5, duration)
r3 = pmask.cloud(begin, end, 3, density * (2.0 / 3.0), duration)

polyrythm = Aggregate(r1, r2, r3)

This is the simplest case of course.
Here the event has no parameters but onset and duration. You could
as well make a constructor for this complex object
(parametrizing the reference density and other parameters), use
generic_cloud to build a polyrithm of more complex objects, the "out
of time" version of the generator (� la Csound, just syntactic sugar,
it is instanced and mapped in a defined time range inside cloud()),
more complex relationship beetwen densities, omde.rythm to indicate rythm
with traditional duration symbols (not in second but similar to Lilypond,
I mean) and something more.

The omde.rythm notation for rhythm (yes, there is a typo in the module
name...) will probably get the same of the Score11 rhythm statement
notation. This because the latter is more complete and because I'll
probably have a Score11 implementation in Python/OMDE/pmask (~60% now).
It translates a Score11 file into OMDE/pmask objects, then renders them as
OMDE object and optionally prints them as Csound scores.

Maurizio Umberto Puxeddu.

Reply via email to