Re: Revised version of waveform renderer on Rietveld that uses glpk

[Mike Solomon]

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" <address@hidden> wrote:

> On 7/2/10 12:03 PM, "Graham Percival" <address@hidden> wrote:
> 
>> On Fri, Jul 02, 2010 at 06:12:03PM +0200, David Kastrup wrote:
>>> Graham Percival <address@hidden> 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
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 
> 
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
>