Re: Double time signature when there are grace notes

[Thomas Weber]

Am 10.02.2017 um 23:48 schrieb Jacques Menu Muzhic:

Not a bug, but a feature : you have to add graces in all voices :




I already realized that:



Le 10 févr. 2017 à 23:23, Thomas Weber  a écrit :

* I can add a "grace space" to the bottom staff



But I tried to avoid this for the following reasons:



* The staffs won't work standalone ([...] broken spacing).
* I have to analyze all other staffs when writing out one staff.




How would you actually do this e.g. in an orchestral work where you want to 
create score and parts from the same data without distorting the spacing where 
invisible graces were added?  Would you work with tags to remove the invisible 
graces?

Best
Thomas

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

Re: tuplet slurs

[David Nalesnik]

Hi Werner,

On Thu, Feb 9, 2017 at 12:53 PM, Werner LEMBERG  wrote:
>
> For voices with lyrics it is common to put triplet indications always
> above the staff, using the following rules.
>
>. stems up or down, no beam: as usual (i.e., a number and a bracket
>  at the top, as if using \tupletUp)
>
>. stems up, with beam: as usual (i.e., a number over the beam)
>
> The last case, however, is unusual:
>
>. stem down, with beam: a number and a *slur* at the top.
>
> I would like to have a single command that makes lilypond do that
> automatically.  Has this been requested before?  A quick searched
> yielded nothing.
>
> Hopefully, the attached images makes everything clear (note that I
> don't need full brackets).
>

It strikes me that I've seen code somewhere that uses slurs instead of
brackets.  I find this:
http://www.lilypondforum.de/index.php?topic=1658.0

The results look great, but of course, the slur is broken.  It might
not be hard to modify that routine to do what you want..

How are you duplicating the other example, with an unbroken bracket?
If you displace the TupletNumber in an ordinary bracket, the gap will
remain.

Is the bracket notation fairly common?  I've certainly seen the
slur-above notation.

I'm asking because it might be fairly easy to modify the C++
TupletBracket stencil code to produce such slurs based on a context
property.

 Also, a full bracket might be used if the tuplet number wouldn't
intersect the bracket.  Maybe this should be default behavior?  I know
I've seen the bracket notation in Britten, albeit without the tuplet
number.

David

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

Re: chord names

[Klaus Blum]

Benjamin Bloomfield wrote
> I'm trying to figure out how to tweak the size of the sharp and flat
> symbol that displays when the chord name has one in it.  Those symbols are
> slightly taller than the capitals in my font, and I'd like to get them
> even.

Maybe there's an easier way, but here's a first solution. It's a quick
modification of 
http://www.lilypondforum.de/index.php?topic=824.0

%
--
#(define (note-name->international-markup pitch lowercase?)
   (let* (
   (name (ly:pitch-notename pitch))
   (alt (ly:pitch-alteration pitch))
   (hspace (vector-ref #(0.15 0.15 0.05 0.05 0.15) (+ (* alt 2) 2)))
   (raise (vector-ref #(0.6 0.6 0.65 0.8 0.7) (+ (* alt 2) 2)))
   )

 (if (>= alt 0)
 (make-line-markup
  (list
   (make-simple-markup
(if lowercase?
(vector-ref #("c" "d" "e" "f" "g" "a" "b") name)
(vector-ref #("C" "D" "E" "F" "G" "A" "B") name)
)
)
   (if (= alt 0)
   ;; If it's natural and not b, do nothing
   (make-line-markup (list empty-markup))
   ;; Else add alteration
   (make-line-markup
(list
 (make-hspace-markup hspace)
 (make-tiny-markup (make-raise-markup raise;
make-tiny-markup instead of make-smaller-markup
(make-musicglyph-markup
 (assoc-get alt
standard-alteration-glyph-name-alist ""
 ))
   )))
 (make-line-markup
  (list
   (make-simple-markup
(if lowercase?
(vector-ref #("c" "d" "e" "f" "g" "a" "b") name)
(vector-ref #("C" "D" "E" "F" "G" "A" "B") name)
)
)
   (if (= alt 0)
   ;; If it's natural and not b, do nothing
   (make-line-markup (list empty-markup))
   ;; Else add alteration
   (make-line-markup
(list
 (make-hspace-markup hspace)
 (make-tiny-markup (make-raise-markup raise;
make-tiny-markup instead of make-smaller-markup
(make-musicglyph-markup
 (assoc-get alt
standard-alteration-glyph-name-alist ""
 ))
   )))
 )
 )
   )

internationalChords = {
  \set Staff.chordRootNamer = #note-name->international-markup
  % \unset Staff.chordNoteNamer
}

\new ChordNames \chordmode {
  as a ais bes b bis
  \internationalChords
  as a ais bes b bis
}
%
--

Cheers, 
Klaus



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/chord-names-tp199985p10.html
Sent from the User mailing list archive at Nabble.com.

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

Re: chord names

[Klaus Blum]

Hi Ben, 

Benjamin Bloomfield wrote
> I'm trying to figure out how to make chord modifiers like "sus4" not be
> superscript.

for your first issue you can modify what you've found in "Customizing chord
names": 

% ---
chExceptionMusic = {
  1-\markup { \tiny "sus4" }
}

% Convert music to list and prepend to existing exceptions.
chExceptions = #( append
  ( sequential-music-to-chord-exceptions chExceptionMusic #t)
  ignatzekExceptions)

\new ChordNames \chordmode {
  g1:sus4
  \set chordNameExceptions = #chExceptions
  g1:sus4
}

\layout {
  ragged-right = ##t
}
% ---

Cheers, 
Klaus





--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/chord-names-tp199985p199989.html
Sent from the User mailing list archive at Nabble.com.

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

Re: tuplet slurs

[J Martin Rushton]

On 09/02/17 18:53, Werner LEMBERG wrote:
> 
> For voices with lyrics it is common to put triplet indications always
> above the staff, using the following rules.
> 
>. stems up or down, no beam: as usual (i.e., a number and a bracket
>  at the top, as if using \tupletUp)
> 
>. stems up, with beam: as usual (i.e., a number over the beam)
> 
> The last case, however, is unusual:
> 
>. stem down, with beam: a number and a *slur* at the top.
> 
> I would like to have a single command that makes lilypond do that
> automatically.  Has this been requested before?  A quick searched
> yielded nothing.

See my "Triplets" thread started 14/01/17 18:14.  In the end I gave up
and used the Lilypond standard in the interests of speed.


> Hopefully, the attached images makes everything clear (note that I
> don't need full brackets).
> 
> 
> Werner



signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Double time signature when there are grace notes

[Noeck]

Am 10.02.2017 um 23:48 schrieb Jacques Menu Muzhic:
> Not a bug, but a feature

Well, I'd say a bug but a well known one:
https://sourceforge.net/p/testlilyissues/issues/34/

Joram

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

Re: Double time signature when there are grace notes

[Jacques Menu Muzhic]

Hello Thomas,

Not a bug, but a feature : you have to add graces in all voices :

\version "2.19.44"

<<
  {
c'1
\break
\time 15/16
\grace a'16 b'2...
  }

  {
R1
\break
\time 15/16
\grace s16 c'2...
  }
>>

JM

> Le 10 févr. 2017 à 23:23, Thomas Weber  a écrit :
> 
> Dear all,
> 
> 
> I need help with the following situation:
> 
> 
> \version "2.19.54"
> 
> <<
> {
>  c'1
>  \break
>  \time 15/16
>  \grace a'16 b'2...
> }
> 
> {
>  R1
>  \break
>  \time 15/16
>  c'2...
> }
> >>
> 
> 
> This results in the attached output.  Is that a bug or is this supposed to be 
> encoded differently?  There are dirty workarounds:
> 
> * I can fix it by removing the \time from the bottom staff.
> * I can add a "grace space" to the bottom staff[1]
> 
> Both solutions have the following disadvantages I want to avoid:
> 
> * The staffs won't work standalone (missing time signature or broken spacing).
> * I have to analyze all other staffs when writing out one staff.
> 
> I'm looking for a reliable solution that works well for auto-generating 
> Lilypond code.
> 
> 
> Highly appreciating any help on this,
> Thomas Weber
> 
> 
> [1] https://lists.gnu.org/archive/html/lilypond-user/2004-08/msg00258.html
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

chord names

[Benjamin Bloomfield]

I'm trying to figure out how to make chord modifiers like "sus4" not be
superscript.  It seems like there should be a simple way to do that, but I
don't see it in the "Customizing Chord Names"

section of the manual.

Also, I'm trying to figure out how to tweak the size of the sharp and flat
symbol that displays when the chord name has one in it.  Those symbols are
slightly taller than the capitals in my font, and I'd like to get them even.

Thanks,

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

Double time signature when there are grace notes

[Thomas Weber]

Dear all,


I need help with the following situation:


\version "2.19.54"

<<
{
  c'1
  \break
  \time 15/16
  \grace a'16 b'2...
}

{
  R1
  \break
  \time 15/16
  c'2...
}
>>


This results in the attached output.  Is that a bug or is this supposed to be 
encoded differently?  There are dirty workarounds:

* I can fix it by removing the \time from the bottom staff.
* I can add a "grace space" to the bottom staff[1]

Both solutions have the following disadvantages I want to avoid:

* The staffs won't work standalone (missing time signature or broken spacing).
* I have to analyze all other staffs when writing out one staff.

I'm looking for a reliable solution that works well for auto-generating 
Lilypond code.


Highly appreciating any help on this,
Thomas Weber


[1] https://lists.gnu.org/archive/html/lilypond-user/2004-08/msg00258.html

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

Re: Multiple markings

[David Sumbler]

On Tue, 2017-02-07 at 23:01 +0100, Thomas Morley wrote:
> Meanwhile why not use some of the workarounds?
> 
> (1)
> \mark \markup <\[center-]column> 
> (already mentioned)
> 
> (2)
> http://lsr.di.unimi.it/LSR/Item?id=976
> or
> http://lsr.di.unimi.it/LSR/Item?id=977
> 
> (3)
> http://old.nabble.com/Nice-workaround-for-simultaneous-rehearsal-mark
> s-%E2%80%93-thanks-Neil!-td32212763.html

I spent some time studying and experimenting with all of these.  But
LSR 976 in particular is amazing - it does everything I am ever likely
to want to do with Marks, and a lot more besides.

I have now modified my project to use this method.  Thank you for
suggesting it, and thank you to Arnold, Neil and anyone else whose work
went into it.

David

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

Re: 48 and 72 ET

[Bernardo Barros]

On 10/02/2017 04:47, Thomas Richter wrote:
> I wrote an extension for 72ET "Ekmelily":
> http://www.ekmelic-music.org/en/extra/ekmelily.htm
> It uses by default ins own font (Ekmelos) but it should work with e.g.
> Bravura, too.
> 

Thanks, Thomas.

It looks like excellent work. It should be merged into LilyPond. Also
LilyPond should improve its default font to work with it.



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

Re: New LilyPond website

[Johan Vromans]

On Fri, 10 Feb 2017 10:51:05 +0100, Michael Gerdau  wrote:

> The new page is about 1.3 MB while the original one is about 170 kB
> Factor of 7.x

This is due to CSS/JS overhead and happens only once.

-- Johan

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

Re: long `instrument' names in frenched scores

[Kieren MacMillan]

Hi Werner,

> In vocal scores it is common that singer parts that were omitted for
> some sytems are introduced again with its full name – not written in
> front of the system but at the beginning of the line.
> 
> Do we have support for this feature already?

As far as I know, the answer is no.

This is a feature that I’ve long desired — and am still willing to sponsor — 
not just for frenched staves, but for part-combined staves. If I understand 
Scheme engravers correctly (which is far from guaranteed), this *should* be a 
relatively easy engraver to design and implement… but it’s definitely above my 
pay grade.

Cheers,
Kieren.


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


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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 10:58, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 10 Feb 2017, at 10:24, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote:
> 
> On Fri, 10 Feb 2017, David Kastrup wrote:
>> enthused.  Why wouldn't we want to have best practices pointed out and
>> promoted on the user list?
> 
> Best practices do not include attacking other list users.
 
 It is the human interface part that is amiss.
>>> 
>>> Don't hold your breath for a timely revamp.
>> 
>> So then you'll have to accept that people don't use convert-ly. :-)
> 
> I don't _deny_ that people don't use convert-ly but I don't need to
> _accept_ it.  Where would be the point in any work if you'll instead
> "have to accept" that the work isn't done before you start with it?

You don't have to accept that the sun is rising every day, but it won't change 
a thing.



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

Re: New LilyPond website

[Michael Gerdau]

> in total. After enabling scripts this problem vanishes.
> 
> In Vivaldi I don't see the background image at the top of the page
> at all.
> 
> 
> I test using all major browsers including Vivaldi (my main browser) and
> I am not getting any of these issues. 

Hmm. What is that to imply? That there is no problem?

I've disabled all extensions to check if one of these would interfere
(not that I expected it but you never know :) ) - no change.

For the record I'm using Vivaldi 1.6.689.46 (Stable channel) (64-Bit)
on Linux. JavaScript V8 5.5.372.33

It is invoked by /usr/bin/vivaldi-stable --always-authorize-plugins
--disable-translate --enable-blink-features=ResizeObserver
--flag-switches-begin --flag-switches-end


Another point I realized is the amount of stuff that gets downloaded for
the new page and for the original one:
The new page is about 1.3 MB while the original one is about 170 kB
Factor of 7.x

Not an issue for those with proper inet connections. Not sure about
rural areas.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

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

Re: 48 and 72 ET

[David Kastrup]

Hans Åberg  writes:

>> On 10 Feb 2017, at 10:24, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote:
 
 On Fri, 10 Feb 2017, David Kastrup wrote:
> enthused.  Why wouldn't we want to have best practices pointed out and
> promoted on the user list?
 
 Best practices do not include attacking other list users.
>>> 
>>> It is the human interface part that is amiss.
>> 
>> Don't hold your breath for a timely revamp.
>
> So then you'll have to accept that people don't use convert-ly. :-)

I don't _deny_ that people don't use convert-ly but I don't need to
_accept_ it.  Where would be the point in any work if you'll instead
"have to accept" that the work isn't done before you start with it?

-- 
David Kastrup

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

Re: 48 and 72 ET

[Thomas Richter]

Am 09.02.2017 um 20:18 schrieb Bernardo Barros:

Hello,

Quarter-tones (24ET) work very well and use the most used symbols.

Is there any implementation of eighth-tone (48ET) with arrows for the
8th-tone alterations, or even better, 72ET?

I know "makam.ly" could be a good start, I'm just wondering if anyone
has done it already.

Thank you!


I wrote an extension for 72ET "Ekmelily":
http://www.ekmelic-music.org/en/extra/ekmelily.htm
It uses by default ins own font (Ekmelos) but it should work with e.g. 
Bravura, too.


Best, Thomas


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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 10:24, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote:
>>> 
>>> On Fri, 10 Feb 2017, David Kastrup wrote:
 enthused.  Why wouldn't we want to have best practices pointed out and
 promoted on the user list?
>>> 
>>> Best practices do not include attacking other list users.
>> 
>> It is the human interface part that is amiss.
> 
> Don't hold your breath for a timely revamp.

So then you'll have to accept that people don't use convert-ly. :-)




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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 10:22, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 10 Feb 2017, at 00:35, David Kastrup  wrote:
>>> 
>>> Hans Åberg  writes:
>>> 
> On 10 Feb 2017, at 00:16, David Kastrup  wrote:
> 
> So is there any reason people don't use convert-ly when upgrading to
> a newer version?
 
 For libraries, you would want to keep track of the changes, but
 running convert-ly and do a diff is a good suggestion.
>>> 
>>> convert-ly -d inserts an updated \version header.
>> 
>> You wouldn't want to do that with library headers, in case something
>> goes wrong. Better to create a separate file, and check file dates, as
>> in a Makefile.
>> 
 Though doing it by hand was quicker, as I remembered the issue and
 which files needed to be fixed.
>>> 
>>> How does _this_ "keep track of the changes"?  Maybe you consider your
>>> biological memory part of the data on your computer?
>> 
>> I cannot parse this.
> 
> You said "you would want to keep track of the changes" as a reason to do
> changes manually rather than by convert-ly.  I tried reading some sense
> into that statement but apparently we have very little common ground
> regarding what we consider making sense.

See the letter from Urs Liska, how he works. It is the human brain that makes 
sure things are correct. Also see the letter by Graham Breed: it is great that 
convert-ly can do the job. But also see the letter by Simon Albrecht: 
convert-ly does not always do it right. So it is good to make that sure, 
especially in a library. Even though it could do it in this case, as you found 
out, I did not need it, and in the past, a very long time ago, I think that 
convert-ly failed, and I haven't needed it since.



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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 04:20, Bernardo Barros  wrote:
> 
> On 09/02/2017 17:22, Hans Åberg wrote:
> 
>> 1. 
>> https://secure2.storegate.com/Shares/Home.aspx?ShareID=35e0b920-6910-4e4f-8340-7d8290115dda

> thank you!

Let me know if it works!



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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 00:34, Urs Liska  wrote:
> 
> Am 10.02.2017 um 00:22 schrieb Hans Åberg:
>>> So is there any reason people don't use convert-ly when upgrading to a
>>> newer version?
>>> 
>> For libraries, you would want to keep track of the changes, but running 
>> convert-ly and do a diff is a good suggestion. Though doing it by hand was 
>> quicker, as I remembered the issue and which files needed to be fixed.
>> 
>> In general, though, perhaps people maybe do not think or know about it, so 
>> the process might be automated.
>> 
>> 
> 
> When maintaining libraries one should want to make them compatible with 
> multiple LilyPond versions, IMO at least with the current stable and devel 
> version, but depending on the use case and target audience one might even 
> support the previous stable release.
> In order to be able to do that in openLilyLib I created the version 
> comparison operators/predicates 
> (https://github.com/openlilylib/oll-core/blob/master/internal/lilypond-version-predicates.scm)
>  which make it easy to write switches based on the currently run LilyPond 
> version.
> 
> I intend to create a patch to include this functionality into LilyPond, but 
> so far I'm not really sure *where* these functions should be defined and 
> where they could adequately be documented.

For regular.ly, Graham made it originally for an earlier LilyPond version only. 
I then was able to make it for latest LilyPond, but not updating it. But now, 
it works for latest LilyPond again. So there a certain span of versions, here.



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

Re: New LilyPond website

[Johan Vromans]

On Thu, 9 Feb 2017 14:32:18 -0800, "H. S. Teoh" 
wrote:

> I don't speak for anyone else, but I'm perfectly OK with using
> Javascript -- as long as it's not *required* for the website to be
> usable at all.

And all necessary javascript is loaded from the site itself, not from
(potential unreliable) 3rd party sites.

-- Johan

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

Re: 48 and 72 ET

[David Kastrup]

Hans Åberg  writes:

>> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote:
>> 
>> On Fri, 10 Feb 2017, David Kastrup wrote:
>>> enthused.  Why wouldn't we want to have best practices pointed out and
>>> promoted on the user list?
>> 
>> Best practices do not include attacking other list users.
>
> It is the human interface part that is amiss.

Don't hold your breath for a timely revamp.

-- 
David Kastrup

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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 00:55, Simon Albrecht  wrote:
> 
> On 10.02.2017 00:19, Hans Åberg wrote:
>> If LilyPond knows how to run the code via convert-ly, why does it not do it?
> 
> LilyPond itself doesn’t change the code it is reading. convert-ly is a 
> separate Python script.
> It might be a valid feature request, though, to have a command-line option 
> which makes LilyPond call convert-ly, if the \version statement points to an 
> older version, and then read the resulting code.

If a .ly file is outdated, LilyPond might run convert-ly to create a new .lyo 
file, if it not already exists and is newer than the original (as in a 
Makefile). Then run the .lyo file instead if it is newer.

> That would leave some things to be designed though, e.g. what would happen if 
> convert-ly issues ‘Not smart enough to update…’ – which happens?

Then one would get an error message, as if there was only a direct compile.



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

Re: 48 and 72 ET

[David Kastrup]

Hans Åberg  writes:

>> On 10 Feb 2017, at 00:35, David Kastrup  wrote:
>> 
>> Hans Åberg  writes:
>> 
 On 10 Feb 2017, at 00:16, David Kastrup  wrote:
 
 So is there any reason people don't use convert-ly when upgrading to
 a newer version?
>>> 
>>> For libraries, you would want to keep track of the changes, but
>>> running convert-ly and do a diff is a good suggestion.
>> 
>> convert-ly -d inserts an updated \version header.
>
> You wouldn't want to do that with library headers, in case something
> goes wrong. Better to create a separate file, and check file dates, as
> in a Makefile.
>
>>> Though doing it by hand was quicker, as I remembered the issue and
>>> which files needed to be fixed.
>> 
>> How does _this_ "keep track of the changes"?  Maybe you consider your
>> biological memory part of the data on your computer?
>
> I cannot parse this.

You said "you would want to keep track of the changes" as a reason to do
changes manually rather than by convert-ly.  I tried reading some sense
into that statement but apparently we have very little common ground
regarding what we consider making sense.

>> It's a common fallacy of young programmers that may take a few decades
>> to cure.
>
> Nor this.

Basically the same idea.  Young programmers don't need to write comment
or documentation since "it's all in their heads" where they keep track
of changes.  But since that apparently wasn't what you were getting at,
never mind.

-- 
David Kastrup

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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 00:39, msk...@ansuz.sooke.bc.ca wrote:
> 
> On Fri, 10 Feb 2017, David Kastrup wrote:
>> enthused.  Why wouldn't we want to have best practices pointed out and
>> promoted on the user list?
> 
> Best practices do not include attacking other list users.

It is the human interface part that is amiss.



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

Re: 48 and 72 ET

[Hans Åberg]

> On 10 Feb 2017, at 00:35, David Kastrup  wrote:
> 
> Hans Åberg  writes:
> 
>>> On 10 Feb 2017, at 00:16, David Kastrup  wrote:
>>> 
>>> So is there any reason people don't use convert-ly when upgrading to
>>> a newer version?
>> 
>> For libraries, you would want to keep track of the changes, but
>> running convert-ly and do a diff is a good suggestion.
> 
> convert-ly -d inserts an updated \version header.

You wouldn't want to do that with library headers, in case something goes 
wrong. Better to create a separate file, and check file dates, as in a Makefile.

>> Though doing it by hand was quicker, as I remembered the issue and
>> which files needed to be fixed.
> 
> How does _this_ "keep track of the changes"?  Maybe you consider your
> biological memory part of the data on your computer?

I cannot parse this.

> It's a common fallacy of young programmers that may take a few decades
> to cure.

Nor this.



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