> 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 <u...@openlilylib.org> 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 <u...@openlilylib.org> 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 <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 >> >> > > -- > 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 -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
