On Jun 16, 2011, at 2:43 PM, Graham Percival wrote:
On Thu, Jun 16, 2011 at 01:50:27PM +0200, address@hidden wrote:
If only it were that easy...
I have also tweaked the rest engraver to do automatic rest grouping.
For example, if in my file I have
\time 4/4
d4 r8. r8 r16 r8 r2 r4 r2
What will be printed is
d4 r4 r2 r1
That sounds like a job for a scheme music function.
It is certainly doable in Scheme insofar as one can create engravers in Scheme. However, in order to pull this off, I need access to context properties like measureLength and timeSignatureFraction, which are only available (as far as I know) from translators/engravers.. The type of filtering in the two snippets below deal with music before it gets sent to an engraver.
This is why the event needs to be rebroadcasted - it changes the rest to r1 in the engraver (not in the .ly file).
I could, of course, implement a crude parser in python that combines my rests into a new input file, but this would be doubleplusunfun.
It still really sounds like you should use a combination of
http://lsr.dsi.unimi.it/LSR/Item?id=372
http://lsr.dsi.unimi.it/LSR/Item?id=122
Right now, I can make this work by deleting the multi-measure-rest engraver and copying all the code to rest-engraver. However, I'd like to keep the changes as minimal as possible in hopes that the useful parts can remain separable and become part of LilyPond.
Scheme would be good for that. Also, that way somebody else could
compile your scores without needing to custom-patch the C++ in
their source code. Granted, you're probably never going to want
anybody else in the world to compile this particular score... but
you never know. What if those teenagers wanted to play with
stuff, and you gave them a short exerpt of this composition? It
would be *way* easier if they could just download 2.14.1 and
compile the .ly in there, instead of trying to work with the
source code.
True, but even if I rewrote the rest engraver in Scheme, the question would still stand about rebroadcasting an event.
I think there may be enough users who are lazy about how they write their rests that it'd be valuable to have auto-rest-making à la auto-beaming, so I may wind up making a patch out of all this.
My question still stands for anyone who has any idea if/how stream events can be rerouted to other engravers.
Sure, but you should ask that on the -devel list, not the -user
list.
Generally I consult -user when it has to do with my composition activities, but you're right that the people one devel are those who wrote the whole translator/engraver/iterator system. cc'ed to devel :)
Cheers,
MS