<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.1.92">
</HEAD>
<BODY>
OK, implemented the table lookup methods. Not too painful.<BR>
<BR>
Also cleaned up some of the variable names and made method names more consistent. (Still, hardly elegant and definitely not optimized!)<BR>
<BR>
Joel<BR>
<BR>
On Wed, 2011-12-21 at 13:28 +0100, Kassen wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 21/12/2011, Joel Matthys <<A HREF="mailto:joel@matthysmusic.com">joel@matthysmusic.com</A>> 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.
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>