Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
Am 10.11.2015 um 03:52 schrieb Craig
Dabelstein:
Hi Urs,
What can I do to help you advance ScholarLY (or any of your
other projects)?
Well, the next thing is to constantly nag (but in a friendly manner
of course) ;-)
But if you would want to do some active contribution you're of
course more than welcome!
E.g. do I need to learn scheme?
Learning Scheme is probably a good thing for you (and I think it's a
good thing for the LilyPond community if more people manage to do
so). But if I were you I wouldn't expect to get to the point soon
where you can do substantial contributions. I don't want to
discourage you, it may well be a worthwile investment, but there are
surely other ways where you will sooner get positive feedback
through achieving things.
Do I play around with incorporating ScholarLY into Latex?
What would be the most helpful for you?
So you know LaTeX? Then this would surely be something useful.
As I wrote in my earlier reply there is the need for a proper
"critical report" package. I do have some code for formatting report
entries, used in a time when I maintained the entries manually. And
the LaTeX export in ScholarLY is modele on that. But what I've never
started on is a *proper* package for that purpose. Out of my hat I
see several tasks/challenges:
Pull in entries from an input file (somewhat similar to
citations)
Apply filtering and/or sorting to that
Make the appearance of the entries (and the whole report)
configurable in a way that is as user-friendly as one would
expect from a LaTeX package
(e.g. by providing commands to modify the appearance without
requiring the user to completely rewrite the command, or by
inventing some templating style)
Provide a way for handling custom properties. ScholarLY
exports unknown properties as key=value properties in the
optional argument, and the package should provide an
infrastructure that the user can define a way to process these
properties and integrate them in his custom rendering of the
entry.
###
Another project that would clearly benefit from assistance is
openLilyLib where currently two major items are (unhandled) on the
roadmap: creating a documentation infrastructure and disentangling
the library infrastructure
A)
The continuation of developing the "new infrastructure" and moving
the existing content to that is more or less blocked on a proper
documentation system. I do not want the "new" openLilyLib to
significantly get new content before that is solved, any material
newly added should already use that documentation.
This involves two separate parts:
a)
"Designing" a documentation syntax that allows authors to document
modules in their code. This is what all programming languages
support, and LilyPond should have that too. This effort should
therefore benefit LilyPond in general, not only openLilyLib.
b)
Starting from a) we need a scripted solution to automatically
produce documentation for openLilyLib and deploy it on the
appropriate server.
B)
I've successfully started out with a new infrastructure that makes
the use of openLilyLib much more straightforward, by using e.g.
I think this is a great improvement and has lots of potential for
the day when there are numerous libraries available. But I've also
realized that maintaining all these libraries inside a single
directory structure, and within a single repository, is not really
scalable. This will negatively affect
download size (everybody will have to get everything,
regardless of what they want to use)
maintainability (we'll have to give push access to a
potentially large number of library maintainers and
contributors)
issue tracker
Therefore we should (now) find a way to disentangle openLilyLib
in a way so that any library can be maintained in its own
repository. There should be the openLilyLib core library that is
responsible for all the infrastructure and common functionality.
The actual libraries should then reside in a consistent location,
presumably beside the core library. And we should have a package
manager that can take care of dependencies and library versions.
Both projects may sound quite large, but I'm sure it's *only* the
issue of (human) resources and not one of inherent obstacles, and
it would be great if we could actually work towards these things.
I'm quite positive that this would provide a serious improvement
in LilyPond accessibility and user-friendly-ness.
Best
Urs
Craig
On Tue, 10 Nov 2015 at 03:42 Urs Liska <address@hidden>
wrote:
Just shortly:
I do think we'll find a good way for you, and I also think
this is a good opportunity to continue work on ScholarLY.
Especially considering that just a few days ago Craig
Dabelstein also asked about ScholarLY.
Urs
Am 09.11.2015 um 17:33 schrieb Graham King:
I'm preparing an edition of
sixteenth-century polyphony, using the book-titling
template[1]. The edition would benefit from some
footnotes/endnotes (the sort that say things like:
"contratenor 1, bar 99: semiminim A missing in MS"). How
best to achieve this, while preserving the "book-titling"
appearance?
Urs' marvellous work on ScholarLy[2] appears ideal, but
outputs its annotations in Latex (and might have other
problems - see separate thread[3]). So I'm now wondering
how best to integrate this with a published score.
Several possibilities present themselves:
1) lilypond-book[4]. Requires extensive knowledge of
Latex, and appears to be targetted at presenting small
snippets within musicological papers, rather that large
amounts of music with a small number of annotations.
2) Latex with \includepdf[5].
3) musicexamples.sty[6].
4) something else?
I have used Latex (once!) and I'm prepared to do some
learning, but I'd welcome advice on the most efficient way
to proceed, and the pros-&-cons of each approach.