Michael Welsh Duggan <[EMAIL PROTECTED]> writes: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED] writes: >>> Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: >>> > * Then I add simple constructions, such as stress on the 1st note of a >>> > slur/1st note of a bar. I should do some reading up on what are the >>> > most important facets of getting a credible performance. >>> >>> Okay. I'll make a first pass at Snobs, then. Shouldn't be too hard, >>> and not all that different from what I was doing in the first place. >>> I'll start by stealing the property code from Grobs, then add the >>> other functionality when it turns out that I need it. My goal is to >>> start simple, and only add complexity when necessary. >> >> OK. My original plan was for the snobs to also have a parent like >> structure like grobs, perhaps with callbacks. Each snob has a parent >> determining the timing. So, when you create an Arpeggio, all notes >> have their parent set to the Arpeggio, and to determine the onset of >> the note, the callback for the Arpeggio is executed, which shifts >> different notes in the chord. >> >> Don't know if its a good idea, though. > > No, that sounds similar to some ideas I had. The major bit I am > unsure about is if the heavyweight event interface is necessary.
In order to reuse as much grob code as possible, I have been seperating out things which are common between Grobs and Snobs into a base object (Probs - property objects). The first major hurdle I have hit is that of interfaces. I am having difficulty deciding whether interfaces should be the domain of grobs only, whether there should be a seperate set for snobs, or whether a single unified set should suffice for both. Would you have any insights into this question? -- Michael Welsh Duggan ([EMAIL PROTECTED]) _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
