As said you should tell me what you want to achieve.
- What do you want to communicate?
- How (and where) do you think that should be visualized?
- How do you think should it be encoded in the annotation?
(This goes for your current example or any others you came across.)
Then we can see if there's already a way or if it makes sense to implement something new.
From your example I'm not sure if it makes sense to approach it as you do.
I suspect that 'original-instrument-key' and 'original-score-key' aren't actually properties of the critical remark but rather properties of the message you want to communicate.
I see it like this: I have an annotation, say, a critical remark.
This has some properties, these may include things like
- author
- reference to a source
- affected instrument and position in time
- and of course the actual message
Having a custom property 'original-instrument-key' would make sense if you'd have annotations that refer to different original-instrument-key's.
I would think the two informations in your example should somehow be integrated in the 'message' property. But I may be mistaken, this very much depends on a more global context, i.e. if these original-key issues are something that you regularly have to comment on in your score(s).
If you have a clear opinion on the matter we can see how to proceed with it. Anyway, I'll give you a few examples of features I would like to add to ScholarLY:
1)
Insert music examples in the annotation. One would e.g. write something like
\criticalRemark \with {
example- a4 b c }
example-two = { a4. b8 c }
message = "Originally written as \example "example-one" but changed to \example "example-two".
}
2)
Have an annotation optionally produce a footnote in the score. This would use a dedicated field for the footnote text or the message if no footnote is specified.
3)
Have an annotation automatically apply "editorial functions". That means: I can tell the annotation that it refers to an editorial addition and this produces a corresponding LilyPond command. This command could then be defined to make the affected item dashed or parenthesized or whatever, depending on its type.
4)
Make it possible to have an annotation affect all or selected contexts. Often an annotation applies to all parts/voices equally. These should have to be entered only once and then affect the items in all voices. And they should also work when parts are engraved individually.
It isn't acceptable to have to enter the same annotation for all the parts in a score.
5)
Make it possible to define annotations externally using the edition-engraver (ideally it's to-be-developed evolution using IDs instead of/in addition to "musical moments").
There are use cases where it is very nice to have the annotations directly in the input file but there are also use cases where it would be extremely helpful *not* to have content and annotations intertwined like that. Developing a dialog based interface for editing annotations would also benefit from such a separation.
Actually such an interface (in Frescobaldi) is also on my wish/todo list.
So any further ideas are very welcome, but you see there is much to be done. So I'd also be very grateful for any help.
Best
Urs
No problem Urs. Thanks for all you do.
Craig
Oops, sent instead of saved ...
I'll have to return to this later.
Am 2. November 2015 08:50:39 MEZ, schrieb Urs Liska <address@hidden>:-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.Hi Craig,
actually I see there's nothing *I* have to look into right now. Rather you should tell me what you would like to achieve. Tell me what - from your experience with an actual project - would be good to have in ScholarLY. While not exactly rich in time I'm more than ready to bring this package further.
So far custom properties are just translated into key-value properties to the LaTeX command. It's then the task of LaTeX to do something useful with them. As I said the current set-up simply guarantees that
Am 29.10.2015 um 22:58 schrieb Craig Dabelstein:
Thanks Urs. I'm working on a 900-page score from 1842 and scholarly/annotate is proving invaluable. Thanks for all your hard work on this.
Craig
On Thu, 29 Oct 2015 at 18:05 Urs Liska <address@hidden> wrote:
I'll have to try this on a PC, but for now two remarks:
You seem to have misplaced the space before \transposition so this can't be expected to produce anything meaningful.
The custom properties that end up in the optional argument (square brackets) don't have any implementation so far. This is jzst a state where you can enter arbitrary stuff in the annotation and have *valid* LaTeX produced.
Please remind me if I fail to come back to this.
Urs
Am 29. Oktober 2015 08:45:06 MEZ, schrieb Craig Dabelstein <address@hidden>:Dear Urs (or any other Annotate experts),
I have created this entry in my input file, taking the idea from the example given on git:
\criticalRemark \with {message = "Originally \\textit{Flauti in F} which is an E\flat\ transposition."original-instrument-key = \key ef \majororiginal-score-key = \key c \major}
Can anyone tell me how this should translate into the latex file? Is it expected to produce a real key signature in the latex file?
The console output produces:
\criticalRemark \with {
Measure 1184, beat 1
Context: Flute 1
Affected Item: NoteHead
Message: Originally \textit{Flauti in F} which is an E\flat\ transposition.
original-instrument-key: Key: #<Pitch ees >
original-score-key: Key: #<Pitch c >
The .inp file produces:
\criticalRemark
[original-score-key={Key: #<Pitch c >},
original-instrument-key={Key: #<Pitch ees >}]
{1184}{1}
{Flute 1}
{NoteHead}
{Originally \textit{Flauti in F} which is an E\flat\ transposition.}
How would you have this display in your latex Critical report?
I hope this makes sense.
All the best,
Craig
![]()
lilypond-user mailing list address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-user-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
lilypond-user mailing list address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-user