Re: Imposing Swing Upon notes (Specification)

[Marc Hohl]

Dean Radcliffe schrieb:
> I added the following to 
> http://code.google.com/p/lilypond/issues/detail?id=687
>
> I think this is a way to think about - could anyone suggest to a 
> novice schemer how this might be done ??
Hello Dean,

I thought about this issue some time ago. There is a file articulate.ly 
from Peter Chubb, and I thought
about extending this to include swing. I worked on the mathematics 
behind this stuff, but it seems
that it is not easy or even not possible to get the position within a 
bar (say, beat 1 or 2 + ...) while
parsing (and this is the stage when articulate.ly joins in).
> There is a quantity called "Global Groove Amount", and a setting that 
> controls whether it applies to syncopated eigths or syncopated 
> sixteenths. It is a number, from 0 to 100 (but most useful at and 
> around 33), which - for the eighth note example - is ignored on 
> quarter note beats, but for those syncopated eigth notes, displaces 
> them later in time by the proportion of 100 specified. Example: 
> assuming 100 divisions per quarter note, the syncopated eigth-note 
> falls on 50 without swing, but with 33 groove factor, the number 50 is 
> increased 33%, and so becomes 66. Notes that are neither exact eigth 
> notes (which have full groove factor applied), or exact quarter notes 
> (which are unaffected by groove factor in eigth-note mode, much like 
> eigth-notes are unaffected in 'swing 16th' mode) can either be left 
> unaffected, or proportionally affected, dependent on a configuration 
> override (the default should be to leave them unaffected).
>
> This would not require lookahead, or collision avoidance, just the 
> ability to determine whether a given musical event is a downbeat per 
> that swing-mode, and the ability to alter the displacement of the note 
> by the product of the groove factor and a number that indicates how 
> off-the-beat the note is already. The visual representation of the 
> note should not be altered, nor other elements moved around, this only 
> need take effect on all audible events in midi output. This feature is 
> basically the rhythmic equivalent of transposition- music written one 
> way, and played another.. but instead of translating in the pitch 
> domain, we are scaling in the time domain, modulo the distance from 
> certain interval boundaries. I would actually suggest calling this a 
> Swing_Performer, available only for midi layouts (I'm not sure i have 
> my terminology right here, but that's the idea, in the same way you 
> can add and remove Dynamics_Performer for midi output)
Yes, this stuff has to go into some Performer, but I don't think that 
Performers can be coded in scheme,
so it has to be done in c++.

Just my 2ct...

Marc
> ------------------------------------------------------------------------
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>