lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Naming convention brainstorming


From: Flaming Hakama by Elaine
Subject: Re: Naming convention brainstorming
Date: Mon, 2 Feb 2015 18:16:55 -0800


From: Urs Liska <address@hidden>
To: lilypond-user <address@hidden>
Subject: Naming convention brainstorming

Hi all,

for quite some time now I've been using a concept that is very useful,
but finally I'd like to give it an authoritative name to be used in
different places.

I'm talking about the working, thinking and compiling mode when I'm
working on the _content_ of a score and not it's final visual
appearance.


Sorry if I'm late to the party, but I was curious if you would mind also listing out what the other phases of work would be.  Seeing the whole workflow might make it clearer how this work is different than other kinds of work.

For example, is this workflow the same for composition as well as arranging or transcription?  Meaning, is the musical content considered to be complete before entering this phase?  Is this phase where musical content is entered?  Is musical content entered during any phase after this?


This mode is characterized for example by
- not caring too much about layout

I assume that by "not caring" you mean that you are not entering information about layout.  Because caring or not caring is not an activity related to lilypond workflow, per se.  Doing something about layout would be.
 
- not caring too much about engraving quality

Is "engraving quality" distinct from "layout"?  What parts of engraving fall outside of "layout"?

 
- being interested in visual feedback about manual interventions
   (e.g. coloring annotations or the result of custom functions)

From what follows, this seems to be the crux of what you are focused on:  visually highlighting the work done by particular functions.  It certainly seems to be only about visual feedback, although of a different kind than normal (temporarily, for the purpose of the developer, rather than finally for the consumer of the printed music.)

So, I am confused as to why this has anything to do with content whatsoever.  It sounds like it is *only* formatting, but of a preliminary intention.

Are there other use cases besides coloring?


There should be a common configuration option that library
authors can (and are encouraged to) respect in their functions. Say I
have a library function "\crossVoiceTie" that does all the work for me
with a hidden voice etc. Then this should highlight that tie or the
hidden noteheads when that special mode is active.

Are you suggesting that every library and function should include code to color the objects it is rendering based on this config option?  This seems somewhat backwards to me.  Seems like it would be better to ask every function to leave its fingerprint on the objects it renders, and then put the ability to color items based on those tags into something else.

( If lilypond were an object oriented language, you could have a superclass that did the coloring, and then make every library function a descendent of that class, so they would get the ability to color for free. )

This would also allow for more flexibility.  For example, I am using libraries A, B and C.  Assume that they are coded to color the way you want.  Can I only turn this on or off the coloring based on one setting?   What if I want to color only the objects rendered by library B, and not those of A and C?  What if I want to show library A's objects in red, library B's objects in green, and leave library C's objects alone?

I might wonder if a better approach would be to ask libraries to instead tag their output, and then write a color-by-configuration engraver (if that is the right concept) to interpret the tags based on the configuration options.  This could be a list of ((tagName1 color1) (tagName2 color2) ...)

 
This approach has proven extremely useful and I'd be happy to promote
this as a more general best-practice.

Again, I am asking for clarity:  is the utility for developing lilypond features, or useful for producing scores?  (Of course, once you have features, you can more easily produce scores.  But this mode seems immediately to be about producing the features.  Later, you switch to score-production mode.)
 
So what are your feelings about this mode of working *before* finishing
an engraving to publication quality?

I am still unclear on why this matters what stage of completion a score is in when you use this feature.


 
When collecting that list I realized that "entry mode" got three "votes"
- while I had already decided to settle on this term. I think this is
the most generic and unbiased way of expressing the idea, although even
this one is not perfect. What would perfectly match the essence would be
"edit mode" - but that is highly ambiguous so it is practically useless.

Again, I would enjoy some clarity on what you are editing.  Is it music, or lilypond functions?

Sounds like you have your mind made up.  But if you are still on the fence, I would also vote for terms that are closer to development terminology like "sandbox mode", "debug mode", or something that actually describes what it is doing like "highlight mode" or "highlight library artifacts mode".


 
Thanks for any opinions
Urs

--
Urs Liska
www.openlilylib.org

Thanks for soliciting ideas and dialogue.




David Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
address@hidden
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

reply via email to

[Prev in Thread] Current Thread [Next in Thread]