pythonsound-devel Mailing List for The Python Sound Project (Page 3)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Thank you very much for the work! I'm in a hurry. I'll reply you
completely and commit it tonight or tomorrow.

Maurizio Umberto Puxeddu.

Hello.

I attached a pair of Python scripts named cvsget and getomde.

They are Python scripts. If you don't have and don't want to (or can't)
install Python, it does nothing useful to you.

cvsget.py its a very quick and dirty hack which connects a CVS repository
with anonymous access and "downloads" a particular directory tree. cvsget
really sucks but someway works. Do not look the source, you could
get sick.

getomde.py uses cvsget to "download" the development version of OMDE/pmask
from the pythonsound CVS repository on SourceForge.
Windows or Mac people should be able to use it by doubleclicking the
getomde.py icon (never tested there, please report bugs).

If you want to use it with something else than OMDE/pmask
use the following syntax:

cvsget.py [host] [root] [username] [password] [cvsdir]

or change/imitate the getomde script. For SourceForge based projects,
you can get the all the relevant information in the CVS page of the
same project.

Hope this helps,

Maurizio Umberto Puxeddu.

I'm still exploring omde/score.py, which seems to be the area that
largely overlaps my pysco ideas. I thought as long as I'm trying
things out to see what they do, I might as well save my test cases and
add a doctest hook to the module. In the process, I found a few things
that I'm pretty sure are bugs and took the liberty of fixing them.

The attached diff is against cvs of today, Oct 6, 19:50 UTC.

Notes on changes:

- General modifications:
  * Added many tests to docstrings.
  * Added _test() to run doctest on the docstrings.

- Event:
   CHANGED: Changed all spellings of "strech" to "stretch".
   FIXED BUG: stretch_absolute_backward used 'alfa' should be 'time'
   FIXED BUG: stretch_relative_backward used 'alfa', should be 'alpha'
   FIXED INCONSISTENCY: stretch_relative_backward was always returning floats; 
	other methods return ints if given int arguments. Should be consistent.

- F:
  BUG FIXED: but maybe it was a feature.... but if F(number=None),
    it's free to choose a number that was already specified by the user.
    I changed it to keep track of all used numbers and choose the lowest
    unused number.

  BUG FIXED: F.end() added, to always return F.onset instead of F.duration
    (which is actually not duration but table length).
     Using F and I polymorphically would not have worked.

- Aggregate:
  BUG FIXED: removed first definition of load() ... it was defined twice
    and the first looked broken.

  ADDED: append() which adds one object to the list.
    We have extend(), why not continue the list metaphor?

  BUG FIXED: extend() had the wrong order of arguments to isinstance()

  CHANGED: saveAs to raise a proper TypeError if wrong argument given

  CHANGED: deepcopy() wasn't returning anything.

  BUG FIXED: clone() was missing, though some other methods use it.
   I assume it's the same as deepcopy. One name should be used throughout.

  SUGGESTION: a shorter name for calculate_onset_min_max, et al, 
   would be get_onset_min_max.

  BUG FIXED: calculate_onset_min_max always returned None as minimum.

  BUG FIXED: calculate_begin_end always returned None as the start.

  BUG FIXED: calculate_onset_min_max, et al. will now work with
	classes that derive from both Event and Aggregate.

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

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

On Thu, Oct 04, 2001 at 10:34:21PM +0200, Maurizio Umberto Puxeddu wrote:
> On Wed, 3 Oct 2001, Paul Winkler wrote:
> 
> > On Wed, Oct 03, 2001 at 03:52:40PM +0200, Maurizio Umberto Puxeddu wrote:
> > > On Mon, 1 Oct 2001, Paul Winkler wrote:
> > I'd still like to discuss whether objects should be responsible for
> > their own start time, or delegate that to a parent Aggregate.  When
> > you get a chance, I'd like to hear your reasoning for making each
> > event responsible for its own start time.
> >
> > The only argument I can see *against* giving this responsibility to
> > the parent (the containing Aggregate) is that it requires you to have
> > a top-level Aggregate to control your composition's overall
> > structure. This might be seen as inconvenient; "I know when this
> > object should start, I want to say so when I create the object."
> 
> This is not a problem, with me at least.
> The problem is an that you can't perform onset-related operations
> on an object without interacting with its container (as a trivial
> example, translation).
> At the moment, in OMDE you can put an object in a container and
> still intermixing direct operations on the object and operations on the
> container as a whole, that is:
> 
> e = Event()
> 
> a = Aggregate(e, f, g , h ,i)
> 
> a.strech()
> e.translate_relative(-5)

I'm guessing that you mean " e's start time is now 5 less than it
was".

Oh, wait - I see, you're referring to Event.move_relative from
score.py.

> How do you perform a translation of an object in your way?
> 
> a.translate_object_relative(a, -5)
                              ^ 
Do you mean                   e ?

> Doesn't works, because, as you said, you want to have several copies of
> the same event.

Why not? Just look through the sub-objects and test if each one "is"
e. This will have exactly the same effect. If copies (rather than new
references) were made, they wouldn't be changed in my approach or in
your approach. I don't see a difference here, except that my approach
is much less efficient if there are many sub-objects.

> You have to do something like
> 
> a.translate_object_relative(123, -5)
>
> where 123 is probably the index of the object in the list of tuples
> (onset, object) like
> 
> a.list
> 
> This is good for a GUI, where you click on the windows, calculate the
> coordinate of an event, find it on the list and keep its index.
> Not so good with a script.

Point taken. In my proposal, it is potentially hard to find an event
inside an aggregate if there are multiple references to it in there.
In your approach, that just wouldn't happen; multiple references would
serve no purpose since they by definition start at the same time and
do the same thing, so the composer just wouldn't do that.

On the other hand, it's still quite easy to lose track of individual
events in your approach; this could happen anytime an Aggregate
contains anonymous Events, e.g. created by pmask.cloud(), or if the
composer does something like

a = Aggregate(Event(), Event())

It could also happen if the name for the event in question gets
re-bound after the Aggregate is created.

But having said that, I concede that you have a slight advantage here.

If we *really* need guaranteed ability to find an event within an
Aggregate, no matter what happens, then we could always create an
Aggregate subclass that stores its sub-events in a dictionary, so each
one must have a unique key.

As for the organizational clarity of my approach, I've realized that
it can be had via a factory function:

def needs_a_good_name(*args):
    result = Aggregate()
    for t in args:
         at, event = t[:]
         e = copy.deepcopy(event)
         e.onset = at
         result.add(e)
    return result

> > As further purely anecdotal evidence, I'll note that the author of
> > Blue does it my way. :)
> 
> In fact Blue its GUI driven!
> Are you in contact with him or did you read the sources of Blue?

Neither - I read the PDF documentation, and in fact I read it wrong!
From the docs:

""" In the lower area, the soundObject s editing interface is
shown. For a genericScore object, it is a text area for inputting
i-statements. The score input into a genericScore are always from time
zero. However, when a CSD file is generated, the times of the
i-statements will have the start time of the soundObject added to it
...  """

So in fact, the input here is just some text representing i
statements, and they don't have to start at zero. So in fact I have no
idea what happens internally in Blue with nested objects.

> I always thought of Blue as the obvious user interface for OMDE/pmask.

It's definitely an appealing approach. But one great thing about doing
this work in python is that we can have as many interfaces as we like;
it's easy enough that it's not inconceivable to develop a custom
experimental GUI for each composition!

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

On Wed, 3 Oct 2001, Paul Winkler wrote:

> On Wed, Oct 03, 2001 at 03:52:40PM +0200, Maurizio Umberto Puxeddu wrote:
> > On Mon, 1 Oct 2001, Paul Winkler wrote:
> I'd still like to discuss whether objects should be responsible for
> their own start time, or delegate that to a parent Aggregate.  When
> you get a chance, I'd like to hear your reasoning for making each
> event responsible for its own start time.
>
> The only argument I can see *against* giving this responsibility to
> the parent (the containing Aggregate) is that it requires you to have
> a top-level Aggregate to control your composition's overall
> structure. This might be seen as inconvenient; "I know when this
> object should start, I want to say so when I create the object."

This is not a problem, with me at least.
The problem is an that you can't perform onset-related operations
on an object without interacting with its container (as a trivial
example, translation).
At the moment, in OMDE you can put an object in a container and
still intermixing direct operations on the object and operations on the
container as a whole, that is:

e = Event()

a = Aggregate(e, f, g , h ,i)

a.strech()
e.translate_relative(-5)

How do you perform a translation of an object in your way?

a.translate_object_relative(a, -5)

Doesn't works, because, as you said, you want to have several copies of
the same event.
You have to do something like

a.translate_object_relative(123, -5)

where 123 is probably the index of the object in the list of tuples
(onset, object) like

a.list

This is good for a GUI, where you click on the windows, calculate the
coordinate of an event, find it on the list and keep its index.
Not so good with a script.

You should have to tag one to one each event...

> As further purely anecdotal evidence, I'll note that the author of
> Blue does it my way. :)

In fact Blue its GUI driven!
Are you in contact with him or did you read the sources of Blue?

I always thought of Blue as the obvious user interface for OMDE/pmask.

Maurizio Umberto Puxeddu.

Just fixed a very idiot bug. You probably want to do a cvs update.

Sorry,

Maurizio Umberto Puxeddu.

On Thu, 4 Oct 2001, Paul Winkler wrote:

> But setup.py install fails at this point:
>
>
>   creating /usr/local/share/omde
>
>   exceptions.SystemExit
>   error: can't copy 'omde/scales': doesn't exist or not a regular file
>
> I copied scales from my copy of pmask-0.12 and put that in omde,
> re-ran setup and it finishes fine.

the omde/scales file is a binary version of the SCALA database and I don't
put it in the CVS. However it doesn't change very often and you can re-use
old copies as long as I don't change the relevant class in omde.pitch.
If this happens, you should download the SCALA database and use the
makeScalaDB utility indicating the directory of the unzipped database.
From the main omde directory:

utility/makeScalaDb /path/to/the/unzipped/scala/database

Maurizio Umberto Puxeddu.

On Thu, Oct 04, 2001 at 06:36:06PM +0200, Maurizio Umberto Puxeddu wrote:
> On Thu, 4 Oct 2001, Paul Winkler wrote:
> 
> > I have CVS checkout of OMDE/pmask from Oct. 1 2001.
> 
> It's ancient! I made all kind of changes in the meantime! :)

OK, just updated... I see you fixed "rhythm" :)

But setup.py install fails at this point:

  creating /usr/local/share/omde

  exceptions.SystemExit
  error: can't copy 'omde/scales': doesn't exist or not a regular file

I copied scales from my copy of pmask-0.12 and put that in omde,
re-ran setup and it finishes fine.

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

It's an answer to a mail asking what it pmask.

---------- Forwarded message ----------

About OMDE/pmask

pmask is a set of Python (www.python.org) modules for numeric score
generation. Its first releases had basically the same set of algorithm
present in Cmask by Andre Bartezky.

The difference between Cmask and pmask is:

-in Cmask is a dedicated language: it is quite simple, but not flexyble
-in pmask you write Python programs: it is just a bit complex but you gain
in flexybility.

I think that writing in Python (using pmask) the equivalent of a Cmask
program is not more complicated that the original, it is only that you
have to type more.

Flexibility means that:
-you can add more basic components (generators)
-you can mix Cmask-like generation algorithms with other totally
different score generation or processing algorithms
-you can apply the same tool to similar kind of problems (3d graphics and
probably 3d graphic animations)

In successive releases pmask in fact added more generators (not present in
Cmask) and a additional step, very simple (like everything in OMDE/pmask)
but very important: events were no more stored as strings but in dedicated
Python objects.

Of course you can print one of such object and get the standard numeric
score notation for event, but you can also operate easily on that
object in order to post-process them, aggregate it with other objects and
operate on such groups of objects.

At this point I wanted to make a distinction between the way you produce
the score events (pmask) and the way you rapresent and process them
(OMDE). This is way I refer to the current development version of "pmask"
as OMDE/pmask.

For example: the Event and Aggregate classes are in omde.score, the
cloud() or sequence() algorithm are in pmask.algorithm (or in pmask) and
generator and modifiers (the difference in pmask is less important) are in
places like pmask.rng (pseudo random number generators), pmask.chaos
(non linear generators), pmask.miscellaneous (List, Mask, Quantizer,
Attractor, Choice etc).
Someone else could use something completely different to produce OMDE
objects than pmask and the continue the processing using OMDE or other
OMDE-enabled tools.
OMDE has also modules for pitch (omde.pitch, integrating the
SCALA database of scales) and rhthm (omde.rhythm), both of which have room
for being greatly extended and improved.

The CVS version OMDE/pmask includes contributions by prof. Zipfel in the
omde.pitch and omde.rythm and a new omde.plot module to plot PDF sketchs
out of your composition. Additional work is  required in order to really
integrate these features.

This OMDE rapresentation of events as objects relies on the Python
language object model. Going a step further, it opens the door to more
abstract kind of musical objects, always espressed as Python objects.
These objects are not directly mapped into score events but into whole
groups of events and their properties are not the list of properties of
the single events but properties of the set as a whole. This is a
different kind of thing from the "aggregate" above and is not implemented
at the moment in OMDE/pmask even if I'm already using a less formalized
(and less functional) implementation of this idiom.

The nice thing is that you can use the same tools to generate score
events, aggregates (via a proper contructor) or such kind of meta-event.

Since many people potentially interested in OMDE/pmask comes from other
algorithm or computer assisted composition experiences (Cmask, SCORE11
for example), I'm starting to think that could be useful to add "native
languages" parsers and converters inside OMDE. Such languages are very
simple in general so it is feasible. I already studied SCORE11 and
implemented the parser and part of the convertion of SCORE11 in pmask
objects.

Hope this helps,

Maurizio Umberto Puxeddu.

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.

On Thu, 4 Oct 2001, Paul Winkler wrote:

> I have CVS checkout of OMDE/pmask from Oct. 1 2001.

It's ancient! I made all kind of changes in the meantime! :)

> It's missing functional.py.

Some time ago pmask was in the omde module hierarchy as
omde.functional.*

There should be no more omde.functional occurrence in the current CVS.

Maurizio Umberto Puxeddu.

I have CVS checkout of OMDE/pmask from Oct. 1 2001.
It's missing functional.py.

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

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

Hello Hans.

I just ported your pmask.chaos module to OMDE/pmask without any test.

I also changed few details to improve performance or coerence with the
behaviour of other components of OMDE/pmask.

Could you double-check the code?

Regards,

Maurizio Umberto Puxeddu.

The POVRay extestions to pmask by Hans Mikelson have not been already
ported to OMDE/pmask (but it is not that work).
I think that with the new syntax of pmask.cloud() and pmask.sequence() and
with the use of generic contructors (other that I for Csound i
statements), Hans should be more free.

I definitely have to learn POVRay!

---------- Forwarded message ----------
Date: Wed, 3 Oct 2001 03:18:52 +0200 (CEST)
From: Maurizio Umberto Puxeddu <um...@ti...>
Reply-To: cs...@li...
To: cs...@li...
Subject: Re: [Csnd] Pmask manual

On Tue, 2 Oct 2001, Hans Mikelson wrote:

> > Also it would be nice to extend them for animations
> > > that would make use of the time variable.
> > Could you explain this better?
>
> The POVRay extensions I added to pmask make no use of time except as a loop
> counter.  This is fine if you are just rendering a scene.  If you want to do
> an animation you would want to have the objects you defined changing over
> time.  Moving, getting bigger or smaller, flocking, rotating, etc.  I think
> animations may use something like 10-60 frames/sec.  I haven't really done
> many animations in POVRay but it would seem to make sense to do the modeling
> at a higher level and just use POVRay as the rendering engine.

I have never used POVRay with or without pmask.
If I understand correctly you used the "time" field to index of different
object in the scene as if each object was an "event". Now you are
proposing to use event as frames.

I'm not able to see the problem as I have no direct experience. I can only
point that you should have less problems since in OMDE/pmask in are not
create ScoreSection using a cmask-like generation model. In OMDE/pmask
there are Aggregate (omde.score.Aggregate) that can be filled using one of
many algorithms. If you want to generate a cmask like cloud, instead of
using something like

section = ScoreSection(start, end, instrument, ...list of generators...)

you create a Aggregate using the pmask.cloud or pmask.generic_cloud
algorithms

a = cloud(start, end, instrument, ... list of generators ...)

but you can also use pmask.sequence (variation of cloud) or your own
algorithm using pmask generators or something else.

You should have more freedom to include POVRay specific algorithms.

Maurizio Umberto Puxeddu.

-- 
To unsubscribe, send email to cso...@li...

The __doc__ stringn example below is already obsolete!

---------- Forwarded message ----------
Date: Tue, 2 Oct 2001 00:08:09 +0200
From: um...@ti...
To: cs...@li...
Cc: um...@ti...
Subject: Re: [Csnd] Pmask manual

On Mon, 1 Oct 2001, Gabriel Maldonado wrote:
> Does it exist a Pmask manual? If it does, where can I get it?

The short answer is: no, there is no decent manual for pmask, only few examples in the examples/ directory.
Moreover the development version of OMDE/pmask, available via CVS as
described here

http://sourceforge.net/cvs/?group_id=15938

is different in several ways from the last release (probably 0.12).
If you
The first release as OMDE/pmask will be fully documented with doc-strings.
This means that you are (in some cases now, in all cases in future) able to
get info about a class or a function this way:

[maurizio@maderna Bocca2]$ python
Python 2.0 (#2, May 22 2001, 11:42:51)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import pmask
>>> print pmask.cloud.__doc__

    Generate an Aggregate of events using the cmask generation model.
    You can use any callable as event generator using

    Class = Contructor

    the default constructor is I.
    Constructor should return an Event or an Aggregate and must take
    at least 3 arguments: instrument number, onset time and duration

    Use

    Class = DebugCTOR

    to print generated values instead of actually generate something.
    An empty aggregate will be returned in this case.

>>>

or get a printable or browseable version of a reference manual using happydoc.
I'm currently using OMDE/pmask to complete two composition and extending
it every day. As I finish them (approx end of this month), I intend to prepare a fully
documented candidate release, submit it to people that was interested and/or
using pmask and possibly collect their comments, then release OMDE/pmask.
At the moment, if you need some explanation, just ask me.
If you are going to start to use pmask or want to give it a try, I strongly
suggest you to try the CVS version of OMDE/pmask. I'm using it every day so
it works quite well and if you find some bug I can fix it quickly.
Reports about design issues are welcome but not likely to be faces before 1 month.

If you and CVS are not simpatico, contact me privately.

Maurizio Umberto Puxeddu

On Wed, Oct 03, 2001 at 03:52:40PM +0200, Maurizio Umberto Puxeddu wrote:
> On Mon, 1 Oct 2001, Paul Winkler wrote:
> > I also like the operator overloads I'm using, but that's really just
> > sugar.
> >
> > If you're agreeable to supporting features like .append(), .merge(),
> > .extend() and maybe some operator shortcuts for them, I may consider
> > dropping pysco entirely and putting my work into OMDE.
> 
> No problem. It can can be done.

OK. I will take on the project of going through OMDE and trying to see
if / how it can support my ideas.

I'd still like to discuss whether objects should be responsible for
their own start time, or delegate that to a parent Aggregate.  When
you get a chance, I'd like to hear your reasoning for making each
event responsible for its own start time.

The only argument I can see *against* giving this responsibility to
the parent (the containing Aggregate) is that it requires you to have
a top-level Aggregate to control your composition's overall
structure. This might be seen as inconvenient; "I know when this
object should start, I want to say so when I create the object."

But I think it's actually an advantage to have an explicit top-level
Aggregate, because it's easier to see the overall structure of the
piece that way.

And suppose you want to have two Aggregates which consist
of the same events in different order. Let's call the contained events
A, B, and C.

If each object is responsible for their own start time, that would
look something vaguely like this:

A = Event(start = 1)
B = Event(start = 2)
C = Event(start = 3)
Agg1 = Aggregate(A, B, C)
A2 = copy(A); A2.set_start_time(10)
B2 = copy(B); B2.set_start_time(20)
C2 = copy(C); C2.set_start_time(0)
Agg2 = Aggregate(A2, B2, C2)

I have to make copies or else I'll change Agg1 when I only want to
change Agg2.

On the other hand, if we use the Aggregate to control start time, it's
a lot easier. Something like this:

A = Event()
B = Event()
C = Event()
Agg1 = Aggregate((1, A), (2, B), (3, C))
Agg2 = Aggregate((10, A), (20, B), (30, C))

As further purely anecdotal evidence, I'll note that the author of
Blue does it my way. :)

Implementation detail: In pysco, I have been storing the events within
an Aggregate (I call them Blobs) as a simple list of [start_time,
event] lists. I chose that because it makes it easy to e.g. sort the
list by start time.  And I use lists rather than tuples so it's easy
to replace any event or change any start time.

> I need to keep concentrate on my compositions for some time and I'll not
> reply very quickly to emails for few days.

That's fine - I have plenty of work to do, and I've been working on
pysco for almost two years anyway, so you can see I'm in no hurry. :)

Anyway, as I found with pysco, trying to compose with it is the best
way to improve it - "eat your own dog food" as they say.

> I also would like to move this discussion on the pythonsound-devel
> list here:
> 
> http://lists.sourceforge.net/lists/listinfo/pythonsound-devel

Done.

I think there have been some discussions of pmask on the csound list,
but not being subscribed anymore, I can't find them - there don't seem
to be archives of the csound list anywhere! Are you on the csound
list? If so, and if you have time, could you see if there are any
interesting pmask-related messages on csound list and forward them to
pythonsound-devel?

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

> Also it would be nice to extend them for animations
> > that would make use of the time variable.
> Could you explain this better?

The POVRay extensions I added to pmask make no use of time except as a loop
counter.  This is fine if you are just rendering a scene.  If you want to do
an animation you would want to have the objects you defined changing over
time.  Moving, getting bigger or smaller, flocking, rotating, etc.  I think
animations may use something like 10-60 frames/sec.  I haven't really done
many animations in POVRay but it would seem to make sense to do the modeling
at a higher level and just use POVRay as the rendering engine.

Bye,
Hans Mikelson

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (53)	Nov (7)	Dec
2002	Jan	Feb (1)	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2003	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2004	Jan	Feb	Mar	Apr	May	Jun	Jul (2)	Aug	Sep	Oct	Nov	Dec

pythonsound-devel Mailing List for The Python Sound Project (Page 3)

pythonsound-devel — Generic list for developers