[Pythonsound-devel] Re: Python and music

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

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