Re: [Pythonsound-devel] omde.score patch [was (no subject)]
Status: Beta
Brought to you by:
mupuxeddu
|
From: Paul W. <sli...@ya...> - 2001-10-09 18:25:21
|
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 |