Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[trueroad]

Great!
But, I failed to build in my Cygwin (case insensitive) environment.


I think there is potential confusion where the CID file has no

extension,

and just has capitalization to indicate it.  Is this a standard for
CID-keyed fonts?



Actually, it is, but I don't see a reason to not use `.cid' as an

extension.

If I understand correctly, CID-keyed OpenType fonts have `.otf'
extension instead of `.cid' extension.
e.g. `SourceHanSerif-Regular.otf' is a CID-keyed font.


https://codereview.appspot.com/343970043/

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

Re: Microrhythm

[Colin Campbell]

On 2018-05-26 04:12 PM, David Kastrup wrote:

Arthur Reutenauer  writes:


I have to correct a post from the other day: In my 30+ years on electronic 
networks, *this* is the hardest I’ve ever seen anyone work to die on a hill not 
worth dying on.

   Hold that thought...

Well, that too.

I won't presume to judge the worthiness of this particular hill, but
I doubt that the best way to scale it is digging yourself in a hole.

With no particular horse in this race, it may be worth observing that 
feeding trolls is not generally a useful way of passing the time. I'm 
just going to update my filters.



Cheers,

Colin

--
Never confuse motion with action. -Benjamin Franklin, statesman, author, 
and inventor (1706-1790)


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

Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[knupero]

https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):

https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
On 2018/05/26 15:17:09, Carl wrote:

I think there is potential confusion where the CID file has no

extension, and

just has capitalization to indicate it.  Is this a standard for

CID-keyed fonts?

ghostscript uses fontname=filename with no extension for CID replacement
fonts. In an old version of the code I used this mechanism of
ghostscript. With this version of the code the CID font is explicitely
loaded in encodingdefs.ps, so almost any name might me used.

The file emmentaler-20.otf defines the non-cid font Emmentaler-20. It is
used by lilypond during generation of the ps code. We need this non-cid
font as it contains the glyph names we use in lilypond.

If during processing of the ps code contained in encodingdefs.ps
ghostscript sees that the non-cid Emmentaler-20 font is used, the code
instructs gs to load the cid font. Then it used the same name
Emmentaler-20 again for the font composed from the Emmentaler-20 font
and the Identity-H CMap.

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in
File mf/emmentaler-brace.pe.in (right):

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in#newcode89
mf/emmentaler-brace.pe.in:89:
ConvertByCMap("/usr/share/ghostscript/9.23/Resource/CMap/Identity-H")
On 2018/05/26 15:17:09, Carl wrote:

This hard-coded 9.23 seems to me to be broken in advance.


Yes, it is broken, I'll fix it. Thanks for spotting.

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in
File ps/cidres.in (right):

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in#newcode1
ps/cidres.in:1: lilypond-datadir (/fonts/otf/Emmentaler-11)
concatstrings (r) file .loadfont
Both cidres.ps and encodingdefs.ps could and should be generated, yes.
This is one of the reasons why I wrote about proof of concept, not ready
for release.

https://codereview.appspot.com/343970043/

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

Let general-column deal reliable with empty args (issue 346030043 by thomasmorle...@gmail.com)

[thomasmorley65]

Reviewers: ,

Description:
Let general-column deal reliable with empty args

Previously an args-list of empty-stencils issued a programming error:
  Improbable offset for stencil: -inf staff space
This patch removes empty stencils from the args-list.
If args-list is empty, an empty stencil is returned.

Please review this at https://codereview.appspot.com/346030043/

Affected files (+16, -6 lines):
  M scm/define-markup-commands.scm


Index: scm/define-markup-commands.scm
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index  
0eb9ed93542ea9e7f61abaaf5a890fb8ff6ed0db..a1a8d86593fabd48a40a1909e1ed38b02ff70a5d  
100644

--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -1999,12 +1999,22 @@ setting of the @code{direction} layout property.
(interpret-markup-list layout props args)))

 (define (general-column align-dir baseline mols)
-  "Stack @var{mols} vertically, aligned to  @var{align-dir} horizontally."
-
-  (let* ((aligned-mols (map (lambda (x) (ly:stencil-aligned-to x X  
align-dir)) mols))

- (stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
- (stacked-extent (ly:stencil-extent stacked-stencil X)))
-(ly:stencil-translate-axis stacked-stencil (- (car stacked-extent)) X  
)))

+  "Stack @var{mols} vertically, aligned to @var{align-dir} horizontally.
+Remove empty stencils from @var{mols}.  If @var{mols} is an empty list  
return

+@code{empty-stencil}."
+  (let ((aligned-mols
+  (filter-map
+(lambda (x)
+  (if (ly:stencil-empty? x)
+  #f
+  (ly:stencil-aligned-to x X align-dir)))
+mols)))
+(if (pair? aligned-mols)
+(let* ((stacked-stencil (stack-lines -1 0.0 baseline aligned-mols))
+   (stacked-extent (ly:stencil-extent stacked-stencil X)))
+  (ly:stencil-translate-axis
+stacked-stencil (- (car stacked-extent)) X))
+empty-stencil)))

 (define-markup-command (center-column layout props args)
   (markup-list?)



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

Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[knupero]

However, I believe that the case problem with MacOS needs to be fixed.

 I

believe this patch won't work on MacOS -- only one version of the font

will be

installed (the last one to be created).


I wasn't aware of MacOS case handling, I'll have a look at it.
Thanks for pointing out that problem.



https://codereview.appspot.com/343970043/

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

Re: Microrhythm

[David Kastrup]

Arthur Reutenauer  writes:

>> I have to correct a post from the other day: In my 30+ years on electronic 
>> networks, *this* is the hardest I’ve ever seen anyone work to die on a hill 
>> not worth dying on.
>
>   Hold that thought...

Well, that too.

I won't presume to judge the worthiness of this particular hill, but
I doubt that the best way to scale it is digging yourself in a hole.

-- 
David Kastrup

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

Re: Microrhythm

[Arthur Reutenauer]

> I have to correct a post from the other day: In my 30+ years on electronic 
> networks, *this* is the hardest I’ve ever seen anyone work to die on a hill 
> not worth dying on.

  Hold that thought...

Arthur

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

Re: Microrhythm

[David Kastrup]

Carl Sorensen  writes:

> On 5/26/18, 10:44 AM, "lilypond-devel on behalf of David Kastrup"
>  d...@gnu.org> wrote:
>
> 
> Entirely subjective which hill is worth dying on: Güllich was the first
> to extensively exposed hard "solo" routes, with the final climb being
> without protection where a missed or broken-out hold would have been
> deadly.  Nobody thought he'd live to old age, but nobody imagined he'll
> die falling asleep behind the wheel.
> 
> I believe the English idiom about dying on a hill makes reference not
> to dying on a climb, but rather to warfare, where one would die trying
> to protect high ground that has strategic importance in the battle.  A
> 1.5 meter high hill virtually never has strategic importance; hence
> it's not worth dying on.

Oh, I was just prattling.  I wasn't deluding myself into thinking hill
climbing to be considered of proverbial importance.

-- 
David Kastrup

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

Re: Microrhythm

[Carl Sorensen]

On 5/26/18, 10:44 AM, "lilypond-devel on behalf of David Kastrup" 
 
wrote:


Entirely subjective which hill is worth dying on: Güllich was the first
to extensively exposed hard "solo" routes, with the final climb being
without protection where a missed or broken-out hold would have been
deadly.  Nobody thought he'd live to old age, but nobody imagined he'll
die falling asleep behind the wheel.

I believe the English idiom about dying on a hill makes reference not to dying 
on a climb, but rather to warfare, where one would die trying to protect high 
ground that has strategic importance in the battle.  A 1.5 meter high hill 
virtually never has strategic importance; hence it's not worth dying on.  

Carl

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

Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[David Kastrup]

lemzw...@googlemail.com writes:

> LGTM, but I share Carl's concerns, in particular the issue  with font
> names that only differ in case.

That sounds like a problem not just on MacOSX but also on Windows.

> https://codereview.appspot.com/343970043/

-- 
David Kastrup

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

Re: Microrhythm

[David Kastrup]

Kieren MacMillan  writes:

> metachromatic  wrote:
>>>To see how silly your comment on this issue is, let's calculate the
>>> difference in time twixt a tuplet like 7919/4451 against a tuplet
>>> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
>>> a tempo of metronome marking 90:
>>> 
>>>The difference is (0.00064839149)*60/90 seconds per quarter note =
>>> 0.00043226099 seconds per quarter note.  But after only 200 quarter
>>> notes (that is, 50 measures of 4/4, taking only two minutes and 13
>>> seconds), that difference in timing has grown to ~ 1/11 second. And I
>>> guarantee you that you can easily hear whether one melodic line is
>>> offset from another by 1/11 second, since that equates to a difference
>>> of slightly less than an eighth note at tempo 90.
>>> 
>>>Now, come on, Han-Wen...are you _really_ telling me the average
>>> listener can't hear the duration of an eighth note a tempo mm = 90?
>>> Seriously?
>
> I have to correct a post from the other day: In my 30+ years on
> electronic networks, *this* is the hardest I’ve ever seen anyone work
> to die on a hill not worth dying on.

Well, there is an immense body of readily composed and performed and
recorded music.  If "good enough" were a universal perception, we'd have
little use for composers and performers any more.
https://en.wikipedia.org/wiki/Action_Directe_(climb)

> And, bonus, it’s done with an extra helping of condescension.

Hey, I do rock climbing.  Lots of hills around with an elevation not
particularly impressive.  "Action Directe"
 is 15m in length.
The Wikipedia page states that Wolfgang Güllich needed 11 days for first
redpointing the route (climbing in one go from the ground while clipping
the belay rope to the bolts and without ever falling or otherwise
weighting the rope).  That glosses over the detail that he rebuilt the
key moves (or rather jumps) in size in his private gymnasium and spent a
season training them.

Here is a dramatized video:  without all
the hubbub (I admit to not bothering turning on the sound) and slow
motion the final climb would be about 30 seconds.

Entirely subjective which hill is worth dying on: Güllich was the first
to extensively exposed hard "solo" routes, with the final climb being
without protection where a missed or broken-out hold would have been
deadly.  Nobody thought he'd live to old age, but nobody imagined he'll
die falling asleep behind the wheel.

I digress: particularly when people don't want to see the worthiness of
your hill, condescension helps to set you apart.  Zealotry is first and
foremost about convincing yourself.

Where is the point in composing a fugue on the theme

\language "german" \relative { b a c h } ?

In this particular case, however, we are talking about a climb involving
voluntary porters, and yelling at them and calling them stupid for not
wanting to line up for unpaid duty faster is, well, not conducive to
getting that hill climbed.  I don't think even Old Bach would have had
much success with that approach.

-- 
David Kastrup

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

Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[lemzwerg]

LGTM, but I share Carl's concerns, in particular the issue  with font
names that only differ in case.


https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):

https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
On 2018/05/26 15:17:09, Carl wrote:

I think there is potential confusion where the CID file has no

extension,

and just has capitalization to indicate it.  Is this a standard for
CID-keyed fonts?


Actually, it is, but I don't see a reason to not use `.cid' as an
extension.

https://codereview.appspot.com/343970043/

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

Re: Microrhythm

[Kieren MacMillan]

metachromatic  wrote:
>>To see how silly your comment on this issue is, let's calculate the
>> difference in time twixt a tuplet like 7919/4451 against a tuplet
>> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
>> a tempo of metronome marking 90:
>> 
>>The difference is (0.00064839149)*60/90 seconds per quarter note =
>> 0.00043226099 seconds per quarter note.  But after only 200 quarter
>> notes (that is, 50 measures of 4/4, taking only two minutes and 13
>> seconds), that difference in timing has grown to ~ 1/11 second. And I
>> guarantee you that you can easily hear whether one melodic line is
>> offset from another by 1/11 second, since that equates to a difference
>> of slightly less than an eighth note at tempo 90.
>> 
>>Now, come on, Han-Wen...are you _really_ telling me the average
>> listener can't hear the duration of an eighth note a tempo mm = 90?
>> Seriously?

I have to correct a post from the other day: In my 30+ years on electronic 
networks, *this* is the hardest I’ve ever seen anyone work to die on a hill not 
worth dying on. And, bonus, it’s done with an extra helping of condescension.

Best of luck!
Kieren.


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


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

Re: Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[Carl . D . Sorensen]

The patch looks well put together.

However, I believe that the case problem with MacOS needs to be fixed.
I believe this patch won't work on MacOS -- only one version of the font
will be installed (the last one to be created).


https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):

https://codereview.appspot.com/343970043/diff/1/mf/GNUmakefile#newcode145
mf/GNUmakefile:145: cd $(outdir) && mv $(notdir $@).otf $(notdir $@)
I think there is potential confusion where the CID file has no
extension, and  just has capitalization to indicate it.  Is this a
standard for CID-keyed fonts?

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in
File mf/emmentaler-brace.pe.in (right):

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in#newcode89
mf/emmentaler-brace.pe.in:89:
ConvertByCMap("/usr/share/ghostscript/9.23/Resource/CMap/Identity-H")
This hard-coded 9.23 seems to me to be broken in advance.

https://codereview.appspot.com/343970043/diff/1/mf/emmentaler-brace.pe.in#newcode90
mf/emmentaler-brace.pe.in:90: Generate("Emmentaler-Brace.otf")
Will this work on MacOS?  IIRC, the default file system on MacOS is
case-insensitive, although it allows the used of mixed case.  THis means
you can have emmentaler-brace,otf or Emmentaler-Brace.otf, but I don't
think you can have both by default on MacOS.

For compatibility, I think there needs to be a different name.

Here's an example that shows the problem:

Carls-MBP:junk carlsorensen$ echo "This is a test" > test
Carls-MBP:junk carlsorensen$ cat test
This is a test
Carls-MBP:junk carlsorensen$ echo "This is an UpperCase test " > Test
Carls-MBP:junk carlsorensen$ cat Test
This is an UpperCase test
Carls-MBP:junk carlsorensen$ cat test
This is an UpperCase test

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in
File ps/cidres.in (right):

https://codereview.appspot.com/343970043/diff/1/ps/cidres.in#newcode1
ps/cidres.in:1: lilypond-datadir (/fonts/otf/Emmentaler-11)
concatstrings (r) file .loadfont
The hardcoding of all the font sizes here seems broken.  If we change
the sizes to be generated from the .mf files; then this won't work any
more.  It seems there should be one variable that lists all of the sizes
to be generated, and that variable should be used throughout the build.

I guess that would meant that rather than having cidres.ps be a
developer-created file, there should be some kind of a template file and
a make command that would cat together cidres.ps using the template file
and the font size variable.

But recognizing that encodingdefs.ps doesn't follow this practice in the
current distribution, this comment may be without merit (or else it
would apply equally to encodingdefs.ps as well.

https://codereview.appspot.com/343970043/

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

Re: Microrhythm

[Han-Wen Nienhuys]

On Sat, May 26, 2018 at 8:35 AM, metachromatic  wrote:
> To see how silly your comment on this issue is, let's calculate the
>  difference in time twixt a tuplet like 7919/4451 against a tuplet
>  7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
>  a tempo of metronome marking 90:
>
> The difference is (0.00064839149)*60/90 seconds per quarter note =
>  0.00043226099 seconds per quarter note.  But after only 200 quarter
>  notes (that is, 50 measures of 4/4, taking only two minutes and 13
>  seconds), that difference in timing has grown to ~ 1/11 second. And I
>  guarantee you that you can easily hear whether one melodic line is
>  offset from another by 1/11 second, since that equates to a difference
>  of slightly less than an eighth note at tempo 90.
>
> Now, come on, Han-Wen...are you _really_ telling me the average
>  listener can't hear the duration of an eighth note a tempo mm = 90?
>  Seriously?
>
> You're actually telling us that musicians should not bother to use
>  musical notes shorter than an eighth note at tempo mm = 90 because
>  ordinary listeners can't "such  carefully construed rhythmic finesse"?

I'm still baffled. I'm pretty sure you can find no human musicians
that can play notes in a 7919/4451 tuplet accurately, especially if
there is someone or something sitting next to them playing a 7909/4447
tuplet. If there is no human performer, then why are you using
LilyPond, which is a program for printing scores? Are you trying to
print these scores?



> Please.
>
> Broken tuplets offer a genuinely useful musical resource because
>  they provide a way for melodic lines to move out of sync with one
>  another. Since that lack of sync builds up cumulatively over time, it
>  very quickly becomes perceptible to anyone, anywhere, regardless of
>  your musical training -- as in, after a little over 2 minutes, the
>  out-of-sync timing amounts to slightly less than an eighth note.
>
>So let's stop the silly efforts to marginalize or discredit this
>  kind of music, and try to focus on the real issue here: Lilypond's
>  internal integer representation cripples composers who want to use
>  broken tuplets. There are a whole boatload of current composers using
>  broken tuplets -- pop musicians as well  as classical honchos -- and
>  that list includes guys like Frank Zappa, and the music effect is
>  absolutely easily audible to anyone:

Yeah, those poor composers. They write 7909/4407 tuplets, and then who
would think that things break. Maybe the poor composers should try to
use Sibelius or Dorico instead? Also, I've heard you can typeset
tuplets with Finale too.

Good luck.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

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

Allow use of Identity-H CMap and CID versions of Emmentaler (issue 343970043 by knup...@gmail.com)

[knupero]

Reviewers: ,

Message:
Please review.

Description:
Allow use of Identity-H CMap and CID versions of Emmentaler

When -O TeX or -O TeX-GS is given, lilypond generates
postscript code that instructs ghostscript to use the
Identity-H CMap and CID versions of the emmentaler
fonts. Used e.g. by 'make doc'.

Without '-O TeX' or '-O TeX-GS' we still use the
traditional postscript code.

Documentation is missing.

Only a proof of concept, definitely not ready for
release.

Tested only with current lilypond and ghostscript master.

Signed-off-by: Knut Petersen 

Please review this at https://codereview.appspot.com/343970043/

Affected files (+1251, -1880 lines):
  M GNUmakefile.in
  M make/lilypond-book-rules.make
  M mf/GNUmakefile
  M mf/emmentaler-brace.pe.in
  M ps/GNUmakefile
  A ps/cidres.in
  M ps/encodingdefs.ps
  M scm/framework-ps.scm
  M scm/output-ps.scm
  M scripts/build/gen-emmentaler-scripts.py
  M stepmake/stepmake/texinfo-rules.make



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

Re: sort input files (issue 347770043 by bmwiedem...@gmail.com)

[nine . fierce . ballads]

On 2018/05/23 12:22:09, bmwiedemann wrote:

sorting .o files instead of .cc


This is not quite what I meant.  If it works for you, fine, but I think
it is more likely to break eventually than if you found the commands
that are being invoked and sorted their arguments.  For example,

$(CXX) -o $@ $(sort $(O_FILES)) blah blah blah

This puts the sort where it really matters and leaves no room for
modifying O_FILES after the sort.  It would still be a good idea to
include a short comment on the reason for the sort, because It isn't
obvious.


https://codereview.appspot.com/347770043/

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

PATCHES - Countdown for May 26th

[James Lowe]

Hello,

Here is the current patch countdown list. The next countdown will be on May 
29th.

A quick synopsis of all patches currently in the review process can be found 
here:

http://philholmes.net/lilypond/allura/



Push: No patches to push at this time.

Countdown: 

5329 Improve make-bracket-bar-line - Thomas Morley
https://sourceforge.net/p/testlilyissues/issues/5329
http://codereview.appspot.com/339670043

5327 Allow Scheme/identifiers for duration multipliers - David Kastrup
https://sourceforge.net/p/testlilyissues/issues/5327
http://codereview.appspot.com/346810043

5323 sort input files - Bernhard Wiedemann
https://sourceforge.net/p/testlilyissues/issues/5323
http://codereview.appspot.com/347770043


Review: No patches in review at this time.


New: No new patches at this time.


Regards

James


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

Re: Microrhythm

[Hans Åberg]

> On 26 May 2018, at 08:35, metachromatic  wrote:
> 
> ... let's calculate the
> difference in time twixt a tuplet like 7919/4451 against a tuplet
> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
> a tempo of metronome marking 90:
> 
>The difference is (0.00064839149)*60/90 seconds per quarter note =
> 0.00043226099 seconds per quarter note.  But after only 200 quarter
> notes (that is, 50 measures of 4/4, taking only two minutes and 13
> seconds), that difference in timing has grown to ~ 1/11 second. And I
> guarantee you that you can easily hear whether one melodic line is
> offset from another by 1/11 second, since that equates to a difference
> of slightly less than an eighth note at tempo 90.

The human internal tick time is about 1/60 s, so a piece running time t seconds 
need a resolution of 60*t to not let a one tick error grow to that size, and 
then the numerator needs to be 60*t^2. For 64 bits, this is log_2 t about (64 - 
6)/2 = 29 bits, i.e. 2^29 seconds or about 17 years.

For performing musicians, like in the [1-2] example, the variation is much 
greater than 1/60 s even between measures, and the reason is that performers 
know how to sync.  

For video synchronization, one is using shorter times, and there is a proposal 
for about a nano-second "flick" [3].

1. https://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00237.html
2. https://www.youtube.com/watch?v=vYR_pvRWO_g
3. https://en.wikipedia.org/wiki/Flick_(time)



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

Re: Microrhythm

[Hans Åberg]

> On 26 May 2018, at 08:35, metachromatic  wrote:
> 
> ... let's calculate the
> difference in time twixt a tuplet like 7919/4451 against a tuplet
> 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
> a tempo of metronome marking 90:
> 
>   The difference is (0.00064839149)*60/90 seconds per quarter note =
> 0.00043226099 seconds per quarter note.  But after only 200 quarter
> notes (that is, 50 measures of 4/4, taking only two minutes and 13
> seconds), that difference in timing has grown to ~ 1/11 second. And I
> guarantee you that you can easily hear whether one melodic line is
> offset from another by 1/11 second, since that equates to a difference
> of slightly less than an eighth note at tempo 90.

The human internal tick time is about 1/60 s, so a piece running time t seconds 
need a resolution of 60*t to not let a one tick error grow to that size, and 
then the numerator needs to be 60*t^2. For 64 bits, this is log_2 t about (64 - 
6)/2 = 29 bits, i.e. 2^29 seconds or about 17 years.

For performing musicians, like in the [1-2] example, the variation is much 
greater than 1/60 s even between measures, and the reason is that performers 
know how to sync.  

For video synchronization, one is using shorter times, and there is a proposal 
for about a nano-second "flick" [3].

1. https://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00237.html
2. https://www.youtube.com/watch?v=vYR_pvRWO_g
3. https://en.wikipedia.org/wiki/Flick_(time)



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

Re: Rational

[David Kastrup]

metachromatic  writes:

 If you want an answer, ask a question.  Just stating something in the
 hope that the correction will work as an answer is trying your luck.
>
>What's the point of asking a question on this forum?  The answer
> always seems to be: "Go fix it yourself. Dig into the Lilypond code,
> and get busy, and stop bothering us with your bug reports."

Replace "bug reports" with "explanations" and the result is exactly your
approach.

-- 
David Kastrup

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

Re: Microrhythm

[metachromatic]

On 5/25/18, metachromatic  If you really need more resolution for the rational numbers, you could
> try to express rationals as int128 fractions, and see how far that
> brings you. It should be relatively easy to write (this is a typical
> Google interview question), and has no implications for memory
> management.

   That's a good programming suggestion and a very poor overall
 solution to the problem of Lilypond running out of integer headroom.
 Guess I thought it would be obvious why that kind of well-intentioned
but futile suggestion  represents kicking the can down the road rather
than solving the
 problem, but apparently not, so let me try to explain.

   Going to a larger number of bytes to represent ints won't help much
 because each added bit only increases the size of the int by a factor
 of 2. Alas, multiplying primes by one another is a function that
 increases much faster than that. For example: how many notes using
 unique primes numerator and denominator would it take to run out of
 headroom with 128-bit integers?

   2^128 = 3.4028237 * 10^38, while the primorial function (that is,
 the production of the first N primes) for P(40) = 1.6 * 10^68. This
 means that using 20 tuplets with unique prime integers requires a
 Least Common Multiple with at least 68 digits.  That's 30 decimal
 orders of magnitude greater than the numbers you can get with 128 bit
 integers. Maybe now you can see why choosing to represent musical
durations internally in Lilypond with integers is a bad idea.

   Your suggestion implies you don't grasp the issues involved, i.e.,
 the primorial function increases exponentially, while the size of
 integers that can be represented by 2^n increases geometrically, that
 is to say, much more slowly.

> MIDI ticks are 384 to the quarter note, ie. they give you a precision
> roughly equivalent to an int16 fraction. My mind boggles why you write
> "microrhythm" music, only to have it represented in such a "lossy"
> medium as MIDI.

Sorry, that's just provably false. You seem unfamiliar with MIDI
sequencers and MIDI software and hardware. Many MIDI sequencers
implement much a larger number of PPQN (pulses  per quarter note). 960
per quarter note and 1536 per quarter note
 became common in the late 1990s, while more modern sequencers like
 Mark of the Unicorn's Digital Performer, when paired with MOTU's Midi
 Express interface, allows an accuracy of ~ 10,000 pulses per quarter
 note.

> Come to think of it, our hearing goes to 20kHz, so a whole note at a
> typical quarter = 60 tempo has 80,000 oscillations at max. The timing
> of these you could comfortably express in int32 fractions.

> It seems to me that you should not ever convert this microrhythmic
> music to sound so as to not do a disservice to its carefully construed
> rhythmic finesse.

   Now you're getting silly, and you know it. So-called "microrhythm"
 AKA broken tuplets proves easily audibly by anyone. What you're not
 getting here, apparently since you're not a musician, is that tuplets
 which cause multiple simultaneous melodic lines to move out of sync
 with one another do so cumulatively. This means that as a piece of
 music goes on for a few measures, a desynchronization of only a
 fraction of millisecond quickly becomes a densynchronization of
 multiple quarter notes or more.

To see how silly your comment on this issue is, let's calculate the
 difference in time twixt a tuplet like 7919/4451 against a tuplet
 7909/4447 over the course of two minutes and 13 seconds of 4/4 time at
 a tempo of metronome marking 90:

The difference is (0.00064839149)*60/90 seconds per quarter note =
 0.00043226099 seconds per quarter note.  But after only 200 quarter
 notes (that is, 50 measures of 4/4, taking only two minutes and 13
 seconds), that difference in timing has grown to ~ 1/11 second. And I
 guarantee you that you can easily hear whether one melodic line is
 offset from another by 1/11 second, since that equates to a difference
 of slightly less than an eighth note at tempo 90.

Now, come on, Han-Wen...are you _really_ telling me the average
 listener can't hear the duration of an eighth note a tempo mm = 90?
 Seriously?

You're actually telling us that musicians should not bother to use
 musical notes shorter than an eighth note at tempo mm = 90 because
 ordinary listeners can't "such  carefully construed rhythmic finesse"?

Please.

Broken tuplets offer a genuinely useful musical resource because
 they provide a way for melodic lines to move out of sync with one
 another. Since that lack of sync builds up cumulatively over time, it
 very quickly becomes perceptible to anyone, anywhere, regardless of
 your musical training -- as in, after a little over 2 minutes, the
 out-of-sync timing amounts to slightly less than an eighth note.

   So let's stop the silly efforts to marginalize or discredit this
 kind of music, and try to focus on the real issue here: 

Re: Rational

[metachromatic]

>>> If you want an answer, ask a question.  Just stating something in the
>>> hope that the correction will work as an answer is trying your luck.

   What's the point of asking a question on this forum?  The answer
always seems to be: "Go fix it yourself. Dig into the Lilypond code,
and get busy, and stop bothering us with your bug reports."

   So, seriously...what's the point of this forum at all?

   When a user who reports a problem gets told "Fix it yourself," what
purpose does this forum serve?

   Why not just replace the entire forum with a GIF that says FIX
YOURSELF, LOSER, LOL!

   Boy, programmers...what a group.

   Imagine this philosophy applied to society at large.

   "Hello, city hall? The bridge is falling down--"
   "Fix it yourself, loser, LOL!"

   "Hello, CDC, I'd like to report an outbreak of ebola at--"
   "Fix it yourself, loser, LOL!"

   "Hi, is this the fire department?  I want to report a fire at--"
   "That's not a bug, that's a feature!  If you don't like it, go put
it out yourself. Pathetic."
-
--mclaren

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