I completely agree that modularity is a great way to go - I think that woodwinds could be re-integrated into lilypond this way, as could fretboard diagrams and other similar features.
For me, the three very beneficial aspects of C++ are its ability to work with data structures that retain information, the robust libraries that exist, and its speed. Waveforms uses all three, which is why I chose to do it in C++. But I think that, if the way lilypond interacts with Scheme were worked on a bit (ie scheme being able to query c++ classes that stored status variables), almost all of the engravers could be turned into modules. But like Carl said, something of that size would take a bit of time - I for one would be willing to work on it. And in this case, like Han-Wen said, C++ could be reserved for situations where its lack would be a huge time drain (ie when libraries are important). ~Mike On 7/2/10 8:31 PM, "Carl Sorensen" <c_soren...@byu.edu> wrote: > On 7/2/10 12:03 PM, "Graham Percival" <gra...@percival-music.ca> wrote: > >> On Fri, Jul 02, 2010 at 06:12:03PM +0200, David Kastrup wrote: >>> Graham Percival <gra...@percival-music.ca> writes: >>> >>>>> It seems nice to be able to add this sort of thing to Lilypond, but I >>>>> think it rather strongly demonstrates Lilypond's lack of modularity: >>>>> this sort of thing should sit in a separate directory and be loaded >>>>> on-demand under user control without needing any resident code parts >>>>> when people don't use it. >>>> >>>> If it was all done in scheme, this would be easy. :) >>> >>> I don't think so, since properties and contexts are defined and >>> initialized globally right now, and we don't have a system for >>> modularizing documentation. >> >> Can't new contexts be defined by the user? I'll admit that I >> don't think they can create new properties... >> >> I was basically just thinking of things like ancient notation, or >> the beautiful "packages" / "files" / "modules" / "whatever we >> shoudl call them" that Reinhold and Nicholas put together, like >> stuff for title pages or orchestralily. As a naive ex-user, I'd >> call those "modules", but that might be misusing a technical term. > > > Although I'm not going to work on this right now (got to get the autobeaming > stuff done first!), it seems like we ought to be able to define something > that works kind of like \usepackage. > > Properties are defined in Scheme, and hence, could be added to from scheme, > at least as far as I can see without trying it myself. > > New contexts can certainly be defined in .ly files. > > Interfaces are defined in scheme, and thus should be modifiable. > > Music types are defined in scheme. > > We now have the capability of defining engravers in Scheme. > > We may be missing iterators and performers, I guess. > > Documentation is *not* currently modular (as David has expressed before). > It would be cool to have some kind of a master documentation runner that > could be called on a module, and would know how to get the appropriate > .itely file and turn it into a little documentation file for the feature. > > I really like David's thoughts about how it would be cool to have LilyPond > be modular like TeX/LaTeX. But that's certainly postponed to after 2.14 as > far as I'm concerned. > > Thanks, > > Carl > > > Thanks, > > Carl > > > >> >> Cheers, >> - Graham >> >> _______________________________________________ >> lilypond-devel mailing list >> lilypond-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/lilypond-devel > > > _______________________________________________ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
