Re: GSoC projects list
>>Here's another one: >> >> . Make lilypond support automatic line breaks for piano four hands >>scores. > > Nice one. > >> >>However, this must be tagged as `difficult'. >> > > What's the requirement - C++? This, and Scheme, I guess. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
Am 10. Februar 2017 06:43:55 MEZ schrieb Werner LEMBERG : > >> Some ideas, without being able to mentor them. [...] > >Here's another one: > > . Make lilypond support automatic line breaks for piano four hands >scores. Nice one. > >However, this must be tagged as `difficult'. > What's the requirement - C++? Urs > > Werner -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
> Some ideas, without being able to mentor them. [...] Here's another one: . Make lilypond support automatic line breaks for piano four hands scores. However, this must be tagged as `difficult'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
. Developing and implementing an OpenType Scheme API. >>> Do you mean a way to access the extended font features from >>> LilyPond, so I can get real caps or swash alternates etc.? >> Yes. > > Would it be in line with that project to also add some typesetting > capabilities, at least hyphenation for multiline markup? No. Automatic hyphenation based on hyphenation patterns is a completely different problem. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
Am 06.02.2017 um 09:24 schrieb Werner LEMBERG: >>> . Developing and implementing an OpenType Scheme API. >> Do you mean a way to access the extended font features from >> LilyPond, so I can get real caps or swash alternates etc.? > Yes. > Would it be in line with that project to also add some typesetting capabilities, at least hyphenation for multiline markup? Urs -- 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
Re: Contemporary notation (Re: GSoC projects list)
Am 06.02.2017 um 20:15 schrieb "Jürgen Reuter": > Hi all, > > personally, I think, it is as always in software development that > addresses a wide audience: the challenge to find an appropriate level > of abstraction. > If you want to support *any* kind of notation, then just use a > painting or CAD software. Obviously, you do not want to do that, > because you will loose any musical semantics, including the > possibility of reformatting, transposing, or whatever else > musicologically editing you would like to apply. Definitely. One strong point for LilyPond is the ability to encode stuff with semantic meaning, and have the result behave like a regular score element that adjusts automatically. > > On the other extreme, you would focus on a specialized notation system > that addresses a selected audience only and is of little or no value > for other users. > > A common approach is solve this dilemma is to: > > * (1) Focus on a selected set of specialized features that you expect > to be useful for many users. Then you can add specialized > automation. For example, the abstraction of having objects called > "notes" that have a particular property called "pitch" enables you to > group a selection of notes into a "music expression" and "transpose" > the whole expression by altering the pitch of each note in that group. > > * (2) For exceptional cases, provide more lower-level features, that > provide less automation due to an increasing lack of musical > semantics, but are more flexible. For example, LilyPonds feature to > embed postscript snippets is extremely flexible. But it is just > graphics, without any musicological sementics. And as such, you can > not impose any musical operation on it. Yes, this goes in the direction of what I meant with "building blocks". Today I found a good example of such low-level functionality that might make it easier to build upon and create higher-level functionality upon: One of the things I'm currently investigating is a special form of slurs, for which I overwrite the stencil and create a shape from scratch. From the grob that is passed to that callback function it is possible to get hold of all sorts of information like its properties or the attached note columns, the objects in the note columns, grob-objects like stems or flags and many others. But it would make creating such stencil overrides much easier if one wouldn't have to always look again for the ways how to retrieve the necessary information and could instead use a function like, say, #(define myStencil (define-slur-stencil (do-something-with (fourth cps)) ... )) where all relevant information such as control points, bounding note columns, attached note heads or extremal note heads when it's chords, and potentially more were simply available. > > Having this approach in mind, I implemented the cluster engraver > roughly 15 years ago. Urs, you mentioned creating "notation that > behaves like a glissando, i.e. any drawn connection between two > notes." With the cluster engraver, you (sort of) can do such a > thing. The idea was to provide graphical notation that builds upon > musical expressions by transforming that musical information into a > corresponding graphical shape. This way, the cluster engraver fills > the gap between non-graphical (and therefore specialized) standard > notation on the one hand and generic, but non-musical low-level > graphics on the other. Maybe the cluster engraver would be a proper > starting point for more music expression based graphical notation? This should be noted. I think independently from this GSoC idea I'll create a dummy package https://github.com/openlilylib/contemporary (not online yet, but as this message will go into the archives ...) with a brainstorming Wiki page. > > Another thing, I guess, is making it easy for musicians without > programming knowledge to smoothly embed their own articulation signs, > note heads, clefs, and other font symbols into LilyPond at runtime: > Just define a new articulation sign or note head shape or clef at the > top of your .ly file with a single short line of scheme code that > references some, say, .eps file. I think, this is still not that > easily possible, right? (Please correct me, if I am wrong.) As replied in another post this is exactly the kind of simplification I have in mind. > > Personally, I am even not sure of how to properly notate contemporary > music. Yes, I have seen e.g. excerpts of Stockhausen's score of his > Studie II, and Wehinger's aural score of Ligeti's Artikulation, as > well as a score of Kagel. (LilyPond's short, long and very long > fermata signs were actually inspired by this score of Kagel.) Still, I > am not satisfied with such notation: At least to my perception, it > typically does not represent well essential nuances of e.g. electronic > sounds. Well, there's an abundance of notation today, and - as Jeffery has pointed out - it would be overwhel
Re: Contemporary notation (Re: GSoC projects list)
Am 6. Februar 2017 20:34:36 MEZ schrieb Simon Albrecht : >On 06.02.2017 20:15, "Jürgen Reuter" wrote: >> Another thing, I guess, is making it easy for musicians without >> programming knowledge to smoothly embed their own articulation signs, >> note heads, clefs, and other font symbols into LilyPond at runtime: >> Just define a new articulation sign or note head shape or clef at the >> top of your .ly file with a single short line of scheme code that >> references some, say, .eps file. I think this is still not that >> easily possible, right? (Please correct me, if I am wrong.) > >Sounds good. Yes, this is the kind of stuff I had in mind, among others. > >> Personally, I am even not sure of how to properly notate contemporary >> music. Yes, I have seen e.g. excerpts of Stockhausen's score of his >> Studie II, and Wehinger's aural score of Ligeti's Artikulation, as >well >> as a score of Kagel. (LilyPond's short, long and very long fermata >> signs were actually inspired by this score of Kagel.) Still, I am not >> satisfied with such notation: At least to my perception, it typically >> does not represent well essential nuances of e.g. electronic sounds. > >I think we should make as few such decisions as possible and rather >stick with such notation as is already widely recognised as >quasi-standard, e.g. following Kurt Stone, Music Notation in the >Twentieth Century (Norton, New York 1980). > >Best, Simon I think *if* there should be an application it will be by someone who has actual needs, not someone with the big picture in mind. And this ud basically a good thing because it provides the necessary enthusiasm. So we should keep the proposal as open as reasonably possible and see the mentor's and the community's duty as one of taking care of the abstract value of the development. Urs (I'll reply to Jürgen's post when I'm back at a proper keyboard) > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contemporary notation (Re: GSoC projects list)
On 06.02.2017 20:15, "Jürgen Reuter" wrote: Another thing, I guess, is making it easy for musicians without programming knowledge to smoothly embed their own articulation signs, note heads, clefs, and other font symbols into LilyPond at runtime: Just define a new articulation sign or note head shape or clef at the top of your .ly file with a single short line of scheme code that references some, say, .eps file. I think this is still not that easily possible, right? (Please correct me, if I am wrong.) Sounds good. Personally, I am even not sure of how to properly notate contemporary music. Yes, I have seen e.g. excerpts of Stockhausen's score of his Studie II, and Wehinger's aural score of Ligeti's Artikulation, as well as a score of Kagel. (LilyPond's short, long and very long fermata signs were actually inspired by this score of Kagel.) Still, I am not satisfied with such notation: At least to my perception, it typically does not represent well essential nuances of e.g. electronic sounds. I think we should make as few such decisions as possible and rather stick with such notation as is already widely recognised as quasi-standard, e.g. following Kurt Stone, Music Notation in the Twentieth Century (Norton, New York 1980). Best, Simon ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contemporary notation (Re: GSoC projects list)
Hi all, personally, I think, it is as always in software development that addresses a wide audience: the challenge to find an appropriate level of abstraction. If you want to support *any* kind of notation, then just use a painting or CAD software. Obviously, you do not want to do that, because you will loose any musical semantics, including the possibility of reformatting, transposing, or whatever else musicologically editing you would like to apply. On the other extreme, you would focus on a specialized notation system that addresses a selected audience only and is of little or no value for other users. A common approach is solve this dilemma is to: * (1) Focus on a selected set of specialized features that you expect to be useful for many users. Then you can add specialized automation. For example, the abstraction of having objects called "notes" that have a particular property called "pitch" enables you to group a selection of notes into a "music expression" and "transpose" the whole expression by altering the pitch of each note in that group. * (2) For exceptional cases, provide more lower-level features, that provide less automation due to an increasing lack of musical semantics, but are more flexible. For example, LilyPonds feature to embed postscript snippets is extremely flexible. But it is just graphics, without any musicological sementics. And as such, you can not impose any musical operation on it. Having this approach in mind, I implemented the cluster engraver roughly 15 years ago. Urs, you mentioned creating "notation that behaves like a glissando, i.e. any drawn connection between two notes." With the cluster engraver, you (sort of) can do such a thing. The idea was to provide graphical notation that builds upon musical expressions by transforming that musical information into a corresponding graphical shape. This way, the cluster engraver fills the gap between non-graphical (and therefore specialized) standard notation on the one hand and generic, but non-musical low-level graphics on the other. Maybe the cluster engraver would be a proper starting point for more music expression based graphical notation? Another thing, I guess, is making it easy for musicians without programming knowledge to smoothly embed their own articulation signs, note heads, clefs, and other font symbols into LilyPond at runtime: Just define a new articulation sign or note head shape or clef at the top of your .ly file with a single short line of scheme code that references some, say, .eps file. I think, this is still not that easily possible, right? (Please correct me, if I am wrong.) Personally, I am even not sure of how to properly notate contemporary music. Yes, I have seen e.g. excerpts of Stockhausen's score of his Studie II, and Wehinger's aural score of Ligeti's Artikulation, as well as a score of Kagel. (LilyPond's short, long and very long fermata signs were actually inspired by this score of Kagel.) Still, I am not satisfied with such notation: At least to my perception, it typically does not represent well essential nuances of e.g. electronic sounds. Probably most important, I think you first of all need lots of examples to get a sense for what might classify as candidate for an appropriate abstraction: Is it all about graphical notation? Or rather use of individual / personalized font symbols? What else is useful? In fact, classification by having seen lots of examples is one of our brain's fundamental approaches for recognition... Best wishes, Jürgen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contemporary notation (Re: GSoC projects list)
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 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 r
Re: Contemporary notation (Re: GSoC projects list)
> 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 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 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
Re: Contemporary notation (Re: GSoC projects list)
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 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 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 cr
Re: Contemporary notation (Re: GSoC projects list)
> 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 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 > s
Re: Contemporary notation (Re: GSoC projects list)
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 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
Re: Contemporary notation (Re: GSoC projects list)
Jeffery Shivers writes: > 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. 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. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Contemporary notation (Re: GSoC projects list)
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. > 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. > 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. On Mon, Feb 6, 2017 at 3:15 AM, Urs Liska 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 -- Jeffery Shivers jefferyshivers.com sou
Re: GSoC projects list
>> . a figured bass mode similar to (jazz) chord mode to display >> figured bass as chords > > What do you mean exactly? Determining the chord name from the > figures and displaying it? This also, but mainly displaying the figured bass chord as notes (which is essentially equivalent). >> . Developing and implementing an OpenType Scheme API. > > Do you mean a way to access the extended font features from > LilyPond, so I can get real caps or swash alternates etc.? Yes. > Or is there even more to it? There is more to it, but those details shouldn't bother us much, because we are going to use the Pango interface anyway, AFAIK. > Abraham, do you think you'd be capable of mentoring such a project? I could co-mentor it (being a font technology geek :-) but certainly not being the main mentor. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Contemporary notation (Re: GSoC projects list)
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
Re: GSoC projects list
Am 06.02.2017 um 08:48 schrieb Werner LEMBERG: >> 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. > Some ideas, without being able to mentor them. > > . Braille support That would be cool. But of course this would require a very specific mentoring skill set. > . a figured bass mode similar to (jazz) chord mode to display figured > bass as chords What do you mean exactly? Determining the chord name from the figures and displaying it? Carl, could that be merged into the chord structure project? > . Developing and implementing an OpenType Scheme API. Do you mean a way to access the extended font features from LilyPond, so I can get real caps or swash alternates etc.? Or is there even more to it? Abraham, do you think you'd be capable of mentoring such a project? @everybody: it's no problem to be listed on multiple projects. In the end you're not even allowed to actually mentor two projects, so there's no risk of being talked into eventually ;-) Urs > > > Werner -- 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
Re: GSoC projects list
> 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. Some ideas, without being able to mentor them. . Braille support . a figured bass mode similar to (jazz) chord mode to display figured bass as chords . Developing and implementing an OpenType Scheme API. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
Am 6. Februar 2017 07:56:34 MEZ schrieb Jan-Peter Voigt : >Hi 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. >You asked me about this one several days ago and I didn't answer (yet). > >So let me do it now: I am willing to mentor the musicXML project. Thanks, this is great. However, I think also the description is still somewhat unclear (which is what I actually wanted to say). Urs > >Best >Jan-Peter > >> 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 >> >> > > >___ >lilypond-devel mailing list >lilypond-devel@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-devel -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GSoC projects list
Hi 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. You asked me about this one several days ago and I didn't answer (yet). So let me do it now: I am willing to mentor the musicXML project. Best Jan-Peter 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GSoC projects list
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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
