Am 06.02.2017 um 15:10 schrieb 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.
Your considerations are reasonable, but I wouldn't see it that much as a
problem. It's not that we need to create a tool that is as comprehensive
as, say, LilyPond itself with regard to common notation. What I think
would be useful (and sufficient in the currently discussed context) is a
tool/package/infrastructure that
* proves that non-standard notation can be made availalbe through
convenient and flexible (parametrical) commands,
* provides tools to make it easy to build upon, that is to a) create
additional libraries for specific purposes and b) to create custom
commands for "local"use
>
>> 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.
Yes, exactly. And what I have in mind would simply put some weight on
one side of the scale to make it easier to achieve stuff and to make it
more obvious how cool it can be.
>
>> 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.
Thoughts, yet, but not too thought-through yet. A category of tools
could for example be an interface/infrastructure to create notation that
behaves like a glissando, i.e. any drawn connection between two notes.
Or an infrastructure to add categorized playing technique "ornaments",
be it through path drawing, inclusion of images or accessing glyphs from
specialized fonts.
Indeed this should be discussed thoroughly before actually investing
substantial energy in implementation. But for now I'd defer this to a
moment if there should be a student interested in the project. This
discussion would be a very interesting topic for getting familiar with
the student, and a good exercise for the "bonding period".
Best
Urs
>
> 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
>
>
--
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
