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

[Maurizio U. P. <um...@ti...>]

On Thu, 4 Oct 2001, Paul Winkler wrote:

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

To be honest, density is a name I adopted from Cmask but is not a density
at all. The temporal density is frequence (which dimensionally is [t]^-1)
and the density used by Cmask is a time. In fact in the new
pmask.algorithm module (which for backward compatibility is accessible
from the pmask module too), contains no longer this term, replaced by dt
or something similar.

I wouldn't say traditional rhythm is not supported by pmask.cloud(). You
can use (I have to clean the syntax, somehow)

# kind of zum-zum pa
onset = List(*rythm2onset(8, 8, 4))

then use pmask.sequence() instead of pmask.cloud().

Of course you can also do

# kind of zum-zum pa    pa   zum-zum
onset = List(*rythm2onset(8, 8, 4), mode='swing-repeat')

or if you want a some "feel"

onset = List(*rythm2onset(8, 8, 4), mode='swing-repeat') * Range(0.95,
1.1)

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

I feel like that pushing your concept of "tempo" inside the current
classes of OMDE you would end carrying inside another concept: pulsation.
It is true true that concept of tempo can be applyed to every kind of
music if you generalize it enough: it is called event density, which is
local. But not all music have a pulsation: some of the have it expressed,
some implied, some have no pulsation at all.

I think that if you need an Aggregate with tempo, you could use
the function-costructor idioma (passing a function as constructor to
cloud() or sequence()), like I'm doing right now, and
help me to formalize it in the PseudoEvent or MetaEvent classes, as I
described in a mail that I'll forward.

The ideas you expressed could be all implemented that way, I think.

Let me know if it can work for you.

Regards,
Maurizio Umberto Puxeddu.