[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: For those who need new features and bug fixes...
From: |
address@hidden |
Subject: |
Re: For those who need new features and bug fixes... |
Date: |
Fri, 21 Dec 2012 13:10:20 +0100 |
On 21 déc. 2012, at 12:17, David Kastrup <address@hidden> wrote:
> "address@hidden" <address@hidden> writes:
>
>> I agree that moment addition and subtraction is a royal pain. If I
>> tackled this, which I might, the solution would be more general in the
>> form of what I call "stream filters."
>
> I'd strongly recommend against that: the only reliable way to establish
> timing is actual iteration, and that's costly (well, one can abort it
> once time 0 is over, but it still needs to get set up). Short of that,
> we'll just move the problem into more obscurity and get new surprises
> when the pseudo-timekeeping gets things wrong.
>
> Now we actually have this sort of "squeeze grace material in before the
> time starts properly" mechanism already, with grace-fixup chains and
> stuff. Prepending _another_ such mechanism because the existing
> mechanism fails to work reliably seems like a step towards making it
> much harder to actually fix things.
I agree that it'll take more time, but I don't think there's anything pseudo
about the timekeeping. I used filters like this for many, many projects and
the first pass is attaching a property called timing-info to every event that
identifies at what time point it falls in the piece. That allows subsequent
iterations to not have to figure out timing stuff. This is also the type of
info that'd also be necessary for a MusicXML export.
My goal is not to prepend an extra mechanism because the current one fails. My
goal is to come up with a systematic way to automate choices before information
gets passed to the engravers. The most problematic engravers, in my opinion,
are currently the ones that try to do this type of automation task: Auto_beam,
Completion_note, and Completion_rest. This is because they cannot peak ahead
in time and go backwards, resulting in their either making poor engraving
choices or issuing events later in time, which causes problems for the
identification of cross-staff grobs. The solution is to come up with a stable
Scheme object - MusicFilter (or whatever) - and chain these things together,
passing the input stream through them before the engraver stage.
I don't think coming up with a general and robust implementation of music
stream filters would make it harder to fix things, nor does it move the problem
to more obscurity. On the contrary, I think it'd make it easier and more open.
For example, if these Filter objects could issue warnings and point to lines
in code where problems cropped up, that'd make it easier to find and fix
problems.
I'll conclude with a variety of tasks that can be done at this stage:
--) Auto beaming
--) Making decisions about splitting notes and rests at barlines
--) Style sheets for how notes should be dotted or tied over beats
--) Typesetting only parts of music
--) Moving keys, time signatures and the like before or after grace moments
In general, anything that requires automation should be done before the
engraver stage. Coming up with a stable and reliable way to do this is, in my
opinion, a step forwards for LilyPond.
Cheers,
MS
Re: For those who need new features and bug fixes..., Kieren MacMillan, 2012/12/21
Re: For those who need new features and bug fixes..., Urs Liska, 2012/12/21