Hi Craig,
somehow I missed answering this one, and I only realized that after
writing several other posts about the topic earlier today ...
Am 05.11.2015 um 02:27 schrieb Craig Dabelstein:
> 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.}
That way one would have to implement one general approach to parsing the
keys, and maybe that would even give an opportunity to handle the
"templating" in a more consistent manner. I find the approach with named
properties cleaner than the current one that simply uses numbered
mandatory arguments.
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.
\criticalRemark \with {
message = "Originally \\textit{Flauti in F} which is an E\flat\
transposition."
original-instrument-key = ef
original-instrument-mode = major
...
}
This is not really concrete yet, but I do think we'll be able to figure
something out for you and improve the library for the general public
along the way.
Best
Urs
>
> Any ideas?
>
> Craig
>
>
>
> On Wed, 4 Nov 2015 at 21:39 Urs Liska <u...@openlilylib.org
> <mailto:u...@openlilylib.org>> wrote:
>
> 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-one = { 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 <u...@openlilylib.org
>> <mailto:u...@openlilylib.org>> 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
>> <u...@openlilylib.org <mailto:u...@openlilylib.org>>:
>>
>> 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
>>> <u...@openlilylib.org <mailto:u...@openlilylib.org>> 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 <craig.dabelst...@gmail.com
>>> <mailto:craig.dabelst...@gmail.com>>:
>>>
>>> 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 \major
>>> original-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
>>>
>>>
>>>
>>> *Craig Dabelstein*
>>> e:craig.dabelst...@gmail.com
>>> <mailto:craig.dabelst...@gmail.com>
>>> <http://www.facebook.com/craig.dabelstein>
>>> <http://au.linkedin.com/pub/craig-dabelstein/b2/5b8/389/en>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> lilypond-user mailing list
>>> lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>> -- Diese Nachricht wurde von meinem
>>> Android-Mobiltelefon mit K-9 Mail gesendet.
>>>
>>
>> ------------------------------------------------------------------------
>>
>> lilypond-user mailing list
>> lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit
>> K-9 Mail gesendet.
>>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
