Re: Contemporary notation (Re: GSoC projects list)

[Jeffery Shivers]

> 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.

Seconded

On Mon, Feb 6, 2017 at 12:13 PM, Urs Liska <address@hidden> wrote:
> 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
>
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel



-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers