Re: clefs, time signatures, and key signatures

[Flaming Hakama by Elaine]

On Sat, Dec 9, 2023, 11:39 AM Werner LEMBERG  wrote:

> > I think that the distances between the clef and the sigs are improved
>
> Thanks, but which variant do you prefer?  The first image or the second
> image in
>
>   https://gitlab.com/lilypond/lilypond/-/merge_requests/2188
>
> ?
>
> Werner
>


for clef + key sig

treble   V1 (-1.9)
alto V1 (0)
bass old (0)
doubleG  V2 (10.7)
moveable V1 (-5.6)
mensural V2 (-21.8)


for clef + time sig

TBH I only use numerical time sigs
I don't think is going to be too worthwhile
my opinion of examples of the common time clefs
but it turns out I like all of V1

treble   V1 (-4.4)
alto V1/old (0)
bass V1 (-0.5)
doubleG  V1 (17.5)
moveable V1 (-6.1)
mensural V1 (-21.8)

Re: clefs, time signatures, and key signatures

[Flaming Hakama by Elaine]

>
> -- Forwarded message --
> From: Werner LEMBERG 
> To: lilypond-u...@gnu.org, lilypond-devel@gnu.org
> Cc:
> Bcc:
> Date: Sat, 09 Dec 2023 07:10:57 + (UTC)
> Subject: Re: clefs, time signatures, and key signatures
>
> >> please have a look at Merge Request 2188 and comment there on how
> >> to proceed with the new distances between clefs and time
> >> signatures, together with the new distances between clefs and key
> >> signatures.
> >>
> >>   https://gitlab.com/lilypond/lilypond/-/merge_requests/2188
> >>
> >> The question is whether the new distances should be based on the
> >> widest standard clef glyph (which is the alto clef, and which is
> >> done currently in the MR), or whether they should be based on the
> >> most common one, the treble clef.
> >
> > For better comparison, I've updated/added the screenshots in the MR
> > so that you can do a blink-comparison of the images.
>
> A few people responded, and the opinions are exactly 50:50.  It would
> be great if more people could chime in!
>
>
> Werner
>

I think that the distances between the clef and the sigs are improved

Elaine

Re: The final stage of my GSoC project

[Flaming Hakama by Elaine]

>
> From: Jason Yip 
> To: lilypond-devel@gnu.org
> Cc: Carl Sorensen 
> Bcc:
> Date: Wed, 9 Aug 2023 16:55:10 -0700
> Subject: The final stage of my GSoC project
> Hey everyone,
>
> Last week I made a draft merge request for the changes that my project
> brings, since I finished most codebase changes, which are the most
> interesting part, and the finish line was quite close with just the
> remaining documentation/regression test work left. Now, I think that my
> merge request for my project is ready and have removed its draft status.
> You can view it at
> https://gitlab.com/lilypond/lilypond/-/merge_requests/2080 and leave
> feedback on it. It will be the URL of my GSoC project page. I hope that
> any remaining final touches for my merge request are completed before
> the end of the project timeline.
>
> This has been a fun project and I want to thank those who have helped me
> understand the Lilypond codebase! I'm always happy to stick around after
> the end of the project to help improve Lilypond further, although I will
> have to shift my focus towards my new university term that starts soon.
> While I have the time, I may consider writing a blog post about my beam
> subdivision algorithm in detail later as I admire its handling of the
> intricacies of music theory.
>
>
> --
> - Jason Yip
>


It is great to see a GSoC project moving along so nicely.

I'll admit I have not been paying enough attention to this project
to know whether or not the improvements will address the
beaming use case that I run into.

Or, maybe my use case can already be addressed and I simply
don't fully understand how to use automatic beaming?

My use case is for a preferred way to beam 8ths in 4/4 is

c8 [ 8 8 8 ]  c8 [ 8 8 8 ]

Which, of course, is straightforward.  However, when there are
only 3 8th notes, I prefer to beam to the beat like

r8 c c [ c ]  r c c [ c ]
c8 [ c ] c r  c [ c ] c r

Rather than the current behavior, which is to beam all 3 notes like

r8 c [ c c ]  r c [ c c ]
c8 [ c c ] r  c [ c c ] r

I do know how to set automatic beaming to produce that,
but in that case, the 4 8th note case becomes

c8 [ c ]  c [ c ]  c [ c ]  c [ c ]

So, can anyone explain whether it is, or will be, possible
to have automatic beaming in 4/4 that behaves like this:

c8 [ c c c ]  c [ c c c ]
r8 c c [ c ]  r c c [ c ]
c8 [ c ] c r  c [ c ] c r


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Time-signature cancellation

[Flaming Hakama by Elaine]

>
>
> -- Forwarded message --
> From: Lukas-Fabian Moser 
> To:
> Cc: lilypond-devel@gnu.org
> Bcc:
> Date: Sun, 4 Jun 2023 09:50:06 +0200
> Subject: Re: Clef, key, and time-signature changes
>
> > I have sometimes needed to reprint a time signature even if it wasn't
> > different.
>
> +1
>
> Of course it would be nice to have a consistent behaviour for clef, time
> signature, key signature. But note that those three entities are
> conceptually different in that clef / key signature are per-staff while
> the time signature is (usually) per-score.
>
> I've been wondering for a while now if "forcing a clef" should really be
> done via a one-time-only context property. Wouldn't it make more sense
> to control this in a persistent setting (a context property in Timing or
> Staff, respectively) that controls whether a "\clef XX" gets discarded
> if the previous clef already was XX? So the behaviour with respect to
> "redundant" \clef, \key or \time commands could be controlled in \layout
> { } ?
>
> Lukas
>

I guess I am kind of confused at the default behavior, why does lilypond
not reprint a clef when you specify \clef ?

Are people putting \clef commands in their code where they don't want a
clef to appear?
Is this a common practice?


Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: what does it take to produce a new output block

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: Flaming Hakama by Elaine 
> To: lilypond-devel 
> Cc:
> Bcc:
> Date: Tue, 31 May 2022 14:02:51 -0700
> Subject: what does it take to produce a new output block
> Hi,
>
> I am interesting in seeing what it would take to enhance lilypond to output
> in this text format
>
> https://www.irealpro.com/ireal-pro-file-format
>
> My first idea would be to add something along the lines of the midi block,
> where if you add this new output, you will get output in this text format,
> which is essentially an HTML link.
>
> \score {
>   … music …
>   \layout { }
>   \midi { }
>   \ireal { }
> }
>
>
> I suppose it should support similar features for command line and scheme:
>
> -direal-extension=html
> #(ly:set-option 'ireal-extension "html")
>
>
> To look into implementing this, where would I get started?
>
> Is there any documentation that describes what exactly is a block, what it
> takes as input, etc.?
>
> Where would I find the code for the layout and midi blocks?
>
>
> Thanks,
>
> Elaine
>
>
>
>
> -- Forwarded message --
> From: Jean Abou Samra 
> To: Flaming Hakama by Elaine , lilypond-devel <
> lilypond-devel@gnu.org>
> Cc:
> Bcc:
> Date: Tue, 31 May 2022 23:24:44 +0200
> Subject: Re: what does it take to produce a new output block
> Hi,
>
> A minor point of procedure: even though you changed the subject, it
> appears that you started this thread from a previous thread about time
> signatures in your email client. The email contains headers that make it
> appear in that thread for others. In the future, start a new thread
> every time.
>
>
> Le 31/05/2022 à 23:02, Flaming Hakama by Elaine a écrit :
> > Hi,
> >
> > I am interesting in seeing what it would take to enhance lilypond to
> output
> > in this text format
> >
> > https://www.irealpro.com/ireal-pro-file-format
> >
> > My first idea would be to add something along the lines of the midi
> block,
> > where if you add this new output, you will get output in this text
> format,
> > which is essentially an HTML link.
> >
> > \score {
> >… music …
> >\layout { }
> >\midi { }
> >\ireal { }
> > }
> >
> >
> > I suppose it should support similar features for command line and scheme:
> >
> > -direal-extension=html
> > #(ly:set-option 'ireal-extension "html")
> >
> >
> > To look into implementing this, where would I get started?
>
>
>
> I would start by writing Scheme engravers living in \layout
> that take the content and format it together. The only disadvantage
> is that won't have ireal output without at the same time doing
> layout output (well, unless you go for calling (exit) at the
> end of the translation step if that's really a problem ...).
> The big advantage is that you can start doing this right now
> in a .ly file, without touching LilyPond's code at all, post
> it on the user list and get feedback.
>
> There is no official documentation for engravers, but there
> is an unofficial resource (by me):
>
> https://extending-lilypond.readthedocs.io/en/latest/translation.html
>
>
>
> > Is there any documentation that describes what exactly is a block, what
> it
> > takes as input, etc.?
>
>
> Well, LilyPond doesn't really have a notion of a "block".
> The objects you create with \midi and \layout are called
> "output definitions" (output defs for shorts), a category
> which actually also encompasses \paper blocks. I guess the
> closest you get as documentation about output defs is
>
>
> https://lilypond.org/doc/v2.23/Documentation/notation/modifying-context-plug_002dins.html
>
> but this is not really descriptive of the internals, and
> I don't think it needs to be: output defs are an overarching
> concept where many tweaks take place; the way these tweaks
> are arranged internally isn't really relevant to the user.
>
> Most importantly, \layout and \midi are hardcoded. You
> cannot create you own type of "block" without touching
> the C++ sources.
>
>
>
> > Where would I find the code for the layout and midi blocks?
>
>
> A bit all over the place, really. lily/lexer.ll and lily/parser.hh
> have the parsing logic, with some bits in lily/lily-lexer.cc
> and lily/lily-parser.cc. The Output_def class is found in
> lily/output-def.cc. The Scheme interfaces for manipulating
> it are in lily/output-def-scheme.cc. A central element of output
> defs is context defs (the \c

what does it take to produce a new output block

[Flaming Hakama by Elaine]

Hi,

I am interesting in seeing what it would take to enhance lilypond to output
in this text format

https://www.irealpro.com/ireal-pro-file-format

My first idea would be to add something along the lines of the midi block,
where if you add this new output, you will get output in this text format,
which is essentially an HTML link.

\score {
  … music …
  \layout { }
  \midi { }
  \ireal { }
}


I suppose it should support similar features for command line and scheme:

-direal-extension=html
#(ly:set-option 'ireal-extension "html")


To look into implementing this, where would I get started?

Is there any documentation that describes what exactly is a block, what it
takes as input, etc.?

Where would I find the code for the layout and midi blocks?


Thanks,

Elaine

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

On Mon, Nov 15, 2021 at 11:11 AM David Kastrup  wrote:

> Carl Sorensen  writes:
>
> > On 11/15/21, 10:21 AM, "lilypond-devel on behalf of Flaming Hakama by
> Elaine"  on behalf of ela...@flaminghakama.com> wrote:
> >
> >
> > According to the semantics quoted several times, the denominator
> describes
> > the length/duration of the unit, the numerator describes how many
> units are
> > in the measure.
> >
> > There is some space for confusion in the LilyPond world.  Moments
> represent a musical moment, an instant in time.  But a moment is also used
> to represent a time interval between the current moment and the zero moment
> (such as the beginning of  a measure).  So a moment also can be used to
> represent an interval, as is applied in the time signature.  I should have
> been more sensitive to this, because I created the BaseMoment property to
> be used in autobeaming; this property represents and interval starting at 0
> and ending at the moment BaseMoment.
> >
> > In terms of semantics, numerals and note representation operate
> exactly the
> > same.  There is  a 1-1 mapping between numbers interpreted as
> fractions of
> > a whole note, and the graphical symbols used to represent those
> > durations/lengths.
>
> That is simply untrue.
>


First of all, thanks for the considered response.


> \tuplet 2/3 { 4 } and 4. are different graphical symbols representing
> exactly the same length.  Similarly \tuplet 3/2 ... and \tuplet 6/4
> ... represent the exactly the same length but have different graphical
> representations, note durations and musical semantics.
>
> Claiming that there is a 1-1 mapping and that one can exchange on for
> the other in the internals without consequences is just not going to
> help.
>
> And there is a huge tendency here to conflate that the existence of an
> n->1 mapping for durations/graphics to a moment length with the
> existence of a 1-1 mapping and to build lots of strawmen based on
> claiming I deny the existence of the n->1 mapping and "proving" in that
> manner that I don't know what I am talking about.
>
>
Regarding 1 => 1, vs N => 1, vs 1 => N,
yes I agree I was hand wavy and incorrect.

What I meant to say was that there is a reliable way to find a default.

If you want 1 ==> 1, but have 1 ==> N, that means you can always find at
least one value in that range, and you can construct a 1 ==> 1 mapping.  I
am suggesting that we can find the most reasonable value to
use, that mapping will be a good default.



> > Now, music expressions also have a length, even if they don't have a
> > lilypond duration.  And it is possible to get the length of a music
> > expression and return it as a Moment using ly:music-length.  So if it
> > were possible to have the parser (or a music function) take two
> > arguments for a time signature, with the first being an integer and
> > the second being a music expression, it would be relatively
> > straightforward to convert this into a reasonable time signature.
>
> Where "convert this into a reasonable time signature" would imply the
> ability to convert this into the two separate components, a functional
> and a visual one.  At the current point of time, something like
> 2/4. (for what is commonly referred to as 6/8 in standard notation) has
> no natural conversion to the functional components
> numerator/denominator.  One could do this "more naturally" by allowing
> the "denominator" to be a rational number instead of just an integer.
>

In general, I agree that there are distinct things, the functional and
visual.

However, it is worth pointing out that, In all cases, there can be more
than one visual representation for a length.

So, this issue seems to be general, and not related to these more modern
time signatures under proposal.  The questions should be more like, can we
come up with useful and meaningful defaults for given time sigs, like we
have for standard sigs?

In particular, it is not clear what you mean about 6/8 being a case where
it is not clear how to interpret it.  Certainly, in all cases, the length
part is uniquely determined.  So, it is either the visual representation,
or the beaming that you are referring to.

In 6/8, the visual representation is clear, if we wanted to show a note,
we'd show an 8th note.

Since I think we all agree that beaming subdivisions are just about
conventions, and there is no way to determine them based on values, 6/8 is
an example where we have rules to help supply default conventions since it
is not implicit in the value.


> The _visual_ component still needs a separate expression that probably
> sticks best wi

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

>
>
> -- Forwarded message --
> From: Jean Abou Samra 
> To: Flaming Hakama by Elaine , lilypond-devel <
> lilypond-devel@gnu.org>
> Cc:
> Bcc:
> Date: Mon, 15 Nov 2021 19:54:44 +0100
> Subject: Re: TimeSignature with note in denominator
> Le 13/11/2021 à 04:21, Flaming Hakama by Elaine a écrit :
> > So, I guess for me this is a 2- or 3-part trick question.
> >
> > The first is, how is the usage of \time different in lyrics than anywhere
> > else?
> >
> > Frankly, I was not aware that using \time inside lyrics was a thing.
> > What is the reason to use \time inside lyrics?
> > It is a suggested practice, is it the only way of doing certain things?
> >
> > If it is interpreted differently in lyrics than elsewhere,
> > is that a pattern that we want to keep?
> >
> > Or should we fix it so that it behaves the same in both contexts?
> >
> >
> > The second has to do with the example syntax.
> > I don't suppose it will change your use case,
> > but just to be clear, I was proposing it might be possible
> > to distinguish a number from a duration by using {}
> >
> > So, for one thing, you used it in the numerator
> > where I was suspecting it would only ever appear in the denominator,
> > so it would be more like;
> >
> > \lyrics { \time 4/4 + 4/{8} }
> >
> > But really, that was just for doing a shorthand notation, I was not
> > formally proposing that syntax.
> >
> >
> >
> > Rather, I was rather suggesting that it be used in the syntax of
> >
> > \lyrics { \compoundTime #{{4 4) (4 {8})) }
> >
> > I suspect that using {} to distinguish number from duration is still not
> > going to cut it in this usage, either.
> >
> > But I suspect that there could be some other kind of way to modify either
> > the data type (number vs string?) of that denominator argument so that it
> > was clear which representation was intended.
>
>
> Elaine,
>
> I'm sorry if it came across as a 'trick question'.
> It was certainly not meant such.
>

Sorry, I didn't mean to imply that.

Really, I was just saying that I was unaware that the \time function had
parser rules in lyrics versus music contexts.

In general, though, whether it is lyrics context or music context, I agree
with this point:


> My point was merely that -- independently of the
> specific case at hand here -- there are technicalities
> that cannot be avoided. So I was trying to explain
> why LilyPond developers may make decisions of
> syntax that sometimes even them would like to see
> differently if only considering the intuitiveness, and
> not the special cases, the programmability, the
> possibility/ease of writing good error messages
> for invalid input, the flexibility of the parser
> tooling, etc.
>

Yes, while we might want to start brainstorming ideas about syntax that
seems expressive, given the existing syntax and parse rules, many of the
obvious choices would not be available, since those symbols already have
meanings.


>
> I don't have much to add, and the discussion is
> already well-furnished, so I won't comment
> further on the specific topic for now.
>
> Kind regards,
> Jean
>


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

On Mon, Nov 15, 2021 at 3:30 AM David Kastrup  wrote:

> Flaming Hakama by Elaine  writes:
>
> > From: David Kastrup 
>
> >> Kieren MacMillan  writes:
> >> > The time signature “9/8” does *not* (as you imply) actually convey
> >> > *any* information about the number of “beats” — the *convention* does
> >> > that.
> >>
> >> I am certain you will be able to provide a definite quote where I
> >> "imply" any such thing.
> >>
> >
> > So, are you claiming that this is a misquote?
> >
> > [David K:]
> >> 8/20 does not specify more than the basic
> >> subdivision for expressing beats (not necessarily identical with the
> >> number of beats as signatures like 9/8 show)
>
> I have problems imagining how myself quoting an example of a signature
> with different conventions than derived from the raw fraction is proof
> that I imply that the raw fraction carries all the information.
>
> Seriously.
>

What is serious is that you seem incapable of either admitting that your
statement is incorrect, or explaining what you mean.

So, are you going to stand behind your statement and explain it, or admit
that it is wrong?


> > The feature request is to render 9/8 with an 8th note instead of the
> > numeral 8 as the denominator.
>
> The discussion long ago stopped being about the printed result and
> rather focused on the internals of time signature representation.
>

Then why are you bringing up the topic of subdivision?



> > The feature request is to render 8/20 with a 16th note quintuplet note
> > instead of the numeral 20 as the denominator.
>
> No, it never was that.  I quoted the 8/20 signature mention in
> LilyPond's code as an example where there _is_ no unique graphic
> representation of the composers intent possible just given the
> information of 8/20 because it could be equally well intended to express
> the basic duration to use as quintuplet or as 10-tuplet.
>

Again, it has been explained several times that there is a unique graphic
representation of a 16th note quintuplet.

Are you stil disagreeing with that?

Maybe we could all use some perspective:  could you show us several unique
representations of a 16th note quintuplet?



> > Why is the subdivision of the measure relevant?
>
> Because there are different print forms for various ways of expressing
> 1/20 and the composer might not even have wanted to be definitive in
> choosing one.
>

Ok, so you initially brought up the topic of subdivision as being
important.

Then in this most recent response, you did 180 and said that it is, in
fact, not relevant.

Now we're back to subdivision being relevant?


ot everyone picking 6/8 unambigulously wants to see this interpreted as
> 2 notes of 4. duration.  So forcing a particular duration expressing a
> length not inherently specified is putting words in the composer's
> mouth.
>

Ok, so now you are saying that any such issues with subdivision exist with
garden variety time signatures, too.

So, if the issue exists with existing supported time signatures, why is it
relevant to this feature request?



>
> >> > I suppose Carl and my surprise (revelation?) is that Lilypond has
> >> > *never* handled time signatures correctly (where “correct” means
> >> > “according to the accepted definition of 'time signature'”).
> >>
> >> Nor has his ever handled durations correctly according to your
> >> definition of "duration".  Which means you should get a grip on what
> >> LilyPond calls a duration before proposing to use it.
> >
> > So, are you defending incorrect semantics?
>
> Tuplet _notation_ is "incorrect semantics" according to your
> classification.  In the end, LilyPond follows what printed music does.
> It may be more awkward than required when generating Midi or
> programmatically manipulating music but it's firmly tied into notation
> practice.
>

According to the semantics quoted several times, the denominator describes
the length/duration of the unit, the numerator describes how many units are
in the measure.

In terms of semantics, numerals and note representation operate exactly the
same.  There is  a 1-1 mapping between numbers interpreted as fractions of
a whole note, and the graphical symbols used to represent those
durations/lengths.

What makes you say that tuplet notation is incorrect semantics by
my classification?

Do you think that "my classification" differs from the standard
definition?




>
> > The point is that the current implementation does not support the
> > necessary semantics.
> >
> > So, you can whine about people not understandin

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: David Kastrup 
> To: Kieren MacMillan 
> Cc: Carl Sorensen , LilyPond development <
> lilypond-devel@gnu.org>
> Bcc:
> Date: Sun, 14 Nov 2021 20:11:03 +0100
> Subject: Re: TimeSignature with note in denominator
> Kieren MacMillan  writes:
>
> > [David K:]
> >> 8/20 does not specify more than the basic
> >> subdivision for expressing beats (not necessarily identical with the
> >> number of beats as signatures like 9/8 show)
> >
> > Ah, I think I now see where your confusion lies.
>
> It's great that you show so much patience with rank beginners in
> LilyPond.
>
> > The time signatures 8/20 and 9/8 *do* function identically:
> > — the bottom number identifies the duration, *expressed as a fraction
> > of a whole number*, that should be considered the functional division
> > of the measure;
>
> And here is where your plan falls down because LilyPond's definition of
> a duration does not agree with the words you are comfortable throwing
> around because of your education.  What you are thinking of is a Moment,
> the unit in which the _length_ of a duration is expressed.  There is no
> 1:1 mapping between moments and durations: various different durations
> may correspond to a single moment when involving scale factors, and lots
> of moments don't have corresponding durations when you forego scale
> factors.
>
> > — the top number identifies how many functional divisions are required
> > to fill a complete measure.
> >
> > *By convention*, traditional classical music groups the 9
> > one-eighth-of-a-whole-note events into three groups of three each,
> > leading people to say that the duration of a “beat” is equal (in that
> > case) to three eighth notes.
> >
> > The time signature “9/8” does *not* (as you imply) actually convey
> > *any* information about the number of “beats” — the *convention* does
> > that.
>
> I am certain you will be able to provide a definite quote where I
> "imply" any such thing.
>

So, are you claiming that this is a misquote?

[David K:]
> 8/20 does not specify more than the basic
> subdivision for expressing beats (not necessarily identical with the
> number of beats as signatures like 9/8 show)


The feature request is to render 9/8 with an 8th note instead of the
numeral 8 as the denominator.

The feature request is to render 8/20 with a 16th note quintuplet note
instead of the numeral 20 as the denominator.

Why is the subdivision of the measure relevant?


And how is the musical convention of 9/8 being 3 beats implied by the
expression 9/8?




> > I suppose Carl and my surprise (revelation?) is that Lilypond has
> > *never* handled time signatures correctly (where “correct” means
> > “according to the accepted definition of 'time signature'”).
>
> Nor has his ever handled durations correctly according to your
> definition of "duration".  Which means you should get a grip on what
> LilyPond calls a duration before proposing to use it.
>
> --
> David Kastrup
>

So, are you defending incorrect semantics?


The point is that the current implementation does not support the necessary
semantics.

So, you can whine about people not understanding how the implementation
works, but if you want to be helpful, instead, please try to help us
understand what the gap is so that others can work on figuring out how to
address it.

Until we know what's broken, we can't fix it.

Also, the notion that the level of complexity being proposed is somehow
problematic, seems misleading.

Based on the fact that the function can actually take either one or two
arguments, means that there is already some amount of logic based on
detecting argument types.

Suggesting that adding another such condition would be unfeasible is either
untrue, or it means that the current approach is not scalable and is more
of a hack.



Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

>
> -- Forwarded message --
> From: Jean Abou Samra 
> To: Kieren MacMillan , Flaming Hakama by
> Elaine 
> Cc: LilyPond development , David Kastrup <
> d...@gnu.org>
> Bcc:
> Date: Fri, 12 Nov 2021 23:49:13 +0100
> Subject: Re: TimeSignature with note in denominator
>
>
>

> Humans can tolerate ambiguity, computers can't.
>

I would argue that for well-designed systems,
you don't want ambiguity for humans, either.



> Assuming that I am wrong and it could actually
> work in lyric mode, how would you parse the
> following?
>
> \lyrics { \time 4/4 + {4}/8 }
>
> It is already valid syntax.
>
> Best,
> Jean
>

So, I guess for me this is a 2- or 3-part trick question.

The first is, how is the usage of \time different in lyrics than anywhere
else?

Frankly, I was not aware that using \time inside lyrics was a thing.
What is the reason to use \time inside lyrics?
It is a suggested practice, is it the only way of doing certain things?

If it is interpreted differently in lyrics than elsewhere,
is that a pattern that we want to keep?

Or should we fix it so that it behaves the same in both contexts?


The second has to do with the example syntax.
I don't suppose it will change your use case,
but just to be clear, I was proposing it might be possible
to distinguish a number from a duration by using {}

So, for one thing, you used it in the numerator
where I was suspecting it would only ever appear in the denominator,
so it would be more like;

\lyrics { \time 4/4 + 4/{8} }

But really, that was just for doing a shorthand notation, I was not
formally proposing that syntax.



Rather, I was rather suggesting that it be used in the syntax of

\lyrics { \compoundTime #{{4 4) (4 {8})) }

I suspect that using {} to distinguish number from duration is still not
going to cut it in this usage, either.

But I suspect that there could be some other kind of way to modify either
the data type (number vs string?) of that denominator argument so that it
was clear which representation was intended.



Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: TimeSignature with note in denominator

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: Kieren MacMillan 
> To: LilyPond development 
> Cc: Aaron Hill , Dan Eble 
> Bcc:
> Date: Fri, 12 Nov 2021 10:41:46 -0500
> Subject: Re: TimeSignature with note in denominator
> Hi all,
>
> I’m not sure whether I’m waiting for others to move this discussion
> forward…?
>
> Assuming I’m not:
>
> 1. In *my* mind, the optimal situation *from the user/UI perspective*
> would be to have a single public interface
>
>\time BLAH FOO BAR etc.
>
> which would gracefully and transparently handle all possible time
> signature demands: simple and compound sigs, all possible “denominator”
> representations, beat structures, etc. My first question in this regard: Am
> I wrong [from the user/UI perspective]? I totally get that it may be
> unadvisable from the programmers’ perspective (and for sure from
> backwards-compatibility perspective, etc.) — my question here is more one
> of Lilypond programming philosophy.
>

Yes, this is what I would expect.

What could possibly be the motivation for anything else?

They are all just time signatures.

I suspect they would have to be one function, because how else would you
combine the two?  Each denominator could be either a number or note.

4/4 + 3/4
6/8 + 1/{2}
1/{8.} + 2/4
2/{4} + 3/{8.}

\compoundMeter #'((4 4) (3 4))
\compoundMeter #'((6 8) (1 {2}))
\compoundMeter #'((1 {8.}) (2 4))
\compoundMeter #'((2 {4}) (3 {8.}))

or

\compoundMeter #'((4 4) (3 4))
\compoundMeterSecondUsingNoteDenominator #'((6 8) (1 2))
\compoundMeterFirstUsingNoteDenominator #'((1 8.) (2 4))
\compoundMeterUsingNoteDenominators #'((2 4) (3 8.))



-- Forwarded message --
> From: David Kastrup 
> To: Kieren MacMillan 
> Cc: LilyPond development , Dan Eble
> 
> Bcc:
> Date: Fri, 12 Nov 2021 17:26:32 +0100
> Subject: Re: TimeSignature with note in denominator
> Kieren MacMillan  writes:
>
> > Hi all,
> >
> > I’m not sure whether I’m waiting for others to move this discussion
> forward…?
> >
> > Assuming I’m not:
> >
> > 1. In *my* mind, the optimal situation *from the user/UI perspective*
> > would be to have a single public interface
> >
> >\time BLAH FOO BAR etc.
> >
> > which would gracefully and transparently handle all possible time
> > signature demands: simple and compound sigs, all possible
> > “denominator” representations, beat structures, etc. My first question
> > in this regard: Am I wrong [from the user/UI perspective]? I totally
> > get that it may be unadvisable from the programmers’ perspective (and
> > for sure from backwards-compatibility perspective, etc.) — my question
> > here is more one of Lilypond programming philosophy.
>
> Personally, I don't see how making it hard for the computer to figure
> out what of a myriad of variants in meaning is intended makes it
> reasonable for the user to see what is intended.
>

No, the point would be to first devise something that users can understand.

If users can understand it, it is possible to get the computer to do so.

Not the other way around.



Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: MIDI rendition of things like rall./acc./rit./fermata

[Flaming Hakama by Elaine]

David,

On Mon, Jun 14, 2021 at 6:46 PM David Kastrup  wrote:

>
> You saw the followup?


Well, it seems I missed the follow up.
Glad to see the functional approach.


> The one with
>
> tempoChange =
> #(define-music-function (interval endscale thenscale music)
>(ly:duration? scale? (scale? 1) ly:music?)
>   "Make a gradual tempo change over @var{music}, essentially changing
> speed after
> every duration of @var{interval}, approaching a factor of speed of
> @var{endscale}
> compared to the start.  Afterwards, tempo is switched to @var{endscale} of
> the
> original speed (default 1).  If @var{endscale} is 0, the speed reached at
> the
> end is just maintained and can be overriden with an explicit @samp{\\tempo}
> command if required."
>(define (scaletempo oldscale newscale)
>  (make-apply-context
>   (lambda (ctx)
> (set! (ly:context-property ctx 'tempoWholesPerMinute)
>  (ly:moment-mul (ly:context-property ctx 'tempoWholesPerMinute)
>  (ly:make-moment (/ newscale oldscale)))
>
>(let* ((muslen (ly:moment-main (ly:music-length music)))
>   (intlen (ly:moment-main (ly:duration-length interval)))
>   (steps (/ muslen intlen))
>   (endfactor (scale->factor endscale))
>   (thenfactor (scale->factor thenscale)))
>  (make-simultaneous-music
>   (list music
> (context-spec-music
>  (make-sequential-music
>   (let loop ((rsteplst (iota (1+ steps) endfactor (/ (- 1
> endfactor) steps)))
>  (res (if (positive? thenfactor)
>   (list (scaletempo endfactor thenfactor))
>   (list
> (if (null? (cdr rsteplst))
> res
> (loop (cdr rsteplst)
>   (cons* (scaletempo (cadr rsteplst) (car
> rsteplst))
>  (make-skip-music (ly:make-duration 0 0
> intlen))
>  res)
>  'Score)
>
> in it?
>
> --
> David Kastrup
>


Things I would suggest to consider:

Since this is presumably making several tempo changes in succession, I
think that singular "tempoChange" is a bit misleading.  Isn't \tempo
already a tempo change?   I would suggest "tempoTransition".

Some parts of this usage are a bit confusing.  If I am slowing from 4=104
to 4=92, as a user of this function, I am supposed to do the math and enter
whatever the ratio 92/104 is?  (Or, I have to write a  scheme expression to
do the calculation)?  Seems like it would be easier and clearer to just
specify the resulting tempo, and let the function do the math to figure out
the ratio.

It would be helpful to document the variable "thenscale".  Perhaps you used
"endscale" instead of "thenscale" in some places in the comments?

I am not sure I understand the notion of fiddling with the final tempo.  In
general, specifying a tempo is for the music that follows.  So to specify a
tempo change and then have to do something else to maintain that tempo
seems like extra.  I can see that if you are going back to a Tempo, such a
feature might seem useful.  But in those cases, aren't you also going
(assuming you are doing both MIDI and PDF) going to add \tempo "a Tempo"
anyway?


Thanks.


HTH,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: MIDI rendition of things like rall./acc./rit./fermata

[Flaming Hakama by Elaine]

>
> -- Forwarded message --
> From: David Kastrup 
> To: lilypond-devel@gnu.org
> Cc:
> Bcc:
> Date: Sun, 13 Jun 2021 00:48:34 +0200
> Subject: MIDI rendition of things like rall./acc./rit./fermata
>
> Hi,
>
> I am currently working on creating MIDI tracks for percussion (for many
> accordion orchestra scores, there is sort of a discretionary percussion
> part), sort of a glorified metronome substitute (considerably more fun).
>
> What the articulate script does with rit/rall/a tempo is a disgrace (it
> switches the tempo down at the point of rit/rall and picks it up again
> at a tempo) and only moderately robust because it works on music input
> rather than at the translation stage.  I presume that the relation of
> all voices according to their notated time should stay the same even in
> polyrhythmic situations; this makes the problem boil down to one of
> translating common-time to MIDI time.
>
> \tempo changes that translation but only for increments, and with a
> constant factor.
>
> So how robust (or not) would be the following approach?  Make it
> possible to write in the timing track something like
>
> \rit 2/3 { \skip 1*2 }
>

In general, I think there are too many things (fermata, ceasura, rit/accel,
trills, repeats with dual dynamics) that need to be dealt with in midi,
such that you will always need dedicated tag sets for MIDI/PDF or some such.

That is, if you want the MIDI to sound good.

I would suspect that, for a rit for example, you will not always want
linear tempo changes, and will want to tweak them.

The longhand way of doing it is to just create a new tempo on each beat or
so ( within the MIDI tag).  I think that your suggestion for a shorthand
would be more useful as a function used within the MIDI tagged content,
rather than after the fact inside the articulate script, where you will be
guessing.

I'd like to see the function take these arguments:
* duration of the section (or provide a music expression that can be
evaluated to determine the duration)
* starting tempo (default to current tempo?)
* ending tempo
* either the rhythmic distance between tempi changes, as you suggest, or I
think it would be better to be an integer representing the number of steps
desired
* some kind of representation of the curve to be used, such as a keyword
for an algo known by the function (linear, log, etc.) and if it were more
fancy, also take arguments for parameters of the known functions, or it it
were really fancy, you could supply your own function to do the calculation.

This function would output a series of spaces and tempi.

Usage would be like:
{
\tempo 4=100
\tag #'PDF { <>_{accel.} s1*3 }
\tag #"MIDI {
\createAccel s1*3 4=100 4=120 6 "linear"
}
\tempo 4=120
}

And this would turn into something like:
{
\tempo 4=100
\tag #'PDF { <>_{accel.} s1*3 }
\tag #"MIDI {
s2
\tempo 4=104
s2
\tempo 4=108 |
s2
\tempo 4=112
s2
\tempo 4=116 |
s2
\tempo 4=120
s2
\tempo 4=124 | % not sure if we want/need this final one
  }
  \tempo 4=124
}


> with the effect that some run-always translator keeps adjusting
> tempoWholesPerMinute during the \skip (in proportion to where the time
> is) until it is at 2/3 the speed at the end when it gets reset.  That's
> somewhat sloppy since the tempo is not adjusted during long notes, so in
> particular a long first note would not get slowed down at all.
>
> If I get the run-always semantics right.  But if I don't (and if one
> does not care about the inconsistency of long notes), one can always
> write
>
> \rit 2/3 { \repeat unfold 32 \skip 32 }
>
> It would not really need to be written in a separate timing track, you
> could just write ordinary music inside.
>
> Does this sound feasible?
>
> In a similar vein, one could do a fermata by just switching
> tempoWholesPerMinute to 2/3 of its value for a single note.  Though this
> does not necessarily need to be the same mechanism, though it likely
> could.
>
> --
> David Kastrup
>



Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: A question of rendering multiple instances of \arpeggio in MIDI

[Flaming Hakama by Elaine]

>
> -- Forwarded message --
> From: "Petr Pařízek" 
> To: lilypond-devel@gnu.org
> Cc:
> Bcc:
> Date: Fri, 16 Apr 2021 04:39:59 +0200
> Subject: A question of rendering multiple instances of \arpeggio in MIDI
> Hello,
>
> originally I wanted to ask two questions but I'll leave my second
> question for a different thread so that the two topics don't get mixed up.
> I currently use LilyPond 2.22 on my Windows machine.
> Via simple web search, I was trying to find some info on the possibility
> of rendering arpeggios in MIDI files. What I found was an older
> discussion (I don't remember the URL) from which it seemed to me that
> such a feature was actually not planned to be implemented, even though
> many other kinds of performance markings could be rendered in the MIDI
> file via the "articulate" script.
> My question is: Is my understanding correct that implementing such a
> feature would, in one way or another, be troublesome and that doing so
> is not considered a good idea? Or is the reason something else?
> I'm asking because I can name at least 4 different ways in which this
> feature would help me tremendously:
> - 1) I'm blind. Therefore, if I want to make sheet music available to
> other people, MIDI files are the one and only way I can locate typos in
> my .ly file (an invaluable feature, numerous times has it helped me spot
> really serious errors in my input text!). If I could render the
> arpeggios in the MIDI file similarly to rendering ornamentation or
> accents or other stuff, I could then easily check whether I have indeed
> used a \arpeggio at the particular spot or not.
> - 2) If this were possible, I wouldn't have to manually turn all the
> arpeggios into written-out notes while repeatedly switching
> \tieWaitForNote on and off. Doing something like this is time-consuming
> even for one single arpeggio because it can't easily be automated.
> Therefore if my score contains more than 30 of them, I don't even try to
> imagine how much time it would take. And I may easily forget to do that
> at one spot if there are so many of them. In contrast, introducing a
> dedicated feature might allow me to just enclose the whole portion into
> braces.
> - 3) If I ever wanted to turn my modified .ly file back to one that's
> more appropriate for printing, I would just remove the dedicated command
> and the braces and leave the music fragment unchanged.
> - 4) If I have good-quality samples available for playing back the MIDI
> file, then the MIDI file can serve as a handy tool not just for spotting
> errors but also for making serious recordings. For a blind person, this
> is an important point because currently there doesn't seem to be any
> other software that would A) run under Windows, B) use some syntax whose
> verbosity is minimal, and C) make meaningful MIDI files. I mean, well,
> there's Scala, but Scala's "sequence" format is much much more verbose
> than what LilyPond offers. And what's more, I think I've read somewhere
> in the documentation that LilyPond even allows me to include a series of
> controller messages in my MIDI file, which can definitely make the
> resulting performance sound a lot better still.
>
> Thank you in advance for your answers or comments.
>
> Petr
>
>
> --
> Tento e-mail byl zkontrolován na viry programem AVG.
> http://www.avg.cz



My initial thoughts on this is that, like many other things in lilypond, it
is generally necessary to have parallel PDF vs MIDI content, when they
diverge.

The most straightforward approach is to use tags, and to make sure that
everywhere you have content that diverges, you have tagged both a PDF and a
MIDI version of the content.

The PDF score keeps the PDF tags, and the MIDI score keeps the MIDI tags.

Note that the tag names "MIDI" and "PDF" are just arbitrary words,
there is no intrinsic significance to them.

This approach becomes handy when coding other differences for MIDI,
such as fermatas, breaths, rit/accel, trills.

Here is an example from some time ago that demos how to use PDF vs MIDI
tags to deal with non-trivial repeats.  Not the same use case, but you
would still use the \tag and \keepWithTag commands.

\version "2.19.81"

body = { c'4 c' c' c' }
voltaI = { d'4 d' d' d' }
voltaII = { e'4 e' e' e' }
voltaIII = { g'4 g' g' g' }

music = {
  \repeat volta 5 \body
  \set Score.repeatCommands = #'((volta "1."))
  \voltaI
  \tag #'MIDI { \body }

  \set Score.repeatCommands = #'((volta #f) (volta "2. 3. 4.") end-repeat)
  \voltaII
  \tag #'MIDI {
  \body \voltaII
  \body \voltaII
  \body }

  \set Score.repeatCommands = #'((volta #f) (volta "5.") end-repeat)
  \voltaIII
  \set Score.repeatCommands = #'((volta #f))
  \bar "|."
}

\score {
  \keepWithTag #'PDF \music
  \layout { }
}

\score {
  \keepWithTag #'MIDI \music
  \midi { }
}




Next, the question is how to produce the tags.

If the transformation of an chord that is marked with an arpeggio into a
performed arpeggio can be done in an automat

Re: Add Code of Conduct

[Flaming Hakama by Elaine]

Regarding the CoC.

If there is no enforcement, then it is not clear what is the point.

In the abstract, such a document could help to set expectations of
behavior, including clarifying types of behavior that is considered
unacceptable.  Such that everyone/anyone in the community would be able to
have something to point to to say, "see this type of behavior is considered
unacceptable".

However, even with a clear CoC, any accusations of violation could be
disputed.  Reasonable people can disagree on many things, especially human
feelings, actions, and intentions.  Without an offiical enforcement
mechanism, we only really have peer pressure.  Which is exactly what we
have now.  And I don't think any of us need a CoC to identify uncivil
behavior.


The main issues with the original enforcement proposal is that it delegates
authority to the people most likely to have a conflict of interest:  the
core contributors.

If we want such a committee to be effective, it should be populated by
people who have fewer conflict of interest.  Ideally, it would include
people who primarily have good standing among the community with track
records of being helpful and diplomatic--coding chops should not be the
main criteria.  Likewise, I think we should consider recruiting at least
one person from outside the community who has experience with such things
(mediators, facilitiators, open source mentors, diversity trainers).  This
should be clear by considering the one suggested use case (sexual
harassment), since we would want a committee that is able to understand and
handle such complaints, and to which community members will feel
comfortable bringing forward such complaints.  That is not an easy thing to
construct entirely in-house.

Any such proposal should also make it clear how this committee gets
elected, have some mechanisms for limiting terms, and how to handle appeals.

In my opinion, in the abstract a CoC with enforcement is useful, but only
once the community is large enough, and if the enforcement mechanism is
transparent, democratic, and constructed to actually handle well the task
it is charged with.

I don't think either the lilypond community nor this specific proposal
comes anywhere close to this.



There are two things that have been said in this discussion so far that I
would like to point out as being un-collaborative and in violation of any
CoC worth its salt:

1) "Adopt this CoC or I will leave the community"  Such threats amount to a
my-way-or-the-highway attitude, which is an attempt to enforce veto power
in what is supposed to be a collaborative / concensus / democratic
approach.  Also difficult to disentangle the degree to which this is
intentionally or unintentionally an unprofessional attempt to elicit
praise, with the expected reactions of "oh no, don't leave, you're too
valuable".  To me, this is toxic behavior and I would welcome their
self-removal from the community if this is their idea of how to conduct
themselves in an exemplary manner.

2) Being disingenuous regarding the point of the CoC.  While it may be a
bit overboard for DK to assume that removing him is the sole point of the
proposal, it is equally disingenuous for the proposers of the CoC to
suggest that any such consequences would be unintended, since that is the
*only* actionalble part of the proposal, and DK is the most obvious target
for such concerns.  What has become clear to me is that there is a
disharmony between the original BDFL and the incumbent BDFL.  This specific
proposal for a CoC seems to me to be an attempt to provide the *appearance*
of some kind of consensus-based or otherwise democratic process, in an
effort to reinstate the original BDFL and dethrone the incumbent BDFL, when
in fact there is nothing consensus-based or democratic about the proposal
at all.  So, it has a taste of insencerity and disguised motives, which is
exactly the opposite of what a CoC should be engendering.

For both sides of this kerfuffle, I'd offer the following reality check:

* The current process relies too heavily on one contributor, and any
improvements to the process will inherently invovle untangling the many
hats being worn by the current BDFL, such that others can wear them--and
probably also reconstituting the hat wardrobe.

* Those wanting more input and responsibility should be frank about their
aims, and not disguise them behind a lofty CoC proposal.  They should
recognize that such a proposal is, in part, difficult to distinguish from a
personal attack, since it does essentially target one individual, even if
that is not the intention and eventual scope of the proposal when applied
to a future 'pond that does operate among a larger number of contributors.

* Those who currently have oversized roles should be willing to help
transform the workflow and workload such that collaboration is expanded,
such that they can focus on their areas of genius.  Also, recognize that,
while the desire to disentangle the workflows of the in

Re: Context paths (and the Edition Engraver)

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: David Kastrup 
> To: Dan Eble 
> Cc: lilypond-devel@gnu.org
> Bcc:
> Date: Tue, 21 Jan 2020 22:51:29 +0100
> Subject: Re: Context paths (and the Edition Engraver)
> Dan Eble  writes:
>
> > On Jan 21, 2020, at 14:37, David Kastrup  wrote:
> >>
> >> StaffGroup = "organ" . Staff = "upper" . Voice . SubVoice = 2
> >
> > OK.  It would be an understandable growth on the current face of
> LilyPond. :)
> >
> > Questions follow, but I'm not asking you to spend time investigating.
> >
> > Do you think we could achieve making the quotes optional for some
> > simple IDs, and making the whitespace optional?
> >
> > StaffGroup=organ.Staff=upper.Voice.SubVoice=2
>
> It would all be optional (except in \lyricsmode or \markup) but I am
> skeptical that it would make for a great convention.
>
> > In a situation where the user didn't care to constrain the context
> > types, do you think could they be omitted, or would we have to invent
> > a placeholder?
> >
> > =organ.=upper..=2
> > X=organ.X=upper.X.X=2
>
> I don't think that this would be a reasonable syntax.
>

Just chiming in to agree that this syntax is not very clear.
At least, I find it confusing to see what looks like multiple assignments
(use of =) on the same line.
The = in this case is not being used in this case to define something, but
to identify something that presumably already exists.


Is there any hope of having syntax like one of the following?

StaffGroup("organ").Staff("upper").Voice.SubVoice("2")
StaffGroup["organ"].Staff["upper"].Voice.SubVoice["2"]


The square braces make it look like you're looking up an element in an
(associative) array, which is kind of what we're doing, if I understand
correctly.  That is, if StaffGroup (in a Context context) refers to all
StaffGroup contexts, and then we're narrowing this down by identifying one
by name, in this example, the one called "organ".

The parenthesis syntax makes it look more like a function call.   (So, it
might be clearer if it were called getStaffGroup)   However, the
parenthesis/function-call syntax makes it easier to identify multiple staff
groups by name, if it can take an array of names.  So, to identify all
voice contexts in all lower staves of three different staff groups:

StaffGroup("organ", "piano", "celeste").Staff("lower").Voice


I realize that the EE use case is more about identifying a very specific
context, in order to apply specific edits.

But, in general, from a context point of view, the general use case
involves identifying all or a subset of contexts.



Also, to comment on another previously suggested model for syntax,
the CSS selector approach is not a good one to model,
since its use of spaces and dots is not consistent with how they are used
here, to indicate sub-properties.

Which is to say, in CSS, dots between identifiers (with no spaces)
refer to multiple properties  of the same element,
and spaces are used to identify descendants.

For example:

confusion

.bar => matches both the outer DIV and inner SPAN
#foo .bar => matches the inner SPAN
#foo.bar => matches the outer DIV



Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Chord names clean-up; no more Banter, exceptionsPartial or \powerChords

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: d...@gnu.org
> To: v.villen...@gmail.com
> Cc: lilypond-devel@gnu.org, re...@codereview-hr.appspotmail.com
> Date: Tue, 07 Jan 2020 14:06:51 -0800
> Subject: Re: Chord names clean-up; no more Banter, exceptionsPartial or
> \powerChords. (issue 363880043 by v.villen...@gmail.com)
>
> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py
> File python/convertrules.py (right):
>
>
> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py#newcode3980
> python/convertrules.py:3980
> :
> if re.search
> (r"#[banter|jazz]-chord-names", str):
> I have no idea what this regexp is actually supposed to be/do.  But it
> needs to get fixed.  Any idea what this should be instead?
>
> As it is, it matches a # followed by one of the letters abejntrz| and
> then -chord-names .  This is very likely not what is intended here.
>
> https://codereview.appspot.com/363880043/
>

My guess as to the intention is that it should match either
"#banter-chord-names" or "#jazz-chord-names".

Although, it is unclear why those strings are important.

Seems like they just mistakenly used square brackets instead of parenthesis
for grouping in the regular expression.


HTH,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: A snippet for editing curves using the mouse and reporting changes to the .ly file

[Flaming Hakama by Elaine]

-- Forwarded message --
> From: Urs Liska 
> To: lilypond-devel@gnu.org
> Date: Mon, 16 Dec 2019 10:18:36 +0100
> Subject: Re: A snippet for editing curves using the mouse and reporting
> changes to the .ly file
> Hi Paolo,
>
> I have followed the discussion but didn't have the time to actually test
> your code until today.
>
> First of all let me state that this is really great, and when I will
> raise some issue these are in no way meant as critique. I really want to
> see this integrated in the toolbox in one way or another, but there are
> a few minor and major questions that should be answered before.
>
> Regarding integration in Frescobaldi I agree that it's appropriate to
> create an independent version of the code and then have Frescobaldi deal
> with it.
>
> Generally I'd say this functionality should be integrated in LilyPond
> itself, and I hope we'll find a version that satisfies all potential
> questions.
> What Werner Lemberg hinted at when mentioning my name was that we could
> alternatively or additionally include the snippet in the openLilyLib
> package oll-misc (https://github.com/openlilylib/oll-misc/). While I
> prefer having it in LilyPond proper you should understand that any
> addition we do now will most surely *not* be included in the next stable
> release 2.20 but will only be available through the next development
> version. Judging from recent history version 2.22 may be quite some way
> in the future.
> For me this won't be an issue since I'm always using the development
> version, but if we want this functionality to be generally available we
> might better include it in LilyPond itself and then *additionally* to
> openLilyLib.
>
> Now to the functionality itself. Again, the length of the list of
> comments should not diminish my excitement about your code!
>
>   * For integration in LilyPond the functionality should be wrapped into
> a single file that can be included. Including the file should
> automatically activate the functionality.
> Maybe there should be a second includable file that does *not*
> automatically activate the functionality but provides a command to
> selectively switch it on and off or apply it to only one curve.
> There may be people who don't want the whole score to be polluted
> with the control points but only see the slur they want to edit.
>   * The behavior of the script in the SVG file is too intrusive IMHO.
>   o forcing the interface with the pop-up prevents any external
> contexts (like e.g. Frescobaldi) from accessing the
> functionality in the way they need to. There should be some way
> to interact with the data in a different way. Also, it should be
> possible to get to the raw data instead of the formatted \shape
> command string.
>   o It seems the function prevents point-and-click from working. I
> assume this is related to your decision to “hijack” the context
> menu functionality.
>   o If that's correct (or even if not) I think the context menu
> should not be blocked in this way. Probably it's a better
> approach to *add* an entry. Maybe this is also a usable hook for
> external programs to integrate your function.
>   * There is one flaw in the behaviour: When you include the generated
> \shape command in the score and recompile the modified slur is drawn
> correctly (which is totally great!). However, when you now modify
> that slur again (which is a very reasonable expectation) the \shape
> command is now calculated relatively to the already-applied \shape,
> so *now* the recompilation will produce a totally unexpected result.
> I see two possible solutions:
>   o Somehow determine if a \shape has already been applied to the
> slur and consider the values when generating a new \shape. I
> have no idea whether this is possible.
>   o Don't use  \shape at all but finally integrate \shapeII into
> LilyPond and use it for the graphical tweaking. With \shapeII it
> is possible to much more robustly shape a slur than with \shape,
> and it is somewhat more absolute. I've attached the
> documentation PDF, and you can find the code at
>
> https://github.com/openlilylib/snippets/tree/master/notation-snippets/shaping-bezier-curves/shapeII
> (don't let the warnings scare you when compiling the example file).
> There would be some figuring out how to best apply the function,
> starting from the approach of polar coordinates, I'd say.
> To make it work, the function would have to do some more
> calculations that simply measuring the offsets, but I'm
> convinced it would be more than worth the effort.
>
> Best
> Urs
>
> Am 16.12.19 um 03:42 schrieb Paolo Prete:
> > Hello,
> >
> > the snippet attached to this mail allows the tuning with the mouse of the
> > curves generated by Lilypond s

Re: Issue 5621: Improve rehearsal mark position at beginning of staff

[Flaming Hakama by Elaine]

From: nine.fierce.ball...@gmail.com
> To: lemzw...@googlemail.com
> Cc: lilypond-devel@gnu.org, re...@codereview-hr.appspotmail.com
> Bcc:
> Date: Mon, 16 Dec 2019 08:51:59 -0800
> Subject: Re: Issue 5621: Improve rehearsal mark position at beginning of
> staff (issue 547340043 by nine.fierce.ball...@gmail.com)
> On 2019/12/15 06:29:59, lemzwerg wrote:
> > Well, the cis–trans pairing is IMHO only understandable for people who
> have a
> > Latin background (or come from Austria, since it was divided into
> > »Cisleithanien« and »Transleithanien« in the K. und K. era)...  As
> nice as it
> > is, I suggest that you find names that are easier to comprehend for
> other
> > people.
>
> I'd like to add named constants to the code.  If CIS and TRANS are not
> well
> liked, how about SAME_WAY and OPPOSITE_WAY?
>
> I'd also like to hear more opinions before changing this.  A few years
> ago,
> I wouldn't have chosen to use "cis," but my perception is that it is no
> longer
> obscure in North American English.
>
>
> https://codereview.appspot.com/547340043/
>

In recent years, "cis" and "trans" have been getting more exposure in the
US, largely through the transgender movement.

Which is to say, transgendered people are referred to as "trans", and
people who are not transgender (their chosen gender matches their assigned
gender) are referred to as cisgender, or "cis".

Up until the trans/cis-gender usage, these terms to my knowledge only
appear in the context of organic chemistry.

I suspect that most lilypond users from the US would not immediately know
what cis/trans mean in this context, so I agree with the suggestion that
SAME_* and OPPOSITE_* would be clearer.

OTHO, I'm not sure that _WAY is very descriptive.  If we are discussing
alignments (can't quite tell, since I didn't see the CIS_ or TRANS_ in the
code review), maybe SAME_ALIGNMENT and OPPOSITE_ALIGNMENT would be clearer.


HTH,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Charles Winston's chord-semantics GSOC work

[Flaming Hakama by Elaine]

On Tue, Apr 9, 2019 at 2:11 PM Dan Eble  wrote:

> On Apr 9, 2019, at 10:43, Carl Sorensen  wrote:
> > majorSevenSymbol, but since it can be set, in can be unset.  And if it
> is unset, we should not produce nothing, because then c:7+ will display as
> C7, which is the same as c:7.  I don't think the display needs to be
> sensible, but it needs to be something different from C7.
> >
> > I value your input and I'd like to do something that is recognizable as
> insane in response to insane input.
>
> Insanity sounds like a job for emoji!
>
> But seriously, it would be unreasonable to demand that you do more in this
> patch than match the legacy behavior in this case.  If it can be improved
> at all, it can be improved separately.
>
> Regards,
> —
> Dan
>

Sorry if I didn't understand this context well enough.

So, because we can set the majorSevenSymbol, therefore we must be able to
unset it?
I'm not sure I follow that logic, unless that comes part and parcel with
canonical set/unset behavior.

However, if I understand what is being proposed, if the user "unsets" it,
we apparently are going to require that it be set to something anyway ("#")?
If so, that doesn't seem like we're really "unsetting" it, but rather going
with a default.

In which case, I'm not sure why a bizarre default is better than a
reasonable default.

Also, if the user does choose to unset it (or set it to an empty string),
then aren't they saying that they want C7 and Cmaj7 to both say "C7"?
While I agree that that is a bizarre request, it seems like that is what
they would want, given that that's what they specified.

Where does the requirement come from that dominant 7 and major 7 chords
need to have different chord symbols?  Shouldn't the regtest just validate
that each chord flavor's symbol match what it is asked to show, regardless
of whether they are the same or different from each other?


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Charles Winston's chord-semantics GSOC work

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: Carl Sorensen 
> To: "carl.d.soren...@gmail.com" , "
> v.villen...@gmail.com" , Carl Sorensen <
> c_soren...@byu.edu>, "pkxgnugi...@runbox.com" , "
> thomasmorle...@gmail.com" , "
> lilypond-devel@gnu.org" , "
> re...@codereview-hr.appspotmail.com" 
> Date: Tue, 9 Apr 2019 00:29:29 +
> Subject: Re: Charles Winston's chord-semantics GSOC work (issue 568650043
> by carl.d.soren...@gmail.com)
>
>
> On 4/8/19, 1:59 PM, "thomasmorle...@gmail.com" 
> wrote:
>
> On 2019/04/08 18:47:13, lilypond-pkx wrote:
> > Are we sure all the reg tests are OK (see tracker for download link)?
>
> > For example
>
> > regression/chord-name-major7.ly
>
> > This looks completely broken with this patch
>
> Interesting question.  The semantics that Charles coded says that c:maj7
> is the way to indicate the C major 7 semantics.  This regtest had c:7+,
> which gives the same pitches as c:maj7, but has a different semantic
> spelling.  In my opinion, c:7+ should probably be named C#7, not C
> triangle.  Of course, the code is broken because it loses the alteration on
> the extension (but not the addition).
>

I would strongly disagree that a Cmaj7 chord should be named C#7.

From a chord symbol standpoint, no one uses #7 to indicate a maj7 chord.
The vast majority of chord symbol naming conventions use either the
triangle, M, Maj, or maj to indicate a major 7th chord.

So, I'd suggest we pick one of those.  I'm partial to the triangle, but
that's probably not the most common.

What I would suggest is that, whichever one is chosen, it is done so in
accordance with the symbols for minor, diminished and augmented.
So, for major / minor / half-diminished / diminished / augmented use one of
these sets:

triangle / minus / null / circle / plus
maj / min / min7b5 / dim / aug

I understand that in the lily syntax, using c:7+ makes mathematical sense,
since following chord naming convention, the "7" refers to dominant 7, or
the b7, and we are interested in saying that it is one semitone higher than
that, and this is a reasonable shorthand.

But we should not inflict this shorthand on the printed chord symbols, nor
on the semantic representation of them.

Musically speaking, we are not lowering then raising the 7th--we're simply
using the actual 7th degree, as is.
Semantically, it is moreso "natural 7" than "#7".



Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 64-bit version of Lilypond?

[Flaming Hakama by Elaine]

On Sun, Mar 10, 2019 at 1:50 AM Jacques Menu  wrote:

> Hello Elaine,
>
> I use Frescobaldi 2.20.0 quite often on my Mac, and it escaped me that
> 3.x.y is available on other platforms…
>
> I can contribute building it and LilyPond on Mac OS X if needed.
>
> JM
>

I would certainly appreciate being able to try the latest version of
Frescobaldi on mac, thanks!

For the purposes of this thread, I also wanted to ask, the reason
Frescobaldi can provide a mac binary but not Lilypond is that Frescobaldi
is all python, but Lilypond also requires C?  Or is it because the Lilypond
build is done through GUB?


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 64-bit version of Lilypond?

[Flaming Hakama by Elaine]

On Fri, Mar 8, 2019 at 4:34 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi,
>
> > In fact, one of the reasons I have not tried Frescobaldi is that you need
> > to use a package manager to install it, and download the developer tools
> > (XCode).
>
> You do? I just download the binary and run it…
>
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info



According to the Frescobaldi download page
http://frescobaldi.org/download.html

For Mac OS X DMG disk images are provided, containing an application bundle
that you can drag and drop in your Applications folder. 64 bit and 32 bit
versions are provided (the "Frescobaldi-2.x.x-x86_64.dmg" and
"Frescobaldi-2.x.x-i386.dmg" files, respectively).

I see from the linked repo
https://github.com/frescobaldi/frescobaldi/releases
that this support is only for 2.x, and while 3.0 has been out for 2 years,
there is no dmg app bundle for 3.0.

Are there plans for a mac version of 3.0?  Is it just lack of popularity,
or is there a reason why support has stopped?


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 64-bit version of Lilypond?

[Flaming Hakama by Elaine]

On Fri, Mar 8, 2019 at 4:40 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi all,
>
> On Mar 8, 2019, at 5:46 PM, Flaming Hakama by Elaine <
> ela...@flaminghakama.com> wrote:
> > However, to be clear, if you are basing this suggestion on being able to
> > install it via Fescobaldi, I'll reiterate the point that it takes way
> more
> > time and hassle to set that up on a mac, since you have to register with
> > Apple, then download and install XCode, then install a package manager
> and
> > install Frescobaldi.  Then use that to install Lilypond.
>
> I’m confused… Why am I able to run Frescobaldi and Lilypond without having
> ever done any of that? I download the binaries from the two websites and
> I’m off and running.
>
> Thanks for any clarification you can give!
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>
>
Hmmm, maybe I just didn't know how to do it the easy way.
Lilypond has always been easy, it's just Frescobaldi that I recall needing
those steps.

Perhaps I should try it again and report back...


Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 64-bit version of Lilypond?

[Flaming Hakama by Elaine]

>
> -- Forwarded message --
> From: David Kastrup 
> To: Flaming Hakama by Elaine 
> Cc: lilypond-devel 
> Bcc:
> Date: Fri, 08 Mar 2019 22:16:37 +0100
> Subject: Re: 64-bit version of Lilypond?
> Flaming Hakama by Elaine  writes:
>
> > So, I think the long-term value of Lilypad to the potential user base
> > (on mac or even other platforms) is close to zero.  In the short term,
> > the main downside would be specifically regarding recruiting new users
> > by providing an immediate "working" install.
>
> I've seen reviews of LilyPond lambasting it because clicking the
> application does nothing.
>
> LilyPad helps against that but I am not sure whether we'll entertain
> people's attention span long enough to actually become a user of
> LilyPond when this was a roadblock.


My hot take:  if this is a roadblock, you're probably not going to warm up
to Lilypond.



> If I remember correctly,
> Frescobaldi can download and install official LilyPond versions.  If
> that's also the case in MacOSX, that would be a strong reason to try
> providing a no-GUI LilyPond installation for Darwin.
>
> --
> David Kastrup
>

I agree that a no-GUI installation for Darwin would be great, and I suspect
it would be enough for the vast majority mac users of Lilypond.

However, to be clear, if you are basing this suggestion on being able to
install it via Fescobaldi, I'll reiterate the point that it takes way more
time and hassle to set that up on a mac, since you have to register with
Apple, then download and install XCode, then install a package manager and
install Frescobaldi.  Then use that to install Lilypond.

This is much more work than setting up the command line environment and
using the native simpletext editor, using your regular editor/IDE.

However, I would guess that shepherding new users to use Fescobaldi would
end up getting more of them to stick since I gather it is helpful or even
essential for many (if not most) Lilypond users.  But this is not a path of
convenience on mac.  So, I agree with the suggestion, if not the original
motivation.


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 64-bit version of Lilypond?

[Flaming Hakama by Elaine]

-- Forwarded message --
> From: Kieren MacMillan 
> To: Karlin High 
> Cc: David Kastrup , lilypond-devel ,
> "Hans Åberg" 
> Date: Fri, 8 Mar 2019 09:50:19 -0500
> Subject: Re: 64-bit version of Lilypond?
> Hi Karlin,
>
> > Would MacPorts installation be adequate for LilyPond? Hans Åberg reports
> success with this. Or is it important to have something available from
> lilypond.org?
>
> Let’s use [totally opinion-based] numbers for argument’s sake:
>
> people who would download and keep using a version from lilypond.org that
> didn’t require a second [editor] download: 100
>
> people who would download and keep using a version from lilypond.org that
> required a second [editor] download: 75
>
> people who would download and keep using a version using MacPorts: 30
>
> That is to say, I would guess we turn off at least half of our potential
> [Mac-based] user base by not having something available from lilypond.org.
> Of course, I would still use it (I have MacPorts installed for maxima and a
> number of other things), but I’m not the average Mac user.
>
> Thoughts?
>
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>


Context of my opinion:  I use Lilypond on a mac.  I do not use
Frescobaldi.  I use Sublime Text as my editor, but when I stared I used
emacs.

I have never used Lilypad except as part of the initial "hello, Lily"
process to validate whether the install worked.

I would image that anyone doing real work in Lilypond, who does not use
Frescobaldi (or some other front end like Denomo?) would use their typical
go-to text editor/IDE, and not Lilypad.

In fact, I wonder if anyone on this list still uses Lilypad for any reason
other than to validate installs?  (Unless I am mistaken and that Lilypad is
commonly used in conjunction with Frescobaldi.)

So, I think the long-term value of Lilypad to the potential user base (on
mac or even other platforms) is close to zero.  In the short term, the main
downside would be specifically regarding recruiting new users by providing
an immediate "working" install.

Since this short-term goal is arguably still very important, I would be
willing to work on instructions or development of a command-line howto or
script to replace the Lilypad-based "hello, Lily".

Also, regarding your thought experiment, since macs ship with an editor
called simpletext, so there would be 0 cases where someone would need to
download additional software to start using Lilypond if it required another
editor.

I do agree that requiring using macports would significantly curtail that
potential user base.

In fact, one of the reasons I have not tried Frescobaldi is that you need
to use a package manager to install it, and download the developer tools
(XCode).  While this may be ok for my development machines, on my macbook
air it isn't really as viable an option (due to disc space, as I also need
to run Logic and Cubase, etc.)


Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

addressing ties in a chord

[Flaming Hakama by Elaine]

>
>
>
For kicks and giggles, I attempted to reproduce an example of tie
formatting
that appeared on the fb music engraving tips page.

The favored rendering was from Dorico:
https://www.facebook.com/photo.php?fbid=10160558409140005&set=pcb.1940968102868739&type=3&theater&ifg=1

And someone else posted a default lilypond mwe version:
https://www.facebook.com/photo.php?fbid=10160686606405430&set=p.10160686606405430&type=3&theater&ifg=1

\version "2.19.54"
\score {
\new Staff {
\key c \major
\numericTimeSignature \time 2/4
8
8 -> ~ (
8
8 )
}
}

I thought I'd try my hand at getting a lilypond version that matched.

The main difference being the placement of the lower tie,
which appears in the 3rd, rather than the 4th staff space in lilypond.

The other details, like the length and thickness are easily enough dealt
with.

I could get the lower tie to look pretty close using \shape ... Tie.

But since this is a chord, that only affects the bottom tie.

Two questions: how does one address the upper tie?
Second question:  is it possible to affect such things globally,
rather than on a per-shape basis?  Or is this where we go into \shapeII
territory?

\score {
\new Staff {
\key c \major
\numericTimeSignature \time 2/4
8
\shape #'((0.4 . 0.8) (0.2 . 0.9) (0.3 . 0.9) (0.1 . 0.8)) Tie
8 -> ~ (
8
8 )
}
\layout {
\context {
\Staff
\override Tie.minimum-length = 3.5
\override Tie #'thickness = #1.9
}
}
}

%{
I tried banging on these other ususal suspects,
but none of them had an effect on which staff space the tie was placed:

\layout {
\context {
\Staff
\override Tie.height-limit = 0.2
\override Tie.ratio = 0.2
\override Tie.details.free-head-distance = 0.5
}
}
%}



Thanks,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Rational

[Flaming Hakama by Elaine]

> From: metachromatic 
> Subject: Re: Rational
>



> ===
>
> \version "2.18.2"
>
> \score {
>
> <<
>
> \new Staff {
> \clef "treble"
> \override TupletNumber.text = #tuplet-number::calc-fraction-text
> \override Staff.TimeSignature #'stencil = ##f
> \omit Score.BarLine
> \relative c''
> {
> \tuplet 53/37{r4}
> \tuplet 43/29{c8}
> r8
> \tuplet 3/2{d8}
> \tuplet 19/13 {e8[ d8 c8]}
> \tuplet 11/7{b4.}
> \tuplet 17/13{g8}
> r8
> \tuplet 61/47{r4}
> %\tuplet 31/23{a8}
> %\tuplet 89/79 {b4}
> %\tuplet 97/41{r4}
>
> }
>
> }
> >>
>
> }
>


>So let's ask ourselves, as a practical matter, what kind of
> accuracy does Lilypond _really_ need internally?
>


>   So what we'd like is for no note in a Lilypond score to be off by
> more than 1/31,250 of a second in (oh, let's say) 100 page of score.
> That means we need a timing accuracy of 1/100*(1/31250) second =
> 1/(3.125) microseconds. That works out to an accuracy of (ballpark) 3
> parts in 10 million.
>


If you think you (or any human) can audibly distinguish among these
durations, you are even more delusional than you are lacking in social
graces.

>From a CS perspective, this might be an interesting theoretical problem.

But it lies entirely outside the realm of music.


Sincerely,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 5272: Add \depart

[Flaming Hakama by Elaine]

-- Forwarded message --
From: Carl Sorensen 
To: Kieren MacMillan 
Cc: "Torsten Hämmerle" , "lilypond-devel@gnu.org"

Bcc:
Date: Wed, 7 Feb 2018 16:02:50 +
Subject: Re: Issue 5272: Add \depart  (issue 337520043 by
nine.fierce.ball...@gmail.com)


On 2/7/18, 8:55 AM, "Kieren MacMillan" 
wrote:

Hi Carl,

Of all suggestions so far, I most like your flow/Flow the most.

> If we want to capture semantics properly, I believe we need to
recognize that there are three different kinds of marks:
> 1) "jump-from" marks (D.S. al ..., D.C. al ..., To Coda)
> 2) "jump-to" marks (Segno, beginning of piece, coda)
> 3) "stop playing" marks (Fine, end of piece)

+1

> \depart
> \join
> \fine

Since the first two are English, is there an English term (e.g., \end,
\stop) that could be found for the third?

\end, \stop, \terminate, \finish

Or maybe we try to capture that it's a mark for the ending, rather than the
end of the piece

\markEnd

Or maybe find an Italian term for all three?

For me, it's not the Italian part, it's the "musical" part, that is, what
do I see when I read the music.  The fact that it is Italian is secondary.
That being said, the \fine command is a bit weird, because it could be
confused with the English word "fine" meaning "OK" (or perhaps even
"punitive charge").  So I think it is better to follow your suggestion and
use all English words, and I think my preferred choice is \end.

Thanks,

Carl


In rehearsals, at least in the US, going over these markings is called
going over the roadmap.

The 'taking a trip' metaphor is also built into 'depart'

It also seems like the commands should have some consistency, so whatever
is chosen, they should share a root.

Also, the more typical English to match 'depart' might be 'resume'.

So, I'd offer the suggestion:

\roadmapDepart
\roadmapResume

\roadmapEnd
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PDF landscape issue

[Flaming Hakama by Elaine]

> > -- Forwarded message --
> > From: Simon Albrecht 
> > To: Francisco Vila , Dev 
> > Cc:
> > Bcc:
> > Date: Sat, 1 Jul 2017 20:17:53 +0200
> > Subject: Re: PDF landscape issue
> > On 01.07.2017 18:44, Francisco Vila wrote:
> >
> >> Hello,
> >>
> >> I'd like to know if something has changed recently about the way
> >> LilyPond creates landscape documents.
> >>
> >> In 2.19.58, a landscape document looks right in Evince and in
> >> Frescobaldi music PDF preview. In 2.19.62, the same document is rotated
> >> 90º counter-clockwise, which is not a problem for Evince as I can rotate
> >> it on a keystroke, but there is no such mechanism in Frescobaldi.
> >>
> >> What is really strange is that the properties dialog in Evince says the
> >> document is portrait, not lansdcape.
> >>
> >
> > This is an intentional change. If I don’t confuse it right now, the
> > #(set-paper-size "foo" 'landscape) syntax didn’t actually change paper
> > dimensions, but set page rotation. Instead, it’s better to use
> > #(set-paper-size "foolandscape") which will reliably set paper
> dimensions.
> >
> > Best, Simon
> >
>
>
> I was just going to write in about this since I just upgraded from 2.19.15
> to 2.19.63 and this is breaking my existing scores.
>
> This command:
> #(set-default-paper-size "legal" 'landscape)
>
> Used to set the paper size to legal, lay it out in landscape, and rotate
> it.
> Now, it sets the paper size to legal and lays it out in landscape, but does
> not rotate it.
>
> So, what is the command to rotate the page?
>


Nice to see that this is explained in the docs:

http://lilypond.org/doc/v2.19/Documentation/notation/paper-size-and-automatic-scaling#setting-the-paper-size

Swapping the paper dimensions without having the print rotated ... can be
achieved by appending ‘landscape’ to the name of the paper size itself:

#(set-default-paper-size "a6landscape")



Thanks,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: PDF landscape issue

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: Simon Albrecht 
> To: Francisco Vila , Dev 
> Cc:
> Bcc:
> Date: Sat, 1 Jul 2017 20:17:53 +0200
> Subject: Re: PDF landscape issue
> On 01.07.2017 18:44, Francisco Vila wrote:
>
>> Hello,
>>
>> I'd like to know if something has changed recently about the way
>> LilyPond creates landscape documents.
>>
>> In 2.19.58, a landscape document looks right in Evince and in
>> Frescobaldi music PDF preview. In 2.19.62, the same document is rotated
>> 90º counter-clockwise, which is not a problem for Evince as I can rotate
>> it on a keystroke, but there is no such mechanism in Frescobaldi.
>>
>> What is really strange is that the properties dialog in Evince says the
>> document is portrait, not lansdcape.
>>
>
> This is an intentional change. If I don’t confuse it right now, the
> #(set-paper-size "foo" 'landscape) syntax didn’t actually change paper
> dimensions, but set page rotation. Instead, it’s better to use
> #(set-paper-size "foolandscape") which will reliably set paper dimensions.
>
> Best, Simon
>


I was just going to write in about this since I just upgraded from 2.19.15
to 2.19.63 and this is breaking my existing scores.

This command:
#(set-default-paper-size "legal" 'landscape)

Used to set the paper size to legal, lay it out in landscape, and rotate it.
Now, it sets the paper size to legal and lays it out in landscape, but does
not rotate it.

So, what is the command to rotate the page?


\version "2.19.63"

#(set-default-paper-size "legal")
\book {
\bookOutputSuffix "legal-portrait"
\relative c' {
\mark \markup { "Letter portrait" }
c1
}
}

#(set-default-paper-size "legal" 'landscape)
\book {
\bookOutputSuffix "legal-landscape"
\relative c' {
\mark \markup { "Letter landscape" }
c1
}
}



Thanks,

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


paper-sizes-legal-portrait.pdf
Description: Adobe PDF document


paper-sizes-legal-landscape.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

midi2ly on mac: midi.so wrong architecture

[Flaming Hakama by Elaine]

> I am not top posting

I am reporting a problem from the facebook group,
someone trying to use midi2ly on mac.

It also failed for me on 3 different macs.

So, I entered it on lilytestissues as:
#5151 midi2ly on mac: midi.so wrong architecture



Their report was:

Hi! When a try a midi2ly, I get this:
File "/Applications/LilyPond.app/Contents/Resources/bin/midi2ly", line 54,
in 
import midi
ImportError:
dlopen(/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so,
2): no suitable image found. Did find:
/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so:
mach-o, but wrong architecture
/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so:
mach-o, but wrong architecture
Any idea of the problem?
Thanks!



My initial tests resulted in a similar error about wrong architecture on
one (OSX 10.11.6).   (The other one resulted in an error "RuntimeWarning:
Python C API version mismatch for module midi: This Python has API version
1013, module midi has version 1012" (OSX 10.9.5)--that one is likely my
fault due to a failed attempt to build lilypond dependencies.)


Here is an MWE of sorts, a round trip from lilypond to midi, then running
midi2ly on that midi file.  Also, to show the midi file was reasonable, I
imported it into a DAW and bounded it as an mp3.

The error on the mac for this example (OSX 10.11.5) was:
Traceback (most recent call last):
  File "/Applications/LilyPond.app/Contents/Resources/bin/midi2ly", line
54, in 
import midi
ImportError:
dlopen(/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so,
2): no suitable image found.  Did find:

/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so:
mach-o, but wrong architecture



%%% File: fifth-and-back.ly %%%
\version "2.19.15"

#(define output-suffix "output")
\score {
<<
\relative c'' {
\tempo "Allegro con brio" 4=144
\time 2/4 r8 g8\ff [ 8 8 ] | ees2 ~ | 2 |
}
>>
\layout { }
\midi { }
}


command line:
$ lilypond fifth-and-back.ly

fifth-and-back-output.pdf is attached
fifth-and-back-output.midi is attached.
Here is the contents of the midi file when looking in a text editor:

4d54 6864  0006 0001 0002 0180 4d54
726b  0053 00ff 030d 636f 6e74 726f
6c20 7472 6163 6b00 ff01 0963 7265 6174
6f72 3a20 00ff 011e 474e 5520 4c69 6c79
506f 6e64 2032 2e31 392e 3135 2020 2020
2020 2020 2020 00ff 5804 0202 1208 00ff
5103 06ef 9100 ff2f 004d 5472 6b00 
3a00 ff03 055c 6e65 773a 00b0 0764 8140
b007 6400 9043 6581 4090 4300 0090 4365
8140 9043  9043 6581 4090 4300 0090
3f65 8c00 903f  ff2f 00



Now, running midi2ly on the file fifth-and-back-output.midi

$ midi2ly fifth-and-back-output.midi
Traceback (most recent call last):
  File "/Applications/LilyPond.app/Contents/Resources/bin/midi2ly", line
54, in 
import midi
ImportError:
dlopen(/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so,
2): no suitable image found.  Did find:

/Applications/LilyPond.app/Contents/Resources/lib/lilypond/current/python/midi.so:
mach-o, but wrong architecture



Please let me know what else I should do to register the bug properly, as
this is my first attempt.



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


fifth-and-back-output.pdf
Description: Adobe PDF document


fifth-and-back-output.midi
Description: MIDI audio
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond-manuals.css: edit color scheme and some spacing

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: Paul 
> To: lilypond-devel@gnu.org
> Date: Mon, 12 Jun 2017 15:33:59 -0400
> Subject: Re: lilypond-manuals.css: edit color scheme and some spacing
> On 06/12/2017 03:02 PM, Flaming Hakama by Elaine wrote:
>
> CSS is happy with both properties set:
>> width as a percentage and min-width as an absolute value.
>>
>> There is no conflict and they should work together well.
>>
>
> Hi, yes, thanks, but... I glossed over the details.  If you look at the
> css file you'll find that the main content div is positioned so that its
> "left" property is a percentage that corresponds with the sidebar's "right"
> property.  There is actually no "width" property in use and I don't think
> there is a maximum left/right css property to use, thus... what I wrote in
> my previous email.
>
> -Paul
>
>


Oops, correct, I didn't look and didn't expect such a fragile way of
positioning two-column content.

Leaving the layout approach as-is, you can mimic this by using left:
calc(Xpx + Y%), where X is the minimum and Y is somewhat less than it was
previously.



David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypond-manuals.css: edit color scheme and some spacing

[Flaming Hakama by Elaine]

>
> I feel like the table of contents bar at the left is too wide.
>>
>
> I agree; it can get a bit wide especially on wider monitors/windows.
> (Note I have not changed its width in this patch.)  Currently the size is a
> percentage of the window width.  We could make that smaller, but at the
> risk that it gets too narrow on smaller screens/windows.
>
> Another way would involve a different approach in the css, allowing us to
> set a maximum and minimum width to it.  But this would entail more
> work/changes to the css and maybe the html.  (e.g. to use floats, flexbox,
> or grid positioning rather than the current "position: fixed;" approach.)
>
> Or... we could keep the "position: fixed;" approach and set the width to a
> constant amount rather than a percentage.  And/or we could also set media
> query break points to change that constant for different window widths.
> This could even be combined with the percentages so it could effectively
> have a max and min width and be set by percent in between.
>
> In any case this would warrant its own issue.
>
> But I would be fine with it being like this.
>>
>
> Glad to hear, and thanks for the feedback.
>
> -Paul
>

CSS is happy with both properties set:
width as a percentage and min-width as an absolute value.

There is no conflict and they should work together well.


David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [partcombine] honouring Voice context name

[Flaming Hakama by Elaine]

From: David Kastrup 
To: Dan Eble 
Cc: Kieren MacMillan , LilyPond Development
Team 
Bcc:
Date: Thu, 08 Jun 2017 12:03:04 +0200
Subject: Re: [partcombine] honouring Voice context name
Dan Eble  writes:

>> On Jun 7, 2017, at 09:34, Kieren MacMillan
>>  wrote:
>>
>> As a first step, I would offer that we should figure out how (if?)
>> the "one" context can be funnelled seamlessly into the "shared" and
>> "solo" contexts — as I see it, that's the main problem with lyrics
>> getting disconnected (etc.).
>
> If we’re going to ask that kind of question, let’s mention a more
> radical redesign.
>
> The context properties of a part, such as stem direction, need to
> change as the part’s relationship with other parts changes.  The
> current part combiner accomplishes this with a set of voices with
> fixed properties.  It slices the part into pieces and distributes them
> to the voice with the appropriate properties.
>
> Could it not leave the parts where they are (continuous parts in
> exactly one voice context per part) and change their context
> properties instead?

For shared/non-shared stems that would not seem to fit the current
logic.  Mind you: for piano music the rather rigid relation of stems and
slurs and noteheads with voices is a problem.

So changing this seems attractive but it would be a very fundamental
change.

--
David Kastrup


This hints back to the broader topic, of what are the intended uses of the
grand unified partcombine. (And whether or how many of these are captured
in existing tickets.)

While it is ideal to design to handle all cases including the most
complicated, does anyone typically combine piano parts?   What is the
musical use-case for this?

Or, putting it another way, how general is the issue of the "rigid relation
of stems and slurs and noteheads" within parts that people will want to
combine?  My hunch is that they don't much overlap:  if you are adding
rigid structures, what makes you think you should be able to automagically
combine something with it?


HTH,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: help with bash script to translate @ref{} items in translated manuals

[Flaming Hakama by Elaine]

> From: Federico Bruni 
> To: Dev 
> Date: Thu, 20 Apr 2017 08:20:26 +0200
> Subject: help with bash script to translate @ref{} items in translated
> manuals
> Hi all
>
> I recently realized that @ref{} links should be translated otherwise PDF
> links are broken (while HTML files still work fine without @ref{}
> translated).
>
> Yesterday I started to manually translate all the @ref{} instances in the
> italian web, usage and learning manuals.
> Now I've come to the notation manual, which has too many items.
>
> [notation (translation %)]$ grep -oh -e @ref{.*} *.itely | sort -u | wc -l
> 257
> [notation (translation %)]$ grep -oh -e @ref{.*} *.itely | wc -l
> 702
>
> 257 different @ref and a total of 702 @ref
>
> Not all these 257 ref are translated (as translation of this manual is not
> complete yet), but most are.
> So I decided to try a bash script, but I have a problem with a regexp,
> which works fine in the terminal but not in the bash script.
>
> Enter Documentation/it/notation and run this:
>
> #!/bin/bash
> LIST="$(grep -oh -e @ref{.*} *.itely | sort -u)"
> for i in $LIST; do
>echo $i
> #echo -n "Replace" $i "with the translated node: "
> #read NODE
> #if $NODE=""; then exit
> #else
> #sed "s|$i|$NODE|g" *.itely
> #fi
> done
>
> You'll get something like:
>
> @ref{Tuplets}
> @ref{Turkish
> classical
> music}
> @ref{Typesetting
> Gregorian
> chant}
>
>
> The problem is the space character, which is not matched in the bash
> script.
> Why?
>
> Thanks in advance
> Federico
>


Not sure if you'e found a solution in bash yet.
As someone else mentioned, this is pretty straightforward in Perl:


#!/usr/bin/perl

#  Usage: findRefs.pl 
#
#  Find all references, from the files specified on the command line,
#  where references are defined as the contents inside strings like
"@ref{}".
#
#  Print the sorted, unique contents.

my $file ;
my $contents ;
my $match ;
my @matches ;
my %refs ;
my $ref ;
local $/ = undef;
foreach $file ( @ARGV ) {
open my $fh, '<', $file or die "Couldn't open file: $!" ;
$contents = <$fh> ;
close $fh ;
(@matches) = ( $contents =~ /\@ref\{(.*)\}/g ) ;
foreach $match (@matches) {
unless ( defined $refs{$match} ) { $refs{$match} = 'defined' ; }
}
@matches = () ;
}

foreach my $ref (sort keys %refs) {
print $ref . "\n" ;
}



If you save that to a file findRefs.pl and make it executable, you might
invoke it as:

 findRefs.pl Documentation/it/notation



HTH,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Google SoC

[Flaming Hakama by Elaine]

On Thu, Mar 30, 2017 at 5:57 PM,  wrote:

>
> -- Forwarded message --
> From: Carl Sorensen 
> To: "Winston, Charles R." , "
> jefferyshiv...@gmail.com" , "
> lilypond-devel@gnu.org" 
> Cc:
> Bcc:
> Date: Thu, 30 Mar 2017 21:19:27 +
> Subject: Re: Google SoC
> Charles,
>
> On 3/30/17 8:33 AM, "Winston, Charles R." 
> wrote:
> >
> >Anyway, I would love for either of you to pass my draft proposal on to
> >the list. It can be found here:
> >https://docs.google.com/document/d/1TZLsCovyvqBhahS3Vy7LJMRqyp-
> C8ZanHTuCOP
> >PTNAg/edit?usp=sharing
> >
> >
> > C8ZanHTuCO
> >PPTNAg/edit?usp=sharing>
> >Of course, thanks again for all the help. I welcome any and all feedback
> >to improve this, and really hope to get to work on this in the summer!
>
>
> Thanks for sharing your proposal.  It's a great start.
>
> The major challenge I see with the proposal right now is that it's
> somewhat superficial.  It could have been written by someone who just read
> what's available on the mailing list, and doesn't reflect much
> understanding of what goes on under the hood in LilyPond.  I realize that
> getting in to LilyPond is a big undertaking, but I think you could make
> the proposal shine if you had a bit more clarity on how your work will fit
> within the greater aspect of LilyPond.
>
> For example, your midterm goal is to complete the implementation of the
> new representation.  But what does that mean?  When the implementation is
> complete, what will we see?  Does it change any input or output?  If it
> doesn't, how will we know that the implementation is complete?
>
> Note that I'm not arguing that you need to have input or output by the
> midterm deadline.  I'm just asking some questions to try to help you
> clarify what "implementation is complete" means.  The more specific you
> can be, the better we will be able to judge your ability to complete the
> project.
>
> Let me know if you have more questions.
>
> Thanks,
>
> Carl
>


Thanks for you interest in improving Lilypond!

As someone who uses a lot of chord symbols, I am hopeful that this effort
will make Lilypond easier to use.

Below are my thoughts after reading your proposal.

Before I dive into that, I wanted to offer the observation that discussions
about chords in lilypond are often difficult because not everyone is clear
that lilypond uses a three step approach:  1) specify chords using input
syntax, 2) input syntax is transformed into a set of notes, and 3) the
exceptions definitions maps each set of notes to chord name markup.

I suppose most people on this dev list are clear about this, but in case
anyone isn't here's my little rant and attempt at clarification:
http://flaminghakama.com/flaming-lilypond-chords



I suspect that the best way to kick off this project is with a survey of
the things that:
* we currently cannot do
* take a lot of effort to do
* can only be done with bad semantics

Such as:

* Omitting the root on chord symbols for repeated slash chords with
repeated roots (such as A- /G# /G /F#)

* Writing chords with two different alterations of the same extension (such
as C7 b9 #9)

* Writing different chord symbols for the same chord in different
circumstances (such as C- in one case and C- b13 in another).

* Having a way to format chord symbols and alterations in different ways
(stacked vertically vs horizontally, and in what order)

I think that gathering these use cases will be the most valuable part of
the process, since what I read in the proposal is a little vague, and
greatly overlaps with existing functionality.

Which is to say, I disagree that "the first action that will take place is
planning, designing, and implementing the modifications to EventChord"
because lacking clear use cases, how will you know what a good
representation is?

Some of the examples above point to additional modeling that is not present
in your proposal.  (Although perhaps this could be done with your existing
proposed model plus some business logic.)



"One specific result of this is a simpler and more powerful process of
chord naming, being able to name much more complex chords than it is
currently able to."

I'm not sure that "the process of chord naming" needs to be simpler, or
could be made simpler.

Most of the properties of the internal representation you suggest (root,
quality and extensions, voicing/inversion/bass note) are already
represented clearly in the input syntax.

The only property you mention that isn't explicit in the chord input syntax
is the scale degree.  However, if you have set a key signature, then the
scale degree could be said to be fully determined.

On the other hand, when doing functional analysis of modulations, there are
typically cases where a few chords should be analyzed with respect to both
the old and the new tonic, and so the concept of scale degree might be
independent of the actual chord, and rather be a property of the actua

Re: installing lilydev on OSX

[Flaming Hakama by Elaine]

> > ...
> > ERROR: Please install required programs:  FlexLexer.h (flex package)
> > guile-config < 1.9.0 (installed: 2.0.13) (guile-devel, guile-dev or
> ^^^
> > libguile-dev package) libguile (libguile-dev, guile-devel or guile-dev
> > package). GUILE-with-rational-bugfix
>
> This looks like you have installed LilyDev 5.1.
> Use this one only if you want to experiment with/contribute to the
> guilev2 moving problems.
> Please confirm you really want to do so, then I'll provide the howto.
>
> More likely you want to have LilyDev 4.1 (which works with guile-1.8)
> from the same website:
> https://github.com/fedelibre/LilyDev/releases
>
> Can't say anything about the OSX problems, though.
>
>
> Cheers,
>   Harm
>


Thanks for the advice.

The 4.1 version is working for me now, and did not have the mirror issue.
I was able to build lilypond, build a pdf from a mwe and view it in xpdf.

Just kicked off a make doc.


David Elaine Alt
415 . 341 .4954 <(415)%20341-4954>
  "*Confusion is highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

installing lilydev on OSX

[Flaming Hakama by Elaine]

I was tring to set up lilydev within virtualbox on OSX and had some
trouble.
Please let me know if you have any clues as to how I should proceed.


I was able to get virtualbox installed.

However, when loading the lilydev vm, there were two concerning things.

The first was right after choosing install, the following mount errors
appeared (briefly, I had to screen capture it).

mount: mounting /dev/sda on /media failed: Invalid argument
umount: can't umount /media: Invalid argument
mount: mounting /dev/sda on /media failed: Invalid argument


The second issue was during the install, the debian package manager
failed.  I tried several different mirror options, but they all produced
the same error:

[!!] Configure the package manager

Bad archive mirror

An error has been detected while trying to use the specified Debian archive
mirror.

Possible reasons for the error are: incorrect mirror specified;  mirror is
not available (possibly due to an unreliable network connection);  mirror
is broken (for example because an invalid Release file was found);  mirror
does not support the correct Debian version.

Additional details may be available in /var/log/syslog on virtual console 4.

Please check the specified mirror or try a different one.



Since I couldn't figure out a working mirror, and it provided me the option
to continue the install without the package manager, I proceeded without
the mirror.

I wondered whether the package manager issue was due to the network.  But
once I completed the install, rebooted the VM and logged in, I was able to
run ping on the command line with success.  And the lilypond script that
ran automatically completed with success.



Continuing through the quick start pages, when I run lily-git.tcl, it
opened a window with messages like

...checkout master...
already on master
your branch is up-to-date on 'origin/master'
...
switched to branch 'dev/local_working'


git-cl is available, and the git pull command says it's up to date.

I updated my Google account access and requested an account on the issue
tracker on the dev list.



Since git-cl seemed to be only for making changes, I figured I'd go ahead
and try to build lilypond based on
http://lilypond.org/doc/v2.19/Documentation/contributor/compiling-with-lilydev

So, I tried the following:

cd $LILYPOND_GIT
sh autogen.sh --noconfigure
mkdir -p build/
cd build/
../configure


And got these errors from the configure:

...
checking FlexLexer.h location... conftest.cc:2:23: fatal error:
FlexLexer.h: No such file or directory
 #include 
   ^
compilation terminated.
...
ERROR: Please install required programs:  FlexLexer.h (flex package)
guile-config < 1.9.0 (installed: 2.0.13) (guile-devel, guile-dev or
libguile-dev package) libguile (libguile-dev, guile-devel or guile-dev
package). GUILE-with-rational-bugfix



So, do you think this error is based on the package manager issue?
Or is this expected behavior?


Please let me know if you have any suggestions for how I should proceed to
get my lilybin installed and working.



Thanks,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

request for LilyPond issue tracker user account

[Flaming Hakama by Elaine]

I endeavored to start contributing to lilypond development.

I've been following the steps in the contributor docs, and on the git-cl
page instructs me:

http://lilypond.org/doc/v2.19/Documentation/contributor/git_002dcl
For the LilyPond issue tracker, please request a user account by sending an
email to the LilyPond Developer’s mailing list (lilypond-devel@gnu.org),
preferably using the same email address that you want to use for your user
login.


So, I'd like to get a LilyPond issue tracker user account for my email
ela...@flaminghakama.com

Please let me know if this is possible.


Thanks,

David Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel