[Fluxus] Fwd: Re: scala.scm - rev 3a

[Joel Matthys]

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.
>
>