lilypond-devel
[Top][All Lists]
Advanced

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

Re: Microrhythm


From: metachromatic
Subject: Re: Microrhythm
Date: Fri, 25 May 2018 23:35:49 -0700

On 5/25/18, metachromatic <address@hidden wrote:
> 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: 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:


 
http://klangnewmusic.weebly.com/direct-sound/lets-talk-rhythm-part-2-nested-tuplets

   https://www.youtube.com/watch?v=Tym-4V2Hc3k


 
https://www.reddit.com/r/musictheory/comments/2flp2f/what_are_some_good_songspieces_which_include/

   http://micrologus.retmusic.com/tag/nested-tuplet/


 
https://www.artsjournal.com/postclassic/2006/01/totalism_as_a_new_rhythmic_par.html

   Here's another musical example. This stuff is easy to hear and quite
 striking musically:
 https://www.youtube.com/watch?v=0G9RvIXrRZo
 --------------
 --mclaren



reply via email to

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