Re: edition-engraver and partcombine

[Kieren MacMillan]

Hi Urs,

Definitions:
“Piece” or “work” means the music, i.e., the musical/textual content 
independent of presentation.
“Score” means an engraved presentation of the piece (including full scores, 
parts, etc.).

> "edition engraver" sounds like a tool that engraves an edition.

Yes — that’s exactly how I use it:
1. Every time I make a major adjustment to a work (e.g., add music, add 
annotations, etc.), I use a new edition to store/execute any tweaks across all 
scores.
2. Every time I make a major adjustment (e.g., change font size, layout 
choices, etc.) to a score, I use a new edition to store/execute the necessary 
tweaks for [only] that score.

I also use “editions” to store/execute separate tweaks to two different 
presentations of the same music — e.g., the “original breaks and fingerings” 
version versus my arrangement/transcription/marked version.

> I wouldn't call a printed part and a full score two editions.

Neither would I… to me, those are two outputs within a single edition (your 
word “target” also being a good alternative word).

> I am adding mods for a given target, like full score vs. part, or e-book vs. 
> printed version etc.

For me, that’s done *within* an edition.

But maybe this is all semantics…  =)

Cheers,
Kieren.
___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Urs Liska]

Am 16.12.2014 22:33, schrieb Jan-Peter Voigt:

Hi Urs,

Am 16.12.2014 um 22:28 schrieb Urs Liska:

Hi Jan-Peter,

that would be great.
I intend to write a post about the tool soon - from a user's, not 
from the developer's perspective. 

that would great :)

Maybe I should wait with this some more.

BTW: I'm still not completely convinced that edition-engraver really 
is the right name.

If you have a proposal, share it ;)



I wouldn't have hesitated to do so, but I don't have a proposal.
The problem I have with it is that in my understanding it isn't even an 
editorial tool, so it would even be located in the wrong place in 
openlilylib. It can be that I'm mistaken here (or at least that the 
issue is more ambiguous than I feel), but in my opinion an editorial 
tool is something an editor uses, with "editor" being meant in the sense 
of "scholarly editor". Editorial tools, as I understand it, could be


- a function to dash/parenthesize/resize editorial additions
- a function to add annotations (not visual annotations like balloonHelp 
but like comments for a critical report)

- a function to visually indicate line breaks in the manuscript
- a function to modify the bar numbering when the edited sketch differs 
from the final version of the piece


Editorial tools can also be functions to improve editorial workflows, 
such as producing versioning info to be printed in the tagline etc. But 
I don't see tools that support the "editor" in the sense of someone 
technically involved in the engraving. Separation of content and 
presentation is a topic that is not on the "edition" side in my view but 
on the technical side of producing an engraving.


This is not meant as an authoritative statement but more to express my 
feelings about organizing and sorting these things.


So, to come to the actual issue at hand: What does "edition engraver" 
sound like to me?
Although I know that an engraver has a specific technical meaning in 
LilyPond "edition engraver" sounds like a tool that engraves an edition. 
And while it definitely helps with "creating different editions from one 
source" this isn't what it is really doing. For example, I wouldn't call 
a printed part and a full score two editions. Usually such targets are 
part of the same "edition". In the traditional publishing business you'd 
consider a full score and a piano reduction as two different (although 
related) editions. In current digital edition concepts "edition" refers 
to the whole corpus of encoded content while the engraved result in one 
form or the other is "only" a more or less arbitrary "rendering" of that 
edition.


I think the "editions" that are set up using \addEdition are rather 
"targets" than "editions". I am adding mods for a given target, like 
full score vs. part, or e-book vs. printed version etc.
So \addTarget would seem more appropriate to me. Maybe one would want to 
make it more specific, maybe I could live with \addEditionTarget.



Basically these musings don't lead anywhere. But I thought I'd share 
them, maybe they trigger some ideas with someone else ...


Best
Urs


Best, Jan-Peter



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Jan-Peter Voigt]

Hi Urs,

Am 16.12.2014 um 22:28 schrieb Urs Liska:

Hi Jan-Peter,

that would be great.
I intend to write a post about the tool soon - from a user's, not from 
the developer's perspective. 

that would great :)

Maybe I should wait with this some more.

BTW: I'm still not completely convinced that edition-engraver really 
is the right name.

If you have a proposal, share it ;)

Best, Jan-Peter

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Urs Liska]

Hi Jan-Peter,

that would be great.
I intend to write a post about the tool soon - from a user's, not from 
the developer's perspective. Maybe I should wait with this some more.


BTW: I'm still not completely convinced that edition-engraver really is 
the right name.


In the meantime I have found a workaround for my problem at hand.
Well, it's not really a workaround but in fact an extremely more elegant 
and "semantically correct" solution for what I want to achieve.
Now I create two complete parts and do the partcombination to them as a 
whole - creating only one set of four voices.


Best
Urs

Am 16.12.2014 22:02, schrieb Jan-Peter Voigt:

Hi all,

I know about this issue and will hopefully have time to fix it soon.
I have to work until friday - lets see, how much I can do between the 
upcoming holydays.

So, hopefully I'm back with lily after christmas.

Best, Jan-Peter

Am 16.12.2014 um 18:46 schrieb Kieren MacMillan:

Hi Urs,

- enable the edition-engraver to address voices by their name 
instead of their index
This is an absolute MUST before the edition-engraver is recommendable 
on a large scale.


Just imagine what happens if you need to reference by index, and then 
add a context (Voice or Staff or anything) in the [vertical] middle 
of the system…

= CHAOS

I’m happy to help — both testing and sponsoring — to make this fix 
happen.


Best,
Kieren.
___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info





___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Jan-Peter Voigt]

Hi all,

I know about this issue and will hopefully have time to fix it soon.
I have to work until friday - lets see, how much I can do between the 
upcoming holydays.

So, hopefully I'm back with lily after christmas.

Best, Jan-Peter

Am 16.12.2014 um 18:46 schrieb Kieren MacMillan:

Hi Urs,


- enable the edition-engraver to address voices by their name instead of their 
index

This is an absolute MUST before the edition-engraver is recommendable on a 
large scale.

Just imagine what happens if you need to reference by index, and then add a 
context (Voice or Staff or anything) in the [vertical] middle of the system…
= CHAOS

I’m happy to help — both testing and sponsoring — to make this fix happen.

Best,
Kieren.
___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Kieren MacMillan]

Hi Urs,

> - enable the edition-engraver to address voices by their name instead of 
> their index

This is an absolute MUST before the edition-engraver is recommendable on a 
large scale.

Just imagine what happens if you need to reference by index, and then add a 
context (Voice or Staff or anything) in the [vertical] middle of the system…
= CHAOS

I’m happy to help — both testing and sponsoring — to make this fix happen.

Best,
Kieren.
___

Kieren MacMillan, composer
www:  
email:  i...@kierenmacmillan.info
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: edition-engraver and partcombine

[Urs Liska]

attachment ...

Am 16.12.2014 17:25, schrieb Urs Liska:

Hi all,

I have problems getting the edition-engraver to run properly, but I 
think the underlying issue is general enough so others may help too.
Well, initially it went quite well, but now I see a problem with the 
partcombiner.


IISC the edition engraver accesses the voices *after* the partcombiner 
does his job (I think so because the partcombiner merges voices when 
the input is parsed (???) while the edition-engraver works when for 
example the measure numbers are already known). So it is clear that I 
can't access individual voices that have been merged to 
\partcombineChords. And I think I can't address the original music 
variables independently either.


But that's not what I'm writing for.
I banged my head against the wall because the edition engraver didn't 
seem to be able to access the voices anymore in a given context, all 
that worked was addressing the staff (which proves that the basic 
set-up is correct).
Now I realized that the edition engraver produces a log file, and that 
gave me the clue to why the addressing didn't work anymore (although 
not about the underlying reason).
It seems LilyPond created new voices implicitly along the way of the 
piece, and therefore I'd have to address them not by "Voice.A" anymore 
but by "Voice.B" or ".G" etc.


From the measure numbers in the log I see that the spawning of new 
Voices is related to the partcombiner.
Basically my score works by concatenating music variables to each 
"part". But here I experiment with temporary part combinations.
There are four violoncello parts, originally engraved on individual 
staves. The idea is for selected sections to temporarily merge voices 
on fewer staves because that's musically clearer. So (pseudo-code) 
violoncelloI may look like


vc = {
  \one
  \two
  \partcombine
\threeI
\threeII
  \four
}

I have the impression that LilyPond creates a whole set of new voices 
when the \partcombine section happens, and this is what makes the 
voice list for that staff go up to "V" in the attached log.



So I think in order to get that to work smoothly I'd need either of 
the following solutions:


- talk LilyPond into not starting new Voices each time (or at least 
reusing old voices)
- enable the edition-engraver to address voices by their name instead 
of their index

  (I think the voice names stay the same in the partcombiner)

Any ideas would be greatly appreciated.
Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


[edition] score.Score.A (1)
[edition] strings.violoncello.solo.Staff.A (1)
[edition] strings.violoncello.solo.Voice.A (1 . (0/1))
[edition] strings.violoncelloI.Staff.A (1)
[edition] strings.violoncelloI.Voice.A (1 . (0/1))
[edition] strings.violoncelloI.Voice.B (92 . (0/1))
[edition] strings.violoncelloI.Voice.C (92 . (0/1))
[edition] strings.violoncelloI.Voice.D (92 . (0/1))
[edition] strings.violoncelloI.Voice.E (92 . (0/1))
[edition] strings.violoncelloI.Voice.F (97 . (1/2))
[edition] strings.violoncelloI.Voice.G (152 . (0/1))
[edition] strings.violoncelloI.Voice.H (152 . (0/1))
[edition] strings.violoncelloI.Voice.I (152 . (0/1))
[edition] strings.violoncelloI.Voice.J (152 . (0/1))
[edition] strings.violoncelloI.Voice.K (349 . (0/1))
[edition] strings.violoncelloI.Voice.L (349 . (0/1))
[edition] strings.violoncelloI.Voice.M (349 . (0/1))
[edition] strings.violoncelloI.Voice.N (349 . (0/1))
[edition] strings.violoncelloI.Voice.O (505 . (0/1))
[edition] strings.violoncelloI.Voice.P (505 . (0/1))
[edition] strings.violoncelloI.Voice.Q (505 . (0/1))
[edition] strings.violoncelloI.Voice.R (505 . (0/1))
[edition] strings.violoncelloI.Voice.S (549 . (0/1))
[edition] strings.violoncelloI.Voice.T (549 . (0/1))
[edition] strings.violoncelloI.Voice.U (549 . (0/1))
[edition] strings.violoncelloI.Voice.V (549 . (0/1))
[edition] strings.violoncelloII.Staff.A (1)
[edition] strings.violoncelloII.Voice.A (1 . (0/1))
[edition] strings.violoncelloII.Voice.B (92 . (0/1))
[edition] strings.violoncelloII.Voice.C (92 . (0/1))
[edition] strings.violoncelloII.Voice.D (92 . (0/1))
[edition] strings.violoncelloII.Voice.E (92 . (0/1))
[edition] strings.violoncelloII.Voice.F (97 . (1/2))
[edition] strings.violoncelloIII.Staff.A (1)
[edition] strings.violoncelloIII.Voice.A (1 . (0/1))
[edition] strings.violoncelloIII.Voice.B (368 . (0/1))
[edition] strings.violoncelloIII.Voice.C (368 . (0/1))
[edition] strings.violoncelloIII.Voice.D (368 . (0/1))
[edition] strings.violoncelloIII.Voice.E (368 . (0/1))
[edition] strings.violoncelloIII.Voice.F (403 . (0/1))
[edition] strings.violoncelloIII.Voice.G (403 . (0/1))
[edition] strings.violoncelloIII.Voice.H (403 . (0/1))
[edition] strings.violoncelloIII.Voice.I (403 . (0/1))
[edition] strings.violoncelloIII.Voice.J (617 . (0/1))
[edition] strings.violoncelloIII.Voice.K (617 . (0/1))
[edition] strings.violoncelloII