Re: [foo-devel] semitone/rational reader extension & other

[martin r. <fo...@ru...>]

dear delevopers,

thanks for your thoughts, ramon.

is there any special reason for not writing to the foo-devel-list?
o.k., there are just you and gerhard and me on this list (right now),
but these are important questions on the development road to a better
foo, thus they belong to the foo-devel-list.  the lists will be
archived, so they are accessible later, which might get important
later, when more people are using foo and are interested in the
history of the program (after foo has beaten windows :-))

On Wed, Jan 28, 2004 at 03:58:30PM +0100, Ramon Gonzalez-Arroyo wrote:
> Replacing the semitonal notation by a function is certainly not a big 
> deal -of course there are already functions in Foo to deal with this and 

you are absolutely right with your thoughts about musical thinking and
notation.

fortunetaly, i found a possible solution for the semitone extension:
in elk, there is a way to define a custom reader (Define_Reader()),
which is suitable for defining a semitone reader extension.  but the
current syntax has to be changed, since the custom reader extensions
have to start with '#'.  the bistring extension is such a thing
('#*100010'), semitone reader could be '#s6' for example.  if i
understood the scheme r5rs correctly, the sign 's' within a number is
already reserved for giving the precision of a number: '3.4122355s0'
should specify 'short' precision.  since this is not implemented in
elk, it could get used for the semitone thing in the past, but is
dangerous...

> the way one thinks it. And with this in mind you'll agree that 1/5 tells 
>  much more than 0.2 (although in this trivial case it could be less 

there's no question about this.  you are absolutely right.  the
question was just about finding a way to use the "stock" elk
distribution without the need of patching it.  that way, we could
benefit of the further development of elk in an easier way.

since reading of rationals is part of R5RS:

the grammar says:
<ureal R> ---> <uinteger R> | <uinteger R> / <uinteger R> | <decimal R>

i won't hesitate to integrate the old rational reader extension with
the new elk and propose this to sam (the current elk maintainer).  in
the new read.c of elk, there is even a statement:

        /* Lacking ratnums, there's nothing we can do if #e has been
         * specified-- just return the inexact number.
         */
 
thank you for pointing out that reading of rationals belongs to the
scheme standard.  i didn't know that.

> 2) What happens with the Oops patch? Before oops patch, methods could 
> have optional arguments. The oops patch prevents methods from using 
> optional arguments. It doesn't give an error, it simply doesn't work. I 
> sent Gerhard the other day an example of both cases. I think this 
> problem is worth looking at it.

of course.  i simply don't know what it really does.  i just copied
the oops patch from the old NeXT-elk-distribution to the new one.
should be one of the next steps to track this down.

> the Abstraction is quite another question. Therefore I see at least 
> three levels of control sources:
> -The old sources with their optional arguments and whatever (working, by 
> the way, in Martin's first implementation (when removing the oops patch))
> -The strict new implementation of the old sources. Adapted to oops.patch 
> or probably better to new ELK (whatever that may mean : cleaning up of 
> optional arguments, cleaning up of semitonals and rationals, etc.)
> -The new developed sources with the new ideas and changes; new classes, 
> new structure, whatever.

you are right.  i already thought of still working at the initial port
of foo, just to retain compatability.  perhaps we could gain
compatability with the first port using the new elk (but without the
new soundfile stuff).  i'd love to see a foo which is almost
completely conformant to foo-2.1 (besides the 'main', boosted foo
branch).

for the readline extension, i think i found a clean and elegant way to
bring it into elk (as an optional, dynamically loadable extension),
which could probably also integrated with the official elk
distribution.  i'm working at it.  expect some news for the weekend.

all the best,

martin

--
foo sound synthesis
http://foo.sourceforge.net