----- Forwarded message from Kassen <[email protected]> -----
Date: Tue, 21 Feb 2012 15:51:11 +0100 From: Kassen <[email protected]> To: Joel Matthys <[email protected]> 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 -----
