On Tue, Jun 3, 2008 at 10:09 AM, Myron Marston <[EMAIL PROTECTED]> wrote:
> I'm working on an application that generates music. I'd like to use > Lilypond to > generate my scores, but I'm having difficulty figuring out the best way to > produce the proper lilypond notation for the durations of the notes. > Internally, all of my rhythmic durations are represented as fractions (i.e. > 1/4 > for a quarter note, 3/8 for a dotted quarter, 1/6 for one note of a quarter > note > triplet, etc). As long as my durations have a power of 2 in the > denominator, > it's not difficult to figure out the correct lilypond notation. But > tuplets are > much more difficult, especially when you get into nested tuplets, tuplets > that > mix durations (i.e. 8ths and 16ths in the same tuplet), etc. > > Does anyone know of an algorithm to convert from fractional representations > of > durations to the lilypond > format?<http://lists.gnu.org/mailman/listinfo/lilypond-user> Hi Myron, The "duration mapping" question you're pointing to is, in my opinion, one of *the key* questions in the formalized generation of notation. Warning: personal opinion follows! Short answer: there is no general algorithm to handle the numeric-to-rhythmic mapping. Why? Because, although the rhythmic-to-numeric mapping of some bit of rhythmic notation into a list of floats or rationals is one-to-one, the numeric-to-rhythmic mapping of a flat list of numeric values to rhythmic notation is one-to-(infinitely)-many. We can consider the list [1/12, 1/8, 1/8, 1/12, 1/12, 1/12] as an example. Do we notate as a 'broken' triplet into which we've inserted to consecutive eighth notes? Or maybe a measure of 1/12, followed by a measure of 2/8, followed by a measure of 2/12? Maybe a tuplet of depth 1 as \times 2/3 { c'8 c'8. c'8. c'8 c'8 c'8 }? Or maybe a nested tuplet of depth 2 to 'undo' the inner prolation as \times 2/3 { c'8 \times 3/2 { c'8 c'8 } c'8 c'8 }? Any useful numeric-to-rhythmic mapping algorithm will need to pick among the best of these options ... but what counts as 'best' will likely need reference to ... 1. metric context ... or ... 2. compositional process of derivation ... of both, which are absent from a simplified representation as a numeric list of values. Pulling nested structure from a flat list is hard ... without reference to some other set of structures to guide the fitting process. Solution: if you want to generate the trees and branches of conventional rhythmic notation then generate the trees and branches of conventional rhythmic notation directly. Model dots, brackets, ties and the effects of time signature denominators as some data structure directly and do composerly things to that. One published example is the RTree implementation in OpenMusic. Modelling rhythmic time as a flat list of floats or rationals shows up all over everywhere in the literature on computer-assisted and algorithmic composition. But it's a trade-off: the simplicity of a flat-list representation of rhythmic time guarantees ambiguity for transcription into western rhythmic notation in precisely the same way that an unambigous model of western rhythmic notation guarantees more complex data. So there's one quite personal opinion on rhythmic modelling: if you want exact rhythmic notation, generate it directly rather than searching for a way to apply nested structure to a flat list after the fact. A final note. If you're willing to round some or all of your numeric values, then there's a huge literature on quantization available; maybe one of the best is an article by Paul Nauert in Perspectives of new music based on a posited notion of performance difficulty: Nauert, P. (1994). A theory of complexity to constrain the approximation of arbitrary sequences of timepoints. Perspectives of New Music, 32(2):226–263. Though when it comes to quantization I've never been able to shake the following, nagging question: if you need to quantize at the end of the generative process ... then what do the intervening steps of your rhythmic transformation actually *mean*? Trevor. -- Trevor Bača [EMAIL PROTECTED]
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
