Sorry, I responded to David before reading your response, but I see that we kind of said the same things.
> 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". Yes, certainly. And if the project isn't initiated this year, we always have the option of proceeding with discussions / work anyway. This is a project I'd for sure like to see happen. I've recently just had to switch to making my scores entirely in java since it is such a headache to create/edit multi-page projects in inkscape and things are still a stretch with lilypond oftentimes. On Mon, Feb 6, 2017 at 10:51 AM, Jeffery Shivers <jefferyshiv...@gmail.com> wrote: >> 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 > > > > -- > > Jeffery Shivers > jefferyshivers.com > soundcloud.com/jefferyshivers -- Jeffery Shivers jefferyshivers.com soundcloud.com/jefferyshivers _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
