[Fluxus] [signal.automatique at gmail.com: Re: scala.scm - rev 3a]

[Kassen]

----- Forwarded message from Kassen <signal.automatique at gmail.com> -----

Date: Tue, 21 Feb 2012 15:51:11 +0100
From: Kassen <signal.automatique at gmail.com>
To: Joel Matthys <joel at matthysmusic.com>
Subject: Re: [Fluxus] scala.scm - rev 3a
User-Agent: Mutt/1.5.20 (2009-06-14)

Oops, this was intended to go to the list. Sorry.

On Sun, Feb 19, 2012 at 07:27:02PM -0500, Joel Matthys wrote:

Some notes;

> Hi Kassen. I've made a few revisions and bug fixes since the last
> post, so I'm attaching my most recent version of the code.

That stuff is great and the explanations are quite clear too. I
copy-pasted those and have more or less decent looking helpmap entries
here now. I still need to proofread those as I know I make mistakes,
but I think I got all of the ones that need to be exposed to the user
now.

> I haven't looked at it since December, but I think I already fixed
> that integer check bug you found. But the type checks you suggested
> are a very good idea.
> 

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 :-). The
issue here manifests itself in non-exact integers not being acceptable
indexes for lists. Now that I think of it I need to check that the
rounding for turning micro-tuning off also casts the number to a exact
one as that will save cpu.

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

Yours,
Kas.

----- End forwarded message -----