Re: Contemporary notation (Re: GSoC projects list)

[Urs Liska]

OK, I think we have to take care that the discussion doesn't get out of
hand now but stays closely on topic (the GSoC project).

It is clear that *comprehensive* coverage of "contemporary notation" is
not a goal that LilyPond should or can aim at, at least for now.

What we *can* aim at is a foundation toolkit, basically as Jeffery
describes below, a framework where composers can build upon and create
their individual notation, but with a (more or less) common syntax,
which will make it easier to reuse code created by others. What I would
suggest a GSoC project should produce in addition is *one* coherent set
of notation features, like (just wild guesses) "Lachenmann style string
notation" or "a comprehensive set of weirdly drawn line spanners" or
"just intonation" or whatever - I would leave that as open as possible
in order not to discourage any potential student who just isn't
interested in a given notation type.

Urs

Am 06.02.2017 um 16:51 schrieb Jeffery Shivers:
>> Man, that sounds to me like making explosives available to as many users
>> as possible.  I mean, I recognize that there is a need apparently to be
>> served, but this rather sounds like a call to expanding that need.
> Hm, no. There is an absurd amount of weird *needs* from composers
> nowadays who aren't working with (any semblance of) conventional
> western notation or even whatever people other than them (the
> individual) might think "contemporary notation" is. My point: what is
> useful to most / in general is what should be prioritized (surely you
> would agree...), and since "contemporary notation" is really a vast
> abyss of possibilities (composers are inventing unique, radical
> notations for use in only single projects), there is no point in
> trying to create a starting point as defined as, say, LilyPond itself.
>
> LilyPond is based on a relatively narrow, rigid perspective of how
> music works and is (ahem, "should be") notated; this is completely
> valid and works in its/our favor because *most people agree on that as
> a starting point*. A contemporary notation library, however, should
> not be so specific right out of the gate. The library needs to be
> designed *to be extended* out of the box, with the implication that
> people build their own specific tools using the more versatile tools
> the library provides, and of course those *specific tools* can be
> contributed though a kind of package manager if one ever exists, or
> whatever other means. We may find that there are certain specific
> things that we didn't expect most people to need but they, in fact, do
> and thus we add those things to the core contemporary notation
> library, but it's just silly and ignorant to assume those things until
> we get there.
>
> But what do I know - I'm only a contemporary composer. :-)
>
> On Mon, Feb 6, 2017 at 10:03 AM, Urs Liska <address@hidden> wrote:
>>
>> 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 <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
>>
>>
>>
>> --
>> address@hidden
>> https://openlilylib.org
>> http://lilypondblog.org
>
>

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org