2007/2/19, D. Michael McIntyre <[EMAIL PROTECTED]>:
> On Sunday 18 February 2007 6:56 pm, you wrote:
> > Is there a bug/feature tracker concerning this patch?
>
> No. Here's his message:
>
In general, the Rosegarden quantizer and Rosegarden's quantizer for
LilyPond export
do not have one to one mapping. The differences start to appear at
least at the 64th note
level. Basically, the Rosegardens's quantizer for LilyPond export
should be completely
rewritten so that those small differences would disappear. Certainly,
most of the code
should be circulated from the NotationView.
Heikki
> > [Rosegarden-user] Lilypond export quirk?
> > From:
> > Arnout Engelen <[EMAIL PROTECTED]>
> > To:
> > [EMAIL PROTECTED]
> > Date:
> > Wednesday 2:38:24 am
> >
> > Spam Status: Spamassassin 62% probability of being spam.
> >
> > Full report:
> > No, score=3.1 required=5.0 tests=BAYES_95,FORGED_RCVD_HELO
> > autolearn=disabled version=3.1.7 Hello,
> >
> > I noticed something that appears to be a quirk in the lilypond export:
> >
> > I had a track which (among others) contained a quarter note, an eigth
> > rest, and another quarter note. This is what it correctly looked like in
> > the Notation editor. When exporting to LilyPond, however, this bar was
> > rendered correctly, but an extra 64th rest was added to the end of the bar.
> >
> > I dug in, and noticed this happened because the eigth rest was 30
> > timeT-units too short, and started 30 timeT-units too late. In
> > src/document/io/LilypondExporter.cpp, in calculateDuration, the duration
> > was first correctly adjusted from 450 to 490, but subsequently truncated
> > back to 450 again because the following quarter note appeared in the
> > correct spot, 450 timeT-units after the (too-late) start of the eigth rest.
> >
> > I worked around this by storing the correction (durationCorrection =
> > Note(type, dots).getDuration() - duration;), and when truncating
> > allowing for some extra room when the correction was positive (i.e. the
> > element was lengthened):
> >
> > if (s->isBeforeEndMarker(nextElt)) {
> > // if the element was lengthened, assume it was lengthened to the left
> > // when truncating to the beginning of the next element
> > if (durationCorrection > 0)
> > {
> > toNext += durationCorrection;
> > }
> > if (soundingDuration > toNext) {
> > soundingDuration = toNext;
> > duration = soundingDuration * tupletRatio.second /
> > tupletRatio.first;
> > }
> > }
> >
> > Not sure if this is a proper solution though, as it ignores the
> > situation that the previous element , in hindsight, should have been
> > truncated (more), and the situation that the lengthened element has to
> > be truncated and actually started in the correct place, but ended too
> > soon. It seems to give nice results for my case though :), consistent
> > with the notation view.
> >
> >
> > Regards,
> >
> > Arnout
>
> --
> D. Michael McIntyre
>
--
Heikki
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
