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.
\include "openlilylib"
\useLibrary ScholarLY
\useModule scholarly.annotate
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 <u...@openlilylib.org
> <mailto:u...@openlilylib.org>> 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.
>>
>>
>> [1] From the Snippets Repository:
>> http://lsr.di.unimi.it/LSR/Item?id=368
>> [2] http://lilypondblog.org/2015/01/introducing-scholarly/
>> [3] lilypond-user list, November 2015: "ScholarLy and polymetric
>> music? (bar numbering, \RemoveEmptyStaffContext)"
>> [4]
>> http://www.lilypond.org/doc/v2.19/Documentation/usage/lilypond_002dbook
>> [5]
>>
>> http://lilypondblog.org/2013/07/creating-songbooks-with-lilypond-and-latex/
>> [6] http://openlilylib.org/musicexamples/index.html
>>
>>
>> _______________________________________________
>> lilypond-user mailing list
>> lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> _______________________________________________
> lilypond-user mailing list
> lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
