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.*"
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.)
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
}
Any ideas?
Craig
On Wed, 4 Nov 2015 at 21:39 Urs Liska <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> 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>:
>>
>>>
>>> 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> 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>:
>>>>
>>>>> 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
>>>>> <http://www.facebook.com/craig.dabelstein>
>>>>> <http://au.linkedin.com/pub/craig-dabelstein/b2/5b8/389/en>
>>>>>
>>>> ------------------------------
>>>>>
>>>>> lilypond-user mailing
>>>>> listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user
>>>>>
>>>>> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>>> gesendet.
>>>>
>>> ------------------------------
>>>
>>> lilypond-user mailing
>>> listlilypond-user@gnu.orghttps://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
