On 02/21/2012 09:51 AM, Kassen wrote:
That particular one was still in there, it's a slightly tricky thing;
Scheme makes a distinction between "exact-integer" and "integer". The
issue can arrise with numbers like 2.0 . Numbers like that are
"integer" but not "exact". The Scheme numbers implementation is a work
of art, but it's a work of art by and for mathematicians :-).
Ugh, I see. I was learning as I went along about this stuff. Thanks!
Some other things I'd like to run by you;
I'd like to add a way to poll for the current amount of keys in a
octave.
That should be easy. It's stored in the *scala-size* variable. (BTW,
it's probably better to say 'notes' in an octave. Keys means too many
things to different people!
I'd also like to try adding a way to query for the description
of a tuning that has been added but hasn't been set as the active
tuning. That way we could search for the one we like without commiting
to loading it. Overloading the current function for descriptions to
optionally take a argument should do the trick.
Oh, I like that. Good idea!
Last on my list of
ideas (for now) is sticking to the current diapason and base-key when
a new tuning is loaded. Currently those are reset to the defaults.
This could be matched with a simple function called "scala-defaults"
that simply sets everything back to "midi standard" in case we get
lost. Does that make sense? Or is resetting those to defaults at
loading a tuning something that other implementations do and that will
lead to confusion if we don't follow that standard?
I don't know of any standard. Your idea makes a lot of sense. I like the
"scala-defaults" command. As I look back on it, I'm a little surprised
at myself for resetting the diapason and base-key every time the scale
changes. I can't think of any good reason for doing so. Ah, to be young
and foolish again, back in December...
Thanks!
Joel
Yours,
Kas.
