Re: GOP2-3 - GLISS (final)

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> On Fri, Aug 10, 2012 at 3:23 AM, David Kastrup <address@hidden> wrote:
>> Janek Warchoł <address@hidden> writes:
>>> Sorry, i don't understand.  You mean that you know how to do this, but
>>> there's something else blocking you from implementing it?
>>
>> If two different things are indistinguishable, you can't have them both.
>>
>> If (3+2)/8 is shorthand for #(3 2 8), then (2+2)/2 is shorthand for
>> #'(2 2 2) and
>> \time #'(2 2 2) 6/4
>> already _has_ an assigned meaning.
>
> Ah, your previous message makes perfect sense now.  I didn't know that
> \time #'(2 2 2) 6/4 is possible at all!  It seems to be undocumented -
> i've only found it used in two snippets.
>
> Frankly, \time #'(2 2 2) 6/4 is a nice thing, but the grouping can be
> done using beatStructure.  I wouldn't oppose deprecating current
> behaviour in favour of more user-friendly compound meter syntax.
>
>>> Anyway, from my point of view (user-friendliness obsession) this would
>>> be fantastic!  I'm ready to pay 25 euro for being able to use \time
>>> (3+2)/8 (without any additional hashes, quotes etc) as a legitimate,
>>> fully-supported meter command.
>>
>> It would have been 3+2/8 at any rate since throwing parens into the
>> token syntax would have further messed up the ambiguities, and forms
>> like 3/2+2/5 would not likely have worked.
>
> You mean, it would be impossible to support 3/2+2/5 as #((3 2) (2 5))?
> Pity.

It would mean that 3/2+2/5 would mean #((3 2) (2 5)) basically wherever
you chose to write it.  Since we don't have a use for it anywhere except
after \time (and it is actually a rather uncommon use of time), it seems
like overkill.

One could try to devise a scheme where, say

2+3/4 -> #(2 3 . 4)                   (meter)
2+3+2 -> #(2 3 2)                     (beat pattern)
2/2+3/4 -> #((2 . 2) (3 . 4))         (meter)

and then figure out predicates that can reliably tell a meter from a
beat pattern.  But it would not really extend to "irrational meters", I
think.  And I am not sure that this kind of complexity for interpreting
strings of the kind [0-9+/]+ is really helpful.

-- 
David Kastrup