Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: >> >>> 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? > > I'd refrain from trying to be too generic when it's not clear that you > will need it. Don't put in interfaces, and once you really need them, > let them bubble up from the Grob class.
Sounds good. So for the meantime, I am running without interfaces. I do have one more question. I am also running without Object_keys for now, as I have not yet been able to determine for what purpose they are used. Is there a good reason to include these? -- Michael Welsh Duggan ([EMAIL PROTECTED]) _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
