Re: A proposal of organize music paragraph layout by a new DSL

[Aaron Hill]

On 2020-11-16 9:48 pm, K.L. wrote:
P.S. I can't imagine some guys in a band using a music sheet with 
different
measure indices for every track😂. How will they tell each other where I 
am
playing? If there are some repeat marks, will they be uniform in 
position?

If they are, solely declaring the first track's layout is enough.


I imagine that such complex pieces rely on rehearsal marks of some form 
rather than bar numbers.


Your DSL might not need to be complicated by such matters, as it seems 
like one could use your system multiple times explicitly:


(I'm typing quickly, so my apologies if I have mangled your proposed 
function.)



<<
  \repeat layout "..." << \new Staff {...} \new PianoStaff {...} >>
  \repeat layout "..." << \new TabStaff {...} >>
  \repeat layout "..." << \new RhythmicStaff {...} >>





This would let the first two instruments share the same layout while the 
other two can be unique.


I especially like this approach as it improves the locality of 
reference.  The layout DSL is most closely associated with what it 
affects.  Also, should one decide to rearrange the order of staves, you 
do not have to rearrange the order within the layout.



-- Aaron Hill

Re: A proposal of organize music paragraph layout by a new DSL

[K.L.]

P.S. I can't imagine some guys in a band using a music sheet with different
measure indices for every track😂. How will they tell each other where I am
playing? If there are some repeat marks, will they be uniform in position?
If they are, solely declaring the first track's layout is enough.

On Tue, Nov 17, 2020 at 1:33 PM K.L.  wrote:

> I see. For unequal-length measure tracks, we must declare layout for every
> track separately. However, if this situation occurs very often, maybe we
> should add a semantic for track, like:
>
> 1,2
>> 1,2,3
>> 1,2,3,4
>
> [image: image.png]
>
> For compactness, I suggest utilizing the new line character \n as a
> grammar token.
>
> Personally, I don't think this is very necessary.
>
> On Mon, Nov 16, 2020 at 9:16 PM Kieren MacMillan <
> kieren_macmil...@sympatico.ca> wrote:
>
>> Hi,
>>
>> >> How does that work with polymetric music?
>> > Sorry, I don't know what is polymetric music exactly. Can you show an
>> example?
>>
>> See the second example (“Different time signatures with unequal-length
>> measures”) in this section of the Lilypond docs:
>> <
>> http://lilypond.org/doc/v2.18/Documentation/notation/displaying-rhythms#polymetric-notation
>> >
>>
>> Cheers,
>> Kieren.
>> 
>>
>> Kieren MacMillan, composer (he/him/his)
>> ‣ website: www.kierenmacmillan.info
>> ‣ email: kie...@kierenmacmillan.info
>>
>>

Re: A proposal of organize music paragraph layout by a new DSL

[K.L.]

I see. For unequal-length measure tracks, we must declare layout for every
track separately. However, if this situation occurs very often, maybe we
should add a semantic for track, like:

1,2
> 1,2,3
> 1,2,3,4

[image: image.png]

For compactness, I suggest utilizing the new line character \n as a grammar
token.

Personally, I don't think this is very necessary.

On Mon, Nov 16, 2020 at 9:16 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi,
>
> >> How does that work with polymetric music?
> > Sorry, I don't know what is polymetric music exactly. Can you show an
> example?
>
> See the second example (“Different time signatures with unequal-length
> measures”) in this section of the Lilypond docs:
> <
> http://lilypond.org/doc/v2.18/Documentation/notation/displaying-rhythms#polymetric-notation
> >
>
> Cheers,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info
>
>

Re: Issue regarding Graphviz and local compilation

[jordankusel]

Dan and Thomas,

Thanks for the input, I was able to build and get Graphviz working. Still quite 
new to the C++ environment so I was running `sudo make install` without first 
just running `make` during my `--enable-checking` attempts - Thomas' commands 
clarified this. Appreciate the fast responses, I'm going to get to work!

- Jordan

‐‐‐ Original Message ‐‐‐
On Monday, November 16, 2020 3:53 PM, Thomas Morley  
wrote:

> Am Mo., 16. Nov. 2020 um 23:55 Uhr schrieb Dan Eble d...@faithful.be:
>
> > On Nov 16, 2020, at 15:49, jordankusel via Discussions on LilyPond 
> > development lilypond-devel@gnu.org wrote:
> >
> > > Hi Devs,
> > > even tried overriding `../configure` with `--prefix=/usr/local` to 
> > > declare this explicitly. Ideally, I'd like to install using the method 
> > > outlined in section 
> > > http://lilypond.org/doc/v2.19/Documentation/contributor/tracing-object-relationships
> > >  to enable the use of Graphviz for familiarizing myself with the codebase.
> >
> > Welcome, Jordan.
> > I had no idea that such a thing existed. Unless someone with more tenure 
> > has something to say about it, I would assume that that procedure has not 
> > been followed in a while and might need to be debugged and revised.
> > —
> > Dan
>
> Being on Ubuntu 20.04, I did:
>
> git checkout master
> git fetch
> git pull -r
> rm -fr build/
> sh autogen.sh --noconfigure
> mkdir -p build/
> cd build/
> ../configure --enable-checking
> make -j5 CPU_COUNT=5
> out/bin/lilypond ../input/regression/graphviz.ly 2> graphviz.log
> gedit graphviz.log [Editing the .log following CG]
> dot -Tpdf graphviz.log > graphviz.pdf
> evince graphviz.pdf
>
> and got the attached pdf. Looks ok to me.
>
> sudo make install
> was successful as well.
>
> So I can't reproduce the problem.
>
> Sorry, to be of not more help,
> Harm

Re: Issue regarding Graphviz and local compilation

[Thomas Morley]

Am Mo., 16. Nov. 2020 um 23:55 Uhr schrieb Dan Eble :
>
> On Nov 16, 2020, at 15:49, jordankusel via Discussions on LilyPond 
> development  wrote:
> >
> > Hi Devs,
> >
> > even tried overriding `../configure` with `--prefix=/usr/local` to declare 
> > this explicitly. Ideally, I'd like to install using the method outlined in 
> > section 
> > http://lilypond.org/doc/v2.19/Documentation/contributor/tracing-object-relationships
> >  to enable the use of Graphviz for familiarizing myself with the codebase.
>
> Welcome, Jordan.
>
> I had no idea that such a thing existed.  Unless someone with more tenure has 
> something to say about it, I would assume that that procedure has not been 
> followed in a while and might need to be debugged and revised.
> —
> Dan
>
>

Being on Ubuntu 20.04, I did:

git checkout master
git fetch
git pull -r
rm -fr build/
sh autogen.sh --noconfigure
mkdir -p build/
cd build/
../configure --enable-checking
make -j5 CPU_COUNT=5
out/bin/lilypond ../input/regression/graphviz.ly 2> graphviz.log
gedit graphviz.log[Editing the .log following CG]
dot -Tpdf graphviz.log > graphviz.pdf
evince graphviz.pdf

and got the attached pdf. Looks ok to me.

sudo make install
was successful as well.

So I can't reproduce the problem.

Sorry, to be of not more help,
  Harm


graphviz.pdf
Description: Adobe PDF document

Re: Issue regarding Graphviz and local compilation

[Dan Eble]

On Nov 16, 2020, at 15:49, jordankusel via Discussions on LilyPond development 
 wrote:
> 
> Hi Devs,
> 
> even tried overriding `../configure` with `--prefix=/usr/local` to declare 
> this explicitly. Ideally, I'd like to install using the method outlined in 
> section 
> http://lilypond.org/doc/v2.19/Documentation/contributor/tracing-object-relationships
>  to enable the use of Graphviz for familiarizing myself with the codebase.

Welcome, Jordan.

I had no idea that such a thing existed.  Unless someone with more tenure has 
something to say about it, I would assume that that procedure has not been 
followed in a while and might need to be debugged and revised.
— 
Dan

Issue regarding Graphviz and local compilation

[jordankusel via Discussions on LilyPond development]

Hi Devs,

First time poster here - I'm looking to modify some LilyPond features for a 
personal project I could see being useful to others in the future, assuming my 
goals are feasible for my current software skillset. I've successfully 
downloaded/compiled the source code according to the Contributor's Guide. 
However, when I try running `sudo make install` from the created/configured 
`/build` folder as outlined in the guide, the installation fails at `Making 
lily/out/lexer.cc`, saying `make: option requires an argument -- 'C'`. I 
believe I've followed the instructions to a T and even tried overriding 
`../configure` with `--prefix=/usr/local` to declare this explicitly. Ideally, 
I'd like to install using the method outlined in section 
http://lilypond.org/doc/v2.19/Documentation/contributor/tracing-object-relationships
 to enable the use of Graphviz for familiarizing myself with the codebase.

I am building from the most recent LilyPond master branch, cloned from Github, 
on Ubuntu 18.04. Please let me know if this is an appropriate post for the 
listserv or if any further information is needed.

Thank you!
- Jordan

PATCHES - Countdown for November 16th

[James Lowe]

Hello,

Here is the current patch countdown list. The next countdown will be on
November 18th.

A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority


 Push:

!509 Update lilypond-ftplugin.vim to adapt customized colon - Champignoom
https://gitlab.com/lilypond/lilypond/-/merge_requests/509

!507 Ensure deterministic conversion from MusicXML - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/507


 Countdown:

!513 Fix build verbosity for make 4.3 - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/513

!506 NR: Revise fonts section - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/506

!505 Regression tests for repeat start & length - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/505


 Review:

!514 main.cc: Show '-d=no-foo' in help screen (#2814) - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/514

!512 Doc: Small adjustments for NR 4.1.6 - Michael Käppler
https://gitlab.com/lilypond/lilypond/-/merge_requests/512


 New:

!510 Various font setup improvements - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/510


 Waiting:

!511 compile.itexi: Update requirements - Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/511


***


Regards,

James

Re: A proposal of organize music paragraph layout by a new DSL

[Kieren MacMillan]

Hi,

>> How does that work with polymetric music?
> Sorry, I don't know what is polymetric music exactly. Can you show an example?

See the second example (“Different time signatures with unequal-length 
measures”) in this section of the Lilypond docs:


Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: A proposal of organize music paragraph layout by a new DSL

[K.L.]

>
> How does that work with polymetric music?
>
>
Sorry, I don't know what is polymetric music exactly. Can you show an
example?

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

[Wols Lists]

On 15/11/20 15:14, Werner LEMBERG wrote:
> As Jonas said, this is a completely different issue, but yes, I think
> there implementing bar-centered bar numbers would need a completely
> different implementation.

IF this is seriously considered, can I throw in my thing often
encountered in band parts - numbered percent bars? Sounds like the code
might have a lot in common.

I'll often have things like \repeat \percent 16 (or even \repeat
\unfold), and from about the fourth bar it starts printing the bar count
above the bar.

Cheers,
Wol

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

[Wols Lists]

On 15/11/20 14:53, Werner LEMBERG wrote:
> 
>> I appreciate that you have given a nuanced response. Practically
>> speaking, the vast majority of scores only have bar numbers at the
>> beginning of a line, so I will simplistically categorise your response
>> as in favour of keeping LilyPond's current behaviour.
> 
> I would very much like that LilyPond has the ability of automatically
> adjusting the horizontal position of some grobs, in particular dynamic
> signs, bar numbers, and rehearsal marks.  The idea is that a large
> delta from the optimum vertical position would make LilyPond retry to
> horizontally position the grob within some delta (say, ±2 notehead
> widths) from the 'correct' position.  If the grob can then be moved
> (much) nearer to the standard vertical position, LilyPond should use
> this adjusted horizontal position.
> 
Plus 100 !!!

You know I moan about that regularly - page real estate is very valuable
to me and pushing grobs vertically wastes so much ...

I was told, unfortunately, that that will actually be very difficult to
implement :-(

Cheers,
Wol

Re: RFC: rethink horizontal alignment of mid-staff bar numbers

[Wols Lists]

On 15/11/20 13:37, Graham King wrote:
> I think Gould's positioning looks _slightly_ better, except at 
> line-beginnings where I definitely prefer lilypond's.  Moreover, the position 
> immediately after a bar line is heavily-contested real-estate, as your 
> examples make clear.  Therefore it would be good to retain the option to 
> preserve the status quo, especially where convert-ly might otherwise cause 
> skyline changes to existing scores.

Plus one for this. Although I'm quite happy with this MR
centre-justifying over the barline. Before the bar line definitely feels
wrong - I was taught to count rests by counting the bar number on the
last beat: 1 2 3 1 1 2 3 2 1 2 3 3 etc, so yes the bar number would
appear to apply to the wrong bar ...

Bear in mind we put rehearsal marks (including bar number marks)
centre-justified by default, so why not bar numbers.

And again, having options makes things better - don't forget not
everybody plays orchestral music, there's a LOT of music people might
want to copy that pre-dates Gould (is ANY post-Gould music out of
copyright?), and different traditions do things in different ways (much
of the stuff I like playing is pre-Gould).

Cheers,
Wol