[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Denemo-devel] [bug #29399] Timesignature query in scheme

From: anonymous
Subject: [Denemo-devel] [bug #29399] Timesignature query in scheme
Date: Fri, 23 Apr 2010 15:29:56 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

Follow-up Comment #6, bug #29399 (project denemo):

Thanks for the work on the grace note query stuff.  The grace query looks
like it should be perfect.
The reason I didn't just go with GetDurationInTicks originally is that as far
as it's concerned, everything must be a divisor of 1536 =the number of ticks
of a whole note (at least assuming as I did that it always returns an
integer).  This is fine for quarters, eighths, and so on, as well as triplets,
but since 1536=512*3, this won't work for most higher tuplets such as
quintuplets and so forth.  So I used fractions as the durations in the rebar
script to allow for arbitrary tuplets.
Now, if my assumption about GetDurationInTicks always returning a whole
number is wrong, then all of that is moot, and that would probably be a much
easier way to implement rebar.  I actually never did try to check what it
returns on say a quintuplet.
For now, I'm going to stick with fractions since, for all I know, the 1536 is
an arbitrary number possibly subject to change, although that too could be

As far as how to deal with tuplets in denemo, this is how I've been picturing
Right now there are two ways to set a tuplet in denemo--the built-ins (giving
type TUPOPEN &c.), and the standalone lilydirectives made from the arbitrary
tuplet script that denemo mostly ignores last I knew, but which affect the
lilypond.  I think either of these ways would be simple enough to work into
the rebar script, and possibly right now I could even update rebar to work
with the lilydirectives ones now that I think of it.  
I think it would suffice if there was a way to query the TUPOPEN objects as
well as the TUPCLOSE ones, and get what type of tuplet they are, ideally as a
string which when converted via string->number gives a fraction equal to the
duration scale factor, if you see what I mean.  So an ordinary triplet would
return "2/3", quintuplets "4/5", and so on.  It would be important to have the
TUPCLOSE return the same string as well, since there can be nested tuplets and
I plan on something like this:
if gettype returns TUPOPEN, TupletScaleFactor *= (query the tuplet and
convert its string to a fraction)
if gettype returns TUPCLOSE, TupletScaleFactor /= (query for the string,
convert to frac)

This would allow for nested tuplets.
Does this seem feasible and in keeping with whatever plans you have for
tuplets?  In my view the ideal situation would be to (eventually) make denemo
aware of the directive-type tuplet commands, or else integrate all the various
built-ins into one command that can handle an arbitrary fraction.  If people
want individual commands like triplet, bind it to the script (d-InsertTuplet
"2/3"), or something similar.  I'm aware that this might not be a priority.

Actually I'm not sure that the rebar should try to fix a measure with tuplets
not adding up; probably should just alert user's attention to that measure if
the excess ends up being something like 2 septuplets.  
As a final comment, is there a way to query denemo from scheme if a measure
is full or too small or too big?  It would probably speed up the script, for
what it's worth.
-Dan W.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]