Tempo, was Re: [Pythonsound-devel] Re: Python and music

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

On Thu, Oct 04, 2001 at 07:12:46PM +0200, Maurizio Umberto Puxeddu wrote:
> 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)

(examples snipped)

OK, that's all pretty cool. I think I could work with that.

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

Why? Nobody is forced to use tempo or density or whatever you want to
call it. I think csound is sensible about this: If no t-statement is
found, then times are interpreted as seconds. Remember that seconds
are an arbitrary measurement too, and not always appropriate for all
time measurements.

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

Agreed.

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

Now this is interesting. I haven't seen this mail yet, but MetaEvent
is a very provocative name. Looking forward to it!
 

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