[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[final PATCH] Re: not-so-ancient flags
From: |
Reinhold Kainhofer |
Subject: |
[final PATCH] Re: not-so-ancient flags |
Date: |
Sat, 30 Aug 2008 00:29:45 +0200 |
User-agent: |
KMail/1.9.9 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Samstag, 23. August 2008 schrieb Han-Wen Nienhuys:
> On Fri, Aug 22, 2008 at 3:14 PM, Reinhold Kainhofer
> > So, to summarize what you suggest:
> > - -) Stem 'flag property: Always a scheme function returning the complete
> > stencil; The default scheme function calls some C++ function, which does
> > exactly what we have in Stem::flag right now (i.e. lookup a glyph from
> > the font, using the 'flag-style property for the name).
> > - -) Stem 'flag-style property: The name of the style, used only by the
> > default 'flag function.
> > - -) C++ function Stem::calc_flag: Contains the current code for flags
> > will be called by the default function of Stem 'flag.
>
> Yes- this follows the principle of least surprise.
Okay, attached is the updated patch, which gives users full control about the
flag generation. It uses the Stem grob properties as outlined above.
I implemented both a C++ and a scheme function to create the flags. There is a
slight performance advantage for the C++ function (for a file containing only
10,000 unbeamed eighth notes it is 5 seconds faster with a runtime of a
little over 3 minutes, see below), so I left the C++ function in, but also
did the Scheme implementation, so that users can take the existing styles and
modify them. With this patch we now have the proper basis to implement the
straight flags style originally requested.
Here's what the patch does (from the git log message):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-) Added the 'flag grob property to the stem: It's a function taking the
stem grob and returning a stencil for the whole flag (including a possible
grace slash). It uses the 'flag-style property with the exact same values
as previously, so any existing score should still be working.
The default is ly:stem::calc-flag (implemented in C++), but
I also implemented the default styles (no-flag, normal-flag and
mensural-flag) in Scheme, where the function default-flag also uses
the 'flag-style grob property. Both (the flag creation in C++ and in
Scheme) show practically the same performance[*], so we might get rid of
one of them in the future. Flag creation using scheme can thus be enabled
by
\override Stem #'flag = #default-flag
flag creation in C++ can be explicitly enabled by
\override Stem #'flag = #ly:stem::calc-flag
-) Implemented the default flag styles as scheme-functions, so that one can
re-use them in one's own flag style functions. The default flags functions
are implemented in a modular way, so one can easily create styles that
adjust some aspects of the default flags. An example style implemented
in the test is to use mirrored flags (i.e. flags always pointing
left). This can be implemented by creating the flag for the opposite
stem direction and rotating it by 180 degrees ;-)
-) Added regression tests to check that the default flag styles all keep
working.
-) In the regression tests, I also added some custom styles: weighted-flag,
where the flags are shown as one big black box and the "number" of flags
is indicated by the height of the box. The other example is the
mirrored-normal-flag style mentioned above (useful for tutorials about
music notation to show that flags should *NOT* be printed to the left!)
The real motivation for this feature, namely straight flags (either
old-style with a large slant or modern-style with a much smaller slant),
is not yet implemented, but should not be too hard, using the
ly:round-filled-polygon function.
[*] We now have two ways to generate flags: One C++ implementation
(ly:stem::calc-flag) and one pure-Scheme implementation (default-flag).
Both require the same amount of memory and there is hardly any difference
in their runtime. For example, a file consisting of 10,000 eighth notes
(nothing else) needs ~1.5GB RAM and runs for a bit over 3 minutes here,
with the C++ implementation beating the Scheme implementation by mere
5 seconds:
In C++:
real 3m9.133s
user 3m4.896s
In Scheme:
real 3m14.016s
user 3m10.024s
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Okay to push to master?
Cheers,
Reinhold
PS: What about the straight flags glyphs that we already designed? Should we
simply drop that and do a pure Scheme implementation with all its drawbacks
(no proper hinting, as pointed out by Werner in Bug #652)?
Werner, should the get_subpath function still be moved from parmesan-macros.mf
to feta-macros.mf, even though it is not really required there?
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
* Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
* K Desktop Environment, http://www.kde.org, KOrganizer maintainer
* Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIuHhbTqjEwhXvPN0RAgLLAKDU27hViONsoCNluvtAK6OdCzFBewCg1RCQ
k5xw7RTw9XQxaZ/ZQ1M+J/4=
=PL5Q
-----END PGP SIGNATURE-----
0001-Change-flag-creation-to-use-the-flag-prop-function.patch
Description: Text Data