Re: [Pythonsound-devel] Re: Python and music [was Re: New work, new tools] (fwd)
Status: Beta
Brought to you by:
mupuxeddu
|
From: Maurizio U. P. <um...@ti...> - 2001-10-04 17:15:14
|
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. |