Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

[Noeck]

Hi,

Am 06.02.2017 um 20:08 schrieb d...@gnu.org:
> https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm#newcode188
> 
> scm/define-grob-properties.scm:188: (collapse-length ,ly:dimension? "An
> automatically generated
> collapse-width maybe?  Length is more like a list length?

The original idea for a name was "minimum-length". Then there was a
lengthy (no pun intended) discussion, because it's different from what
happens at hairpins, leading to "collapse-length".

While I understand the width/length reasoning from a programming point
of view. In the score, I would still call it a length of an extender
line and not a width. Because a line width is sth. different. (Native
speakers please correct me.)

Cheers,
Joram

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Contemporary notation (Re: GSoC projects list)

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

   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: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

[dak]

It's not really clear to me where I am supposed to go from here with
what I proposed.  I lean towards going back to creating my own version
of this again since this one contains so much stuff that does not ring a
bell with me.


https://codereview.appspot.com/313240043/diff/21/lily/extender-engraver.cc
File lily/extender-engraver.cc (right):

https://codereview.appspot.com/313240043/diff/21/lily/extender-engraver.cc#newcode33
lily/extender-engraver.cc:33: #include "iostream"
Why?

https://codereview.appspot.com/313240043/diff/21/lily/extender-engraver.cc#newcode87
lily/extender-engraver.cc:87: ASSIGN_EVENT_ONCE (hy_, ev);
If we are not the primary engraver for an item, we should not complain
about how often an event is assigned I think.

https://codereview.appspot.com/313240043/diff/21/lily/extender-engraver.cc#newcode109
lily/extender-engraver.cc:109: if (ex_ && !hy_)
Why check for hy_ here?  If there is an explicit extender event, why
would we mess with it?

https://codereview.appspot.com/313240043/diff/21/lily/extender-engraver.cc#newcode112
lily/extender-engraver.cc:112: extender_->set_property
("force-extender", SCM_BOOL_T);
I think it might make more sense to have, if at all, a property for
implicitly generated extenders so that any extender generated by a
user-created engraver sounds as forced.  We could probably could just
look up the event_cause and see whether it is a lyric-event, but when
user-created extenders are expected at all, it might probably be
advisable to have a more explicit property one can set to switch between
explicit and implicit behavior.

https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc
File lily/lyric-extender.cc (right):

https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc#newcode54
lily/lyric-extender.cc:54: bool no_auto_extenders = to_boolean
(me->get_property ("no-auto-extenders"));
That is awful.  Creating extenders with properties like "no-extender" or
"no-auto-extenders" in order to decide whether one did not want an
extender in the first place is nonsensical.  If we want to suppress
extenders on anything but visual appearance, we should have context
properties for that and not even generate them.

Because we might want to be able to create similar behavior in Midi or
other backends where no grobs are available.

https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc#newcode63
lily/lyric-extender.cc:63: while (hs && robust_scm2double
(heads[hs-1]->get_property
Same as previously I see.

https://codereview.appspot.com/313240043/diff/21/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):

https://codereview.appspot.com/313240043/diff/21/lily/self-alignment-interface.cc#newcode63
lily/self-alignment-interface.cc:63: ly_symbol2scm
("lyric-syllable-interface"
Why is this necessary?

https://codereview.appspot.com/313240043/diff/21/lily/self-alignment-interface.cc#newcode146
lily/self-alignment-interface.cc:146: ly_symbol2scm
("lyric-syllable-interface"
And this?

https://codereview.appspot.com/313240043/diff/21/lily/self-alignment-interface.cc#newcode156
lily/self-alignment-interface.cc:156: ly_symbol2scm
("lyric-syllable-interface"
And this?

Shouldn't we rather try to fix the condition rather than remove the
warning?

https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm#newcode188
scm/define-grob-properties.scm:188: (collapse-length ,ly:dimension? "An
automatically generated
collapse-width maybe?  Length is more like a list length?

https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm#newcode684
scm/define-grob-properties.scm:684: (no-auto-extenders ,boolean?
"Inhibits automatic generation of lyric
Why do we need this also?

There are just too many properties.

https://codereview.appspot.com/313240043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Automatic LyricExtenders (issue 313240043 by perpeduumimmob...@gmail.com)

[dak]

On 2017/02/06 11:02:56, akobel wrote:

Version 2017-02-04 by David


Not "by David" but "by Kurt".  David merely rebased Kurt's new version.

https://codereview.appspot.com/313240043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

HTML 4.01 requires "type" attribute for "script" element (issue 315540043 by d...@gnu.org)

[graham]

LGTM

https://codereview.appspot.com/315540043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Contemporary notation (Re: GSoC projects list)

[Jeffery Shivers]

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 

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

Re: Contemporary notation (Re: GSoC projects list)

[Urs Liska]

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 

Re: Cleaning up GSoC project ideas

[Urs Liska]

Am 06.02.2017 um 15:40 schrieb Paul:
> On 02/02/2017 04:10 PM, Urs Liska wrote:
>
>> However, I suggest that we either remove such orphaned projects or at
>> least compress and move them down to the bottom of the page. A concise
>> page with actual and current projects is quite important for attracting
>> students, I think.
>
> Sorry for the delay responding...  I'd rather not lose them from the
> website entirely just because they don't currently have a mentor (as
> long as we think they are viable student projects).  What if next year
> new/old mentors are available?

This is a valid point, and actually my crude proceeding was also
intended to *force* people like you coming up with such thoughts.

>
> But since you think it's important to remove or demote those
> projects... Why don't we move them to the "attic" page.  Then next
> year we can easily look at them again to see if mentors are available
> and we want to promote them back up to the GSOC page?

This is a good idea. Any suggestion where *exactly* to put them to?

>
> Might also be worth putting the grace note one there with a note that
> we decided it was too much for a GSOC project.  Otherwise people may
> re-propose it in the future.

+1

>
>> The question is what will remain, and I *strongly* encourage all of you
>> to consider the existing list and/or think about projects that could be
>> suitable for a student to tackle in three months of full-time work, and
>> where you could consider volunteering to be listed as a mentor.
>
> I haven't been able to think of any new projects.  I'd consider being
> a mentor for something involving scheme, but I haven't had a chance to
> look at the list or think further about it.
>

How about this one:
https://codereview.appspot.com/312440043/diff/1/Documentation/web/community.itexi
?

Urs

> -Paul
>
> ___
> 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


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Cleaning up GSoC project ideas

[Paul]

On 02/02/2017 04:10 PM, Urs Liska wrote:


However, I suggest that we either remove such orphaned projects or at
least compress and move them down to the bottom of the page. A concise
page with actual and current projects is quite important for attracting
students, I think.


Sorry for the delay responding...  I'd rather not lose them from the 
website entirely just because they don't currently have a mentor (as 
long as we think they are viable student projects).  What if next year 
new/old mentors are available?


But since you think it's important to remove or demote those projects... 
Why don't we move them to the "attic" page.  Then next year we can 
easily look at them again to see if mentors are available and we want to 
promote them back up to the GSOC page?


Might also be worth putting the grace note one there with a note that we 
decided it was too much for a GSOC project.  Otherwise people may 
re-propose it in the future.



The question is what will remain, and I *strongly* encourage all of you
to consider the existing list and/or think about projects that could be
suitable for a student to tackle in three months of full-time work, and
where you could consider volunteering to be listed as a mentor.


I haven't been able to think of any new projects.  I'd consider being a 
mentor for something involving scheme, but I haven't had a chance to 
look at the list or think further about it.


-Paul

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Contemporary notation (Re: GSoC projects list)

[David Kastrup]

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)

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

> 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
 

Re: GSoC projects list

[Werner LEMBERG]

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

[Urs Liska]

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

[Urs Liska]

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