Reinhold Kainhofer <[email protected]> writes: > Am 2011-11-15 10:49, schrieb David Kastrup: >> The "principle of lazy complication" would keep material as simple as >> feasible until a more complicated version is asked for. >> >> That is, when a music function asks for a "scheme?" argument and the >> input is just c', it gets a pitch. If it asks for a "ly:music?" event, >> it gets a NoteEvent (not an EventChord). If it asks for an EventChord, >> it gets one. >> [...] >> >> All in all, such a change should make programming and inspecting data >> structures much more straightforward, and particularly save the >> programmer from the "let's see what complex structures Lilypond creates >> from simple input and devise a scheme how to get at the simple things we >> actually wanted" phenomenon. >> >> But it is definitely not going to be an upwards-compatible change. > > What will be different for a normal user? I.e. What basic lilypond > notation will change?
You won't have to create an artifical chord in order to put string numbers to notes or be able to tweak single notes. Things like fingerings and postevents applied to single notes will end up as articulations rather than simultaneous events (which is what happens when applied to chords). It's conceivable that one will need to check the music type system and provide a way to declare postevents that should not end up as articulations on individual notes ever. In short: I expect things to get a bit more streamlined at the input side. > And what advanced notation will break with that change? I don't think notation will be affected, but the programming model changes, and so music functions may need to get rewritten. In most cases, it should work to just replace their argument predicates with more specific ones. This can't be done automatically since some music functions are intended to also work inside of chord notation and/or apply tweaks, and consequently should _not_ get their arguments converted to EventChord automatically. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
