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, an
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
>> . 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).
>> . De
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 som
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,
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 r
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 attr
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 access
> 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 a
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
> 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 p
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 founda
LGTM
https://codereview.appspot.com/315540043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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.
On 2017/02/06 18:38:37, dak wrote:
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.
"by Knut" of course.
https://codereview.appspot.com/313240043/
___
lily
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-en
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
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 sh
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 LilyP
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 li
20 matches
Mail list logo
