Re: Contemporary notation (Re: GSoC projects list)

[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



-- 

Jeffery Shivers
 jefferyshivers.com
 soundcloud.com/jefferyshivers