Just quickly - this is awesome! :) cheers,
dave On 12/21/2011 04:35 PM, Joel Matthys wrote: > OK, implemented the table lookup methods. Not too painful. > > Also cleaned up some of the variable names and made method names more > consistent. (Still, hardly elegant and definitely not optimized!) > > Joel > > On Wed, 2011-12-21 at 13:28 +0100, Kassen wrote: > >> On 21/12/2011, Joel Matthys <[email protected]> wrote: >>> Slight revision. Some confusion about when functions can be called with >>> optional parameters. Anyway, works better now. >> >> Great work, and fast too! >> >> I had a look at this now, nothing to deep, mind you, and like most >> people my knowledge of tuning is a bit limited, it's a bit of a black >> art after all. >> >> Do I understand correctly that your (scale-note ) -which I think will >> eventualy replace the plain note- is a lot more involved than the old >> one because it parses most of the scale stuff evey time it is called? >> And do I understand correctly that the advantage of this is that we >> can now have fractional notes that will be correct? >> >> I'll defer to Dave, but my current gut instinct is wondering how much >> of thise we could pre-calculate at picking our scale to save cpu >> during realtime usage. Would you say, for example, that it might make >> sense to pre-calculate a table like (note ) uses now and use that in >> case of integer arguments while your function would take care of the >> fractional ones? That would save cpu in the common case while >> preserving the option to accurately use quarter-tone equal-tempered >> notes, I imagine. >> >> I am open to the possibility that none of the above makes any sense >> and I completely misunderstood it all. >> >> Yours, >> Kas. >> > > >
