somehow I missed answering this one, and I only realized that after writing several other posts about the topic earlier today ...
Hi Urs,
Thanks for your detailed email. I agree wholeheartedly with your examples 1-4 above -- these would all be very useful for me. The score I'm working on (900-page handwritten manuscript from 1842) has natural horns and trumpets, and clarinets and flutes that change keys regularly throughout. I was going to include the original key of each instrument in the report to partially explain why the new transposed ranges are so high or low. For example using the current setup of annotate I'm creating a latex file that produces output like this:
M. 545, beat 1, Flute 1: "Originally Flauti in Es (which is a Db transposition)."
or
M. 123, beat 1, Horn 1: "Originally Corni in Ab."
OK, I think this is what I meant with a certain special case about your particular score. If you don't convince me otherwise I would say this is rather not a general use case and therefore it should be realized using the custom properties just as you did and make sure that the LaTeX commands understand them (see below for more details).
On reflection this is probably fine, but I guess it could also be put into a footnote in the score (although there would be a lot of them.)
If that's not something the performer should be directed to notice I wouldn't add numerous footnotes (but that is an *opinion*, not a rule).
I don't know how using code such as the following would make this any easier or clearer when sending it to latex.
\criticalRemark \with {message = "Originally \\textit{Flauti in F} which is an E\flat\ transposition."original-instrument-key = \key ef \major}
You're right.
If these transpositions and original keys have a significance that is similar to other properties in your editorial situation they should be encoded as properties.
Basically there are two approaches I can think of: Creating custom annotation types (in LilyPond) or handle it in LaTeX commands.
As you've seen currently your custom properties end up in key=value pairs in the optional argument. You can now "hand-code" a solution to properly handle these keys to produce a meaningful result - or you can help me implement a proper solution that can be generally useful (as outlined in an earlier post today).
And maybe it would be useful to change the LaTeX export in general so *all* properties end up in the optional argument and only the message as the mandatory argument.
\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.}
would instead look something like:
\criticalRemark
[measure=1184,
position-in-measure=1,
context={Flute 1},
item=NoteHead,
original-score-key={Key: #<Pitch c >},
original-instrument-key={Key: #<Pitch ees >}]
{Originally \textit{Flauti in F} which is an E\flat\ transposition.}
One general thing: You pass along these custom properties as "music _expression_". LilyPond accepts this and actually can interpret them but the resulting LaTeX export is a string generated from the Scheme representation. And this is something that LaTeX won't be easily able to make any use of.
You should consider entering these fields in a format your intended target platform can handle. Maybe split them into two fields, one for the pitch and one for the mode, e.g.
original-instrument-mode = major
...
Best
Urs
Any ideas?
Craig
OK, now I'm back again ...
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
Am 02.11.2015 um 23:36 schrieb Craig Dabelstein:
No problem Urs. Thanks for all you do.
Craig
On Mon, 2 Nov 2015 at 17:54 Urs Liska <address@hidden> wrote:
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