Re: Contemporary notation (Re: GSoC projects list)

[Jeffery Shivers]

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 <address@hidden> 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
>>
>>
>> --
>> address@hidden
>> https://openlilylib.org
>> http://lilypondblog.org
>
> --
> address@hidden
> https://openlilylib.org
> http://lilypondblog.org
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel



-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers