Re: [Pythonsound-devel] omde.score patch [was (no subject)]

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

On Tue, Oct 09, 2001 at 08:00:50PM +0200, Maurizio Umberto Puxeddu wrote:
> On Tue, 9 Oct 2001, Paul Winkler wrote:
> 
> > If you like. But why is it necessary for the programmer to remember
> > that this method "has to do some work"? He/she is only interested in
> > the return value.
> 
> If you know that a call is potentially going to consume much time,
> you can think of caching the values instead of calling it
> twice. Nothing more.

OK, I see your point.
 
> Probably the best way should be caching onset min, onset max and end
> max values instead of caching onset and duration, isn't it? I think I'll
> do this.

This is starting to sound rather like pysco. :) 
Especially since Aggregate now subclasses Event. 

In pysco, I didn't provide methods like those you have - I just had
attributes, and required that time-modifying methods must update the
relevant attributes. This meant that accessing the values is always
fast, but modifying an Aggregate might be slow.

pysco.Event had two attributes: 
   endbeat (this is duration, which is actually a better name)
   last_at (this corresponds to calculate_min_max_onset()[1])

For non-Aggregates, last_at was just 0.

I think omde is well on the way to being "like pysco but better"!

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