Hi, There is a bunch of fairly independent next steps for me. I'd like to start with 3, because it's the biggest one, so I can work on 1+2 whenever 3 stalls.
1. Interface for exporting/importing music streams: - refactor global-context-scheme: separate run-translator into three separate functions: 1 ly:make-global-context: initialise and create empty Global_context 2 ly:make-global-translator: create translators for an empty Global_context 3 ly:interpret-music-expression: iterate music in a global context. - write Scheme replacements for 2 and 3, which exports / imports streams - find a good way for a user to export/import streams? 2. Try to completely separate translators and iterators from contexts: - retrieve get_output from the global translator_group instead of global_context. Kill the Score_context class. - make translators keep their own child/parent lists. I think this will make context::implementation_ unused & junkable, so translators will be separated from contexts. - create separate class Iterator_outlet, which contains the Context methods and members that are specific to music iteration. 3. Make translators listen to stream events, and make MusicEvent stream-events contain properties directly. Furthermore, represent all events as stream events rather than music from the beginning. I think this will take some time. - Change StreamEvent to a prob, where the event-class is the only immutable property. - Rename MusicEvent to OldMusicEvent. Change Music::send_to_context to copy all properties to an event of the new type MusicEvent which it sends along with the OldMusicEvent. I.e., send two separate events, one OldMusicEvent with Music embedded, and one MusicEvent with properties set directly. - Create a listener system for translators. Each translator should register try-music equivalents to events-below listeners using some macro. - Replace one try-music at a time into a set of listeners (huge job). - make Music send only MusicEvents. - it should be safe to remove the translator group's code for calling try_musics - Change EventChord iterator to use 'events iso 'elements, which initially is a mixed list of music and stream events. - it's now possible to change all MY_MAKE_MUSICs into stream event creations, one by one. - rename music-class 'event to 'bottom-event? (event that is sent to bottom context, possibly implicitly created) - make type-checking work for stream-event properties. I think I'll use define-music-properties.scm directly at first, and perhaps split into separate lists for music and events later if that looks sensible. - perhaps introduce event-function, which maps event to event (as in c-\tag #'foo -. ) 4. Delay the evaluation of syntax-expressions, and softcode relative as a macro. I'd prefer to wait with this until after 3, for typechecking reasons (it would feel good to settle the distinction between stream-events and music first). There are basically two ways to evaluate syntax-expressions: - Evaluate the expression directly. This can actually be implemented more robustly than it first sounds: If all syntax constructors are created with define-ly-syntax, then we can create typechecking/error-detecting wrappers around each user-defined function. - The parser can evaluate the expression manually, by traversing it and recursively calling all functions. A related question is whether music macros should return syntax expressions or music expressions / stream events, and another question is how to handle syntax expressions for event-functions. I'll look into those problems when I'm a bit closer. -- Erik _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
