I've thought about this a lot, and I agree that OLL would be the obvious means to implement a *contemporary notation* package with LilyPond.
A huge problem we will face with doing this, which will always be a problem no matter how accessible/robust the library, is that there will very often be some unexpected (and probably illogical) way that a composer wants to notate their music. So if our software doesn't support what they want, or they have to really *stretch* it to accomplish their needs, it makes sense for them to turn to something like inkscape for faster and more straightforward results, even though that process won't carry all the benefits/flexibility of engraving with a tool like LilyPond (for example, increasing the horizontal spacing between everything in a multi-page score on a big ole inkscape document is a much bigger deal than it is in LilyPond). This is all to say, "contemporary notation" encapsulates so many possibilities, it'll be a tricky and probably exhausting process to figure out the best way to make its use available to as many users as possible. Not saying that to be discouraging, just realistic. > LilyPond's programmability and especially the provision to make enhanced > features available through (more or less) easy-to-use commands is one of > the major features I've been lobbying with over the recent years. And > with regard to contemporary notation this feature outweighs (IMO) the > fact that creating non-standard notation is more complicated than by > using arbitrary drawing tools. Yes, my comment above pretty much echoes that. > What I'm thinking of is not a flat collection of notation elements but rather > a hierarchy of > building blocks that can be used to easily build concrete notation elements. Yes - any thoughts on what the building blocks are yet? This could - and should - be an extensive discussion for sure. On Mon, Feb 6, 2017 at 3:15 AM, Urs Liska <u...@openlilylib.org> wrote: > One thing I'm missing about our projects list is actual *notation* > projects. Currently (i.e. when the current wave of purges has been > completed) there is no project that adds to or improves LilyPond's > notation. All projects are important items, but maybe this isn't really > attractive to students. > > I have one suggestion for which I could be a mentor, but I would really > prefer to act as *secondary* advisor only, with someone else being the > primary mentor: creating a library for contemporary notation. Obviously > it would be an openLilyLib project again, and I'm not feeling 100% > comfortable with that, but I'm sure it would be attractive for potential > students, and it would also add some prominently visible new features to > LilyPond. > > LilyPond's programmability and especially the provision to make enhanced > features available through (more or less) easy-to-use commands is one of > the major features I've been lobbying with over the recent years. And > with regard to contemporary notation this feature outweighs (IMO) the > fact that creating non-standard notation is more complicated than by > using arbitrary drawing tools. > > openLilyLib is a suitable framework to build such a contemporary > notation package and making it easily accessible. What I'm thinking of > is not a flat collection of notation elements but rather a hierarchy of > building blocks that can be used to easily build concrete notation elements. > > Feedback for that? Any of the more proficient composers out there > willing to join? > > Urs > > Am 06.02.2017 um 00:24 schrieb Urs Liska: >> >> Hi all, >> >> I'm somewhat worried about LilyPond's GSoC project proposals list. >> Right now I'm purging the web page >> (http://lilypond.org/google-summer-of-code.html) from projects without >> mentors, and I have the feeling when this process is completed we're >> left with an unsatisfactory state. >> >> From the 9 projects that are listed at the time of writing this post >> four are right now scheduled for removal: >> >> * Grace notes >> * Improving default beam positioning >> * Improving compilation behaviour >> * Improve Slurs and Ties >> >> A fifth project, MusicXML export, is still unclear. >> >> So essentially per now we will have only 4/5 projects left: >> >> * Improving internal chord structure >> * Adopting SMuFL >> * Adding glyph variants >> * openLilyLib testing and documentation >> >> I find this list quite disappointing, and I'm afraid it won't be >> terribly attractive to potential students. So I strongly encourage >> anybody to suggest further projects, preferably together with a pledge >> to mentor them. >> >> Best >> Urs >> >> >> -- >> u...@openlilylib.org >> https://openlilylib.org >> http://lilypondblog.org > > -- > u...@openlilylib.org > https://openlilylib.org > http://lilypondblog.org > > _______________________________________________ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
