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 <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>:
>>
>> 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
