how do i feel about GLISS discussions
Hi Team, i was going to write that i'm tired by the arguments that seem to plague our GLISS discussions, and that i need a break. But then i realized that i love Lilypond too much, and that i care both about her development and her developers, so i'll continue participating in the discussions :) Together we can shape the future of music engraving! I apologize for not responding promptly to all replies to my messages - there's so much happening that i find it hard to keep up with everything. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
David Kastrup d...@gnu.org writes: Within your own scores, be consistent in your choices. How this consistency looks, does not matter. Within LilyPond, there is a large consistency which elements are uppercase, and which lowercase. The one thing that actually gets annoying is CamelCase. However, as a rule, camelcase starts with lowercase letters. With recent changes in the lexer, it would be possible to replace the CamelCase words with dashed words. That would allow for things like \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am personally not a big fan of CamelCase. You would, of course, get the same principal problem I can't remember where and whether to put dashes when making use of that option. Weeding out CamelCase would not, in itself, change the classes of things that we use uppercase for, lowercase for, and dashes for (there would be some overlap in classes since we _do_ have a few existing words-with-dashes and \commands-with-dashes, but distinguishing those classes is actually not important, unlike the pure lower/uppercase distinction we actually use for Grob and Context names). Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. I don't think that this characterization is doing justice to the developers since it basically assumes that their main incentive is making fun of users. Part of the reason working on LilyPond is less rewarding than it could be is this atmosphere of distrust, and the urge to rein in developers who apparently have nothing better to do than damage LilyPond. distrust is maybe too strong a word. non-involvement may be closer to the truth. Regarding the GLISS discussions and proposals in that context becoming official project policy, participation of programmers is actively discouraged. Goals are being set without bothering to look at how the existing and developing code base and its underlying design will support them. For me, one of the pillars of userfriendliness is coherence of design. When a user is able to predict how to do something. If programmers are not supposed to participate in the design process, and non-programmers will not be participating in executing this design, we get to the situation where those who have the means of implementing a design will do this ad-hoc, stealthily, and without communication or coordination. Stealthily may seem like too strong a word, but quite a few of the actual usability/language features are proposed and finally implemented in the way we see in URL:http://code.google.com/p/lilypond/issues/detail?id=2717. There is minimal feedback by few persons (this particular issue has already gotten more feedback than usual in its first iterations and will presumably pass into LilyPond silently once nobody can think of something to particularly dislike). If you take a look at our Changes file from 2.16 and take a look at how many of those changes were the result from following through with active and planned policy decisions rather than spontaneously done work, it does not appear that our purported planning is connected much to what actually gets done, and users could exercise more influence if they actually commented on issues in the tracker accompanying actual work in progress rather than participating in a hypothetical discussion detached from the realities of both our code base and worker base. One issue/review that recently profited a lot from interaction of developers and users was URL:http://code.google.com/p/lilypond/issues/detail?id=2823 where people cooperated in collecting and completing information, leading to a much better informed approach to actual work. If you take a look at _who_ collected the various bits of information, however, you'll see the usual suspects again: seasoned programmers, just that some of them acted in the capacity of users in the context of this issue. We definitely can make use of a _lot_ more of this kind of user involvement and exchange of knowledge, interest, and inspiration, but I don't see that the syntax discussions and decisions detached from the actual development are facilitating this. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
Am 20.09.2012 11:56, schrieb David Kastrup: David Kastrup d...@gnu.org writes: Within your own scores, be consistent in your choices. How this consistency looks, does not matter. Within LilyPond, there is a large consistency which elements are uppercase, and which lowercase. The one thing that actually gets annoying is CamelCase. However, as a rule, camelcase starts with lowercase letters. With recent changes in the lexer, it would be possible to replace the CamelCase words with dashed words. That would allow for things like \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am personally not a big fan of CamelCase. You would, of course, get the same principal problem I can't remember where and whether to put dashes when making use of that option. Weeding out CamelCase would not, in itself, change the classes of things that we use uppercase for, lowercase for, and dashes for (there would be some overlap in classes since we _do_ have a few existing words-with-dashes and \commands-with-dashes, but distinguishing those classes is actually not important, unlike the pure lower/uppercase distinction we actually use for Grob and Context names). Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. It is not that I am not interested in this kind of discussions/proposals, it is just that I have no problem with camelCase/uppercase/lowercase stuff, so I don't need a change here; on the other hand, if this would make it easier for everyone, then I would not object to a lilypond is all lowercase change. I don't think that this characterization is doing justice to the developers since it basically assumes that their main incentive is making fun of users. Part of the reason working on LilyPond is less rewarding than it could be is this atmosphere of distrust, and the urge to rein in developers who apparently have nothing better to do than damage LilyPond. distrust is maybe too strong a word. non-involvement may be closer to the truth. Regarding the GLISS discussions and proposals in that context becoming official project policy, participation of programmers is actively discouraged. Goals are being set without bothering to look at how the existing and developing code base and its underlying design will support them. I think that defining _goals_ can be done seriously only by taking the underlying design, the developers etc. into account, but _discussions_ should have any amount of freedom they need. [...] Stealthily may seem like too strong a word, but quite a few of the actual usability/language features are proposed and finally implemented in the way we see in URL:http://code.google.com/p/lilypond/issues/detail?id=2717. There is minimal feedback by few persons (this particular issue has already gotten more feedback than usual in its first iterations and will presumably pass into LilyPond silently once nobody can think of something to particularly dislike). You are right. I can only speak for myself, but the main problem is that most of the time I can spend for working on LilyPond is put into the actual patches; the reviewing process is handled rather shabbily, I confess. I take a look at nearly *every* issue when I got an email notification, but I often do not find the time to get deeper into the problem to understand what the current proposal means or what the patch to be review actually does. And just a quick LGTM, but not tested doesn't help anybody. If you take a look at our Changes file from 2.16 and take a look at how many of those changes were the result from following through with active and planned policy decisions rather than spontaneously done work, it does not appear that our purported planning is connected much to what actually gets done, and users could exercise more influence if they actually commented on issues in the tracker accompanying actual work in progress rather than participating in a hypothetical discussion detached from the realities of both our code base and worker base. One issue/review that recently profited a lot from interaction of developers and users was URL:http://code.google.com/p/lilypond/issues/detail?id=2823 where people cooperated in collecting and completing information, leading to a much better informed approach to actual work. If you take a look at _who_ collected the various bits of information, however, you'll see the usual suspects again: seasoned programmers, just that some of them acted in the capacity of users in the context of this issue. Do you propose that the user base should get more information about development work? When working on tablature features, I got an *overwhelming* response of other users, a lot of how about x/can you do y stuff which more often than not found its way into tablature.scm. In other areas, the response was about nil. So there is no common rule how to get people involved. We definitely can make use of a
Re: [GLISS] - alternative viewpoint
Marc Hohl m...@hohlart.de writes: Am 20.09.2012 11:56, schrieb David Kastrup: David Kastrup d...@gnu.org writes: Within your own scores, be consistent in your choices. How this consistency looks, does not matter. Within LilyPond, there is a large consistency which elements are uppercase, and which lowercase. The one thing that actually gets annoying is CamelCase. However, as a rule, camelcase starts with lowercase letters. With recent changes in the lexer, it would be possible to replace the CamelCase words with dashed words. That would allow for things like \slur-up \slur-down \voice-one \one-voice \voice-two and so on. I am personally not a big fan of CamelCase. You would, of course, get the same principal problem I can't remember where and whether to put dashes when making use of that option. Weeding out CamelCase would not, in itself, change the classes of things that we use uppercase for, lowercase for, and dashes for (there would be some overlap in classes since we _do_ have a few existing words-with-dashes and \commands-with-dashes, but distinguishing those classes is actually not important, unlike the pure lower/uppercase distinction we actually use for Grob and Context names). Just quoting this as yet another example where I offer some concrete suggestions in a GLISS thread with nobody bothering to even reply. It is not that I am not interested in this kind of discussions/proposals, it is just that I have no problem with camelCase/uppercase/lowercase stuff, so I don't need a change here; on the other hand, if this would make it easier for everyone, then I would not object to a lilypond is all lowercase change. The problem is not people not interested in this kind of discussions/proposals. The problem is people who stop being interested in an oh so important problem the moment one tries offering different, more feasible solutions than what they were thinking of. If the problem is not important enough to give feasible approaches at a solution serious consideration (which most certainly would include explaining in which way they appear inferior to the less feasible approaches), then it is hard to consider it important enough to bother with the infeasible approaches. I can only speak for myself, but the main problem is that most of the time I can spend for working on LilyPond is put into the actual patches; the reviewing process is handled rather shabbily, I confess. With regard to reviewing user interface additions, it may indeed be the case that other developers don't care much since they could get along fine previously, trust they'll get along fine in future, and maybe trust other developers not to do all too much damage. But we don't have users involved either. And those are actually the ones for which such additions are made. Involving them instead in a planning stage largely disconnected from actual developments is a poor substitute. I take a look at nearly *every* issue when I got an email notification, but I often do not find the time to get deeper into the problem to understand what the current proposal means or what the patch to be review actually does. And just a quick LGTM, but not tested doesn't help anybody. That's more or less topical for code changes, like the stuff Mike does. For documentation and user interface changes (probably with the exception of things like try removing the closed music category which focuses on obliterating behavior that was not really suitable for documenting), the target audience are users (a superset of developers, hopefully). But we don't have them involved in the feedback. And I don't think we should wait with getting them involved until my devious plan of turning users into programmers almost without noticing bears fruit. Do you propose that the user base should get more information about development work? Yes. When working on tablature features, I got an *overwhelming* response of other users, a lot of how about x/can you do y stuff which more often than not found its way into tablature.scm. In other areas, the response was about nil. So there is no common rule how to get people involved. Sure. But with our issue tracker, users don't get involved as a rule. Even on issues started from a user report. We definitely can make use of a _lot_ more of this kind of user involvement and exchange of knowledge, interest, and inspiration, but I don't see that the syntax discussions and decisions detached from the actual development are facilitating this. Well, I am still not sure about the latter. Within specific sub-areas like tablature support, this apparently works better than when LilyPond as a whole is concerned. Let's write a subsystem/package for this is just much more manageable than let's change LilyPond as a whole. Obviously, we should strive to change LilyPond as a whole in order to make it easier to delegate problems to the subsystem/package level. That allows for much
Re: [Lilypond-auto] Issue 2717 in lilypond: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f
Am 20.09.2012 18:17, schrieb lilyp...@googlecode.com: [...] Oh. \omit is actually even better, isn't it? Yes, I like it! I'll likely change that, short of protests. Still, something more convincing for \single would be nice. Yes, but I still have no clue ... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2717 in lilypond: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f
Still, something more convincing for \single would be nice. \immediate? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2717 in lilypond: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f
Werner LEMBERG w...@gnu.org writes: Still, something more convincing for \single would be nice. \immediate? How is \once not immediate? Or actually any override? At least I am not convinced. Another thought I had was to punt and not create a separate command, but just let \tweak itself take an override instead of a specification, like \tweak \hideNotes c but I am not particularly enthused about that. Currently the signature of \tweak is something like (parser location name property value music) ((string?) symbol? scheme? ly:music?) and this change would not really be all that compatible. I think I figured some rather contrived combination of options to hand-simulate that kind of behavior, but I am no longer sure. A separate word seems saner. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] Doc: fix small inaccuracy
Hello, this patch changes variables--commands when talking about \germanChords, \semiGermanChords etc in NR 2.7.2. I don't remember whether simple patches like this can obtain LGTM directly through the list or they need a rietveld push in any case. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com 0001-Doc-fix-small-inaccuracy-in-notation-manual-chapter-.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Doc: fix small inaccuracy
On Thu, Sep 20, 2012 at 07:35:41PM +0200, Francisco Vila wrote: I don't remember whether simple patches like this can obtain LGTM directly through the list or they need a rietveld push in any case. Sure, that's simple enough. LGTM, please push directly. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: extend explanation of relative-includes (2558) (issue 6490120)
LGTM http://codereview.appspot.com/6490120/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2717 in lilypond: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f
Le 20/09/2012 19:15, Marc Hohl disait : Am 20.09.2012 18:17, schrieb lilyp...@googlecode.com: [...] Oh. \omit is actually even better, isn't it? Yes, I like it! I'll likely change that, short of protests. Still, something more convincing for \single would be nice. Yes, but I still have no clue ... Why not \mask, since the space taken by the object is still preserved? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Improve documentation of \glissando. (issue 6529043)
We normally do not include \override in most sections of the Notation manual. Instead, we ask users to submit LSR snippets showing the \override, then we include those snippets in the docs. This allows us to improve the documentation with minimal effort on the part of developers. If there's a special reason to include \override directly, then we can -- we do this when discussing automatic beaming, for example, because there's no sense in mentioning this without having overrides. But I'm not certain if this applies in this case? http://codereview.appspot.com/6529043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] - alternative viewpoint
[sorry, forgot to hit Reply to all] Am 20.09.2012 19:02, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: [...] The problem is not people not interested in this kind of discussions/proposals. The problem is people who stop being interested in an oh so important problem the moment one tries offering different, more feasible solutions than what they were thinking of. If the problem is not important enough to give feasible approaches at a solution serious consideration (which most certainly would include explaining in which way they appear inferior to the less feasible approaches), then it is hard to consider it important enough to bother with the infeasible approaches. That's true. I can only speak for myself, but the main problem is that most of the time I can spend for working on LilyPond is put into the actual patches; the reviewing process is handled rather shabbily, I confess. With regard to reviewing user interface additions, it may indeed be the case that other developers don't care much since they could get along fine previously, trust they'll get along fine in future, and maybe trust other developers not to do all too much damage. But we don't have users involved either. And those are actually the ones for which such additions are made. Involving them instead in a planning stage largely disconnected from actual developments is a poor substitute. +1 [...] Do you propose that the user base should get more information about development work? Yes. [...] Within specific sub-areas like tablature support, this apparently works better than when LilyPond as a whole is concerned. The strategy to split the development process into sub-areas and announce them on -user might be a good plan; this means that someone has to provide a reasonable interface so that users can be easily informed about topic x. This is probably easy when topic x is about extending some features or defining new features lilypond should have, but in other cases you'll need a way to allow users to test patches, and that's more difficult, I think (except there is a way to extend the automatic patch test mechanism so that users can download special precompiled versions of lilypond including a certain patch set and test it thoroughly before this feature becomes official). Let's write a subsystem/package for this is just much more manageable than let's change LilyPond as a whole. Obviously, we should strive to change LilyPond as a whole in order to make it easier to delegate problems to the subsystem/package level. That allows for much more parallelized processing. +1 Do you already have a strategy how to split the whole system into subsystems? Do you think of extending the way the work on lilypond is done at present (i.e. the patch revision system and the code guidelines stay mostly unchanged) or rather to allow for something like the macro packages in LaTeX, where anyone can roll his own package, writes a documentation for it and may upload it on some server? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Improve documentation of \glissando. (issue 6529043)
Am 20.09.2012 20:08, schrieb gra...@percival-music.ca: We normally do not include \override in most sections of the Notation manual. Instead, we ask users to submit LSR snippets showing the \override, then we include those snippets in the docs. This allows us to improve the documentation with minimal effort on the part of developers. If there's a special reason to include \override directly, then we can -- we do this when discussing automatic beaming, for example, because there's no sense in mentioning this without having overrides. But I'm not certain if this applies in this case? So this means that the first, second and third example should go into a LSR snippet to be included in the documentation, the latter examples do not have any \override and can stay unchanged? At least this would make sense for me. Regards, Marc http://codereview.appspot.com/6529043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how do i feel about GLISS discussions
On Thu, Sep 20, 2012 at 11:11:22AM +0200, Janek Warchoł wrote: i was going to write that i'm tired by the arguments that seem to plague our GLISS discussions, and that i need a break. That's the correct thing to do. The current flamefest is going nowhere. Or rather, it's going backwards: by isolating developers, we have less energy going into lilypond. This results in us not catching minor mistakes until they become more serious -- for example, Werner's recent doc patch included a number of \overrides which should really by in LSR instead. If a doc person had looked at this in detail a week ago, we could have avoided some wasted work by Werner. Unfortunately, nobody felt motivated enough to look at it, so I only noticed it on this final day of the patch countdown. My solution is to take a break, then read the emails and modify the proposal for how to organize ly language discussions. Then I'll wait a few days, read the responses to *that*, modify it again if necessary, etc. If all goes well, then we would be able to begin having decent discussions about the ly language in mid-Oct. I see no chance of having worthwhile discussions before then, and I wouldn't be surprised if it didn't actually begin until Nov. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2717 in lilypond: Patch: Implement \hidden/\hide as shorthands for \tweak/\override #'stencil = ##f
Jean-Charles Malahieude lily...@orange.fr writes: Le 20/09/2012 19:15, Marc Hohl disait : Am 20.09.2012 18:17, schrieb lilyp...@googlecode.com: [...] Oh. \omit is actually even better, isn't it? Yes, I like it! I'll likely change that, short of protests. Still, something more convincing for \single would be nice. Yes, but I still have no clue ... Why not \mask, since the space taken by the object is still preserved? Uh no, it isn't. That's \hide, working through the transparent property. \omit does not preserve the space since it removes the stencil. Yes, the issue title needs to be adapted. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Improve documentation of \glissando. (issue 6529043)
Reviewers: Graham Percival,
Message:
I agree with your argumentation. However, I don't have time to fix the
patch. Maybe a good soul from the documentation team can improve this.
Description:
Doc: Improve documentation of \glissando.
Based on work from Tiresia GIUNO tires...@googlemail.com.
Please review this at http://codereview.appspot.com/6529043/
Affected files:
M Documentation/notation/expressive.itely
Index: Documentation/notation/expressive.itely
diff --git a/Documentation/notation/expressive.itely
b/Documentation/notation/expressive.itely
index
25dbc81d798c75a3b3b1fef709d6fb2b7b66c2e8..528cdb2047c56e75470673e535f57d7b8a3849c4
100644
--- a/Documentation/notation/expressive.itely
+++ b/Documentation/notation/expressive.itely
@@ -1038,15 +1038,88 @@ g2\glissando g'
c2\glissando c,
@end lilypond
+It is possible to place an expression mark at a certain point within
+the glissando, usually indicated by a stem without a notehead:
+
+@lilypond[verbatim,quote,relative=2]
+f4\glissando\
+\once \override NoteColumn #'glissando-skip = ##t
+\once \override NoteHead #'transparent = ##t
+a4\f\ a8\! r4.
+@end lilypond
+
+@noindent
+Setting @code{glissando-skip} to @code{#t} makes the glissando skip the
+inserted @code{NoteColumn} grob. To hide the notehead, the
+@code{transparent} property is set to @code{#t}. If the stem doesn't
+align well with the glissando, it may need repositioning.
+
+The same works with more than one inserted grob:
+
+@lilypond[verbatim,quote,relative=2]
+r8 f2\glissando a8 r4 |
+r8 f8\glissando
+\override NoteColumn #'glissando-skip = ##t
+\override NoteHead #'transparent = ##t
+g4 a8
+\revert NoteColumn #'glissando-skip
+\revert NoteHead #'transparent
+a8 r4
+@end lilypond
+
+Setting the @code{breakable} property to @code{#t} in combination with
+@code{after-line-breaking} allows to break a glissando if it occurs
+at a line break:
+
+@lilypond[verbatim,quote,relative=2,line-width=4.0\cm]
+\override Glissando #'breakable = ##t
+\override Glissando #'after-line-breaking = ##t
+
+f1\glissando | \break
+a4 r2. |
+f1\glissando \break
+\once \override NoteColumn #'glissando-skip = ##t
+\once \override NoteHead #'transparent = ##t
+a2 a4 r4 |
+@end lilypond
+
+A glissando can connect notes across staves:
+
+@lilypond[verbatim,quote]
+\new PianoStaff
+ \new Staff = right {
+e'''2\glissando
+\change Staff = left
+a,,\glissando
+\change Staff = right
+b''8
+ }
+ \new Staff = left {
+\clef bass s1 s8
+ }
+
+@end lilypond
+
+A glissando can occur between chords:
+
+@lilypond[verbatim,quote,relative=2]
+c1\glissando g'
+c, e1\glissando g' b \break
+
+\set glissandoMap = #'((0 . 1) (1 . 0))
+c, g'1\glissando d a'
+\set glissandoMap = #'((0 . 0) (0 . 1) (0 . 2))
+c1\glissando d f a
+\set glissandoMap = #'((2 . 0) (1 . 0) (0 . 1))
+d f a1\glissando c c'
+@end lilypond
+
Different styles of glissandi can be created. For details, see
@ref{Line styles}.
@snippets
@lilypondfile[verbatim,quote,texidoc,doctitle]
-{glissandi-can-skip-grobs.ly}
-
-@lilypondfile[verbatim,quote,texidoc,doctitle]
{contemporary-glissando.ly}
@seealso
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Improve documentation of \glissando. (issue 6529043)
On 2012/09/20 18:08:15, Graham Percival wrote: We normally do not include \override in most sections of the Notation manual. Instead, we ask users to submit LSR snippets showing the \override, then we include those snippets in the docs. This allows us to improve the documentation with minimal effort on the part of developers. If there's a special reason to include \override directly, then we can -- we do this when discussing automatic beaming, for example, because there's no sense in mentioning this without having overrides. But I'm not certain if this applies in this case? glissando-skip was introduced somewhere in 2.15.x, so no snippet using it can make into LSR. Thinking of an LSR-update, David recently suggested to wait a bit: http://lists.gnu.org/archive/html/lilypond-devel/2012-09/msg00715.html http://codereview.appspot.com/6529043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-5 - GLISS discussions
On 14/09/12 07:13, Graham Percival wrote:
http://lilypond.org/~graham/gop/gop_6.html
** Summary
We’ve gone over the same arguments a number of times, so let’s try
to resolve them. Fluff will go on a new mailing lilypond-quacks
mailing list. Serious proposals, if any, will go to
lilypond-devel. Anybody with a serious proposal must be familiar
with the Extending manual, must write up a formal proposal, will
be subjected to multiple rounds of questioning, etc.
1+
I think it’s also time to consider splitting the language in a
manner similar to TeX and LaTeX. Namely, the current language
could remain (almost?) unchanged, while an additional layer (ly2?
lz? ly++ ?) could provide an easier way to write music, which
would then be translated into ly for normal compiling. This could
resolve a great deal of friction between people who want more
“syntactic sugar” and those who want less sugar (or at least, no
more than current).
Interesting idea, but I think we need to decide on the
language-design/concept/fluff discussion-on-developers-list split first.
I've got opinions on this, but I think, given the criteria you developed
re the new list, it needs bouncing around there first.
** Motivation
Before stabilizing the syntax, I think we should have a discussion
about possible changes. Many people would like to talk about the
ly language (regardless of whether that involves the parser,
lexer, naming of functions and keywords and pitches, etc). Whether
“possible changes” means a “1% chance” or a “0.1% chance” is
irrelevant at present. The goal is to share ideas. If you don’t
like fluff discussions that will probably go nowhere, don’t read
those emails.
I don’t know how to make this more clear. We want to have free
discussions, with no expectations of anything being implemented.
If this doesn’t seem appealing to you, there is no need to panic.
Some people enjoy singing in choirs; other people enjoy playing in
rock bands; other people listen to electronica. There is no need
to complain about other people’s leisure activities just because
you don’t enjoy those activities.
** The ly language
There’s some ambiguity in the term syntax (at least, some people
might understand that word in different ways. So I’m coining a new
term: the ly language. This refers to anything that takes place
inside a ly file.
** Mailing list
I suggest that we discuss possible modifications to the ly
language to syntax on a new lilypond-quacks mailing list. These
ideas are not formal proposals, and will not be acted upon. In
exchange, nobody on that email list will complain about
technically infeasible ideas, wasting developer’s time, having to
defend the parser, or anything like that. That list will welcome
all members – there will be no expectation that people discussing
ideas will be familiar with the parser, be capable of producing
patches, or even will have read the Extended manual. The intent
behind moving informal ideas to a separate list is to avoid
causing programmers any worry from technically infeasible ideas.
** ly++
The current format needs to have a one-to-one correspondance (or
“bijection”) between ly and scheme. Graphically, the process is
something like this:
ly -- scheme - pdf/midi
However, some ideas on the lilypond-quacks list might not allow an
unambiguous translation from scheme to the potential new syntax,
despite having an unambiguous translation from that new syntax to
scheme. It might be worth considering extending the processing
chain:
ly++ - ly -- scheme - pdf/midi
At the very least, it’s worth keeping these translations between
layers in mind; if no scheme-language translation is possible,
then that idea is not suitable for the ly language and could only
possibly be used in a theoretical ly++ language.
** Language standardization
The standardization part, wherein we very slowly and cautiously
declare certain portions of the ly language as not open to future
changes, takes place in:
https://github.com/gperciva/lilypond-extra/tree/master/gliss
http://lilypond.org/~graham/gliss/
This process will begin a few months after we begin having open
and friendly discussions about the syntax on lilypond-quacks.
** Formal proposals
If somebody has a serious suggestion for a change to the ly
language (with the exception of renaming internals, which we do on
a completely ad-hoc basis), there will be a much more involved
process.
Ideally, this will include a patch, examples of ly files before
and after the change, at least two weeks of discussion (similar to
GOP), etc.
I think patches should be the *outcome* of this stage, where the current
current patch/review process would take over.
This bit would be discuss the kind of thing like we use properties and
whatnot, how about using the rest of the OOPS stuff like methods
Example:
JAZombiesFullScore = {
% declarations and music for music
Re: [GLISS] - alternative viewpoint
Sorry, forgot to complete the mail adresses. 2012/9/20 David Kastrup d...@gnu.org: Marc Hohl m...@hohlart.de writes: [...] But we don't have users involved either. And those are actually the ones for which such additions are made. Involving them instead in a planning stage largely disconnected from actual developments is a poor substitute. [...] the target audience are users (a superset of developers, hopefully). But we don't have them involved in the feedback. And I don't think we should wait with getting them involved until my devious plan of turning users into programmers almost without noticing bears fruit. Do you propose that the user base should get more information about development work? Yes. When working on tablature features, I got an *overwhelming* response of other users, a lot of how about x/can you do y stuff which more often than not found its way into tablature.scm. In other areas, the response was about nil. So there is no common rule how to get people involved. Sure. But with our issue tracker, users don't get involved as a rule. Even on issues started from a user report. We definitely can make use of a _lot_ more of this kind of user involvement and exchange of knowledge, interest, and inspiration, but I don't see that the syntax discussions and decisions detached from the actual development are facilitating this. Well, I am still not sure about the latter. Within specific sub-areas like tablature support, this apparently works better than when LilyPond as a whole is concerned. Let's write a subsystem/package for this is just much more manageable than let's change LilyPond as a whole. Obviously, we should strive to change LilyPond as a whole in order to make it easier to delegate problems to the subsystem/package level. That allows for much more parallelized processing. -- David Kastrup Hi David, Marc, speaking only for me: I'm terrible sorry that I currently can't give you the feedback you desire. Since my injury, I wasn't able to concentrate on any more involved project or to finish any larger one. Also, I let Marc alone with the bar-line-code, we started to tackle together. Marc, please accept my apologies. So I mostly limited my activities to answer questions on the user-list, FWIW. But perhaps you may accept some summarizing thoughts about involving users in the development-process. (Most of them already mentioned) Or better: why it doesn't work, currently. Thinking of an average user, subscribing the user-list only: (1) He's often not informed that sth is planned/discussed/in-work. (2) If he's informed and looks at the code on Rietveld, he doesn't know what to do with it, because very often there's no example/regtest/snippet _how_ to use the new syntax/feature/code/whatever. Ok, Rietveld is not the place to put in such additional, illustrating examples, etc. But I think you get my point. (3) Thinking of more involved tasks like testing a patch (and managing the tools needed to do so), I assume this is not a task an average-user is expected to manage, with the current system. At least I had some larger problems installing LilyDev (I wasn't able to install the required fontforge-version, I had to ask for help) Also, learning how to deal with the new world of git-commands is time-consuming. etc etc So I second Marc: 2012/9/20 Marc Hohl m...@hohlart.de: but in other cases you'll need a way to allow users to test patches, and that's more difficult, -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120923
For 20:00 MDT Sunday September 23 Critical: Issue 2831 http://code.google.com/p/lilypond/issues/detail?id=2831: Crash with slurs and flags and duration-override - R 6500130 http://codereview.appspot.com/6500130/ Documentation: Issue 2807 http://code.google.com/p/lilypond/issues/detail?id=2807: Alternative to setting beatStructure - R 6532055 http://codereview.appspot.com/6532055/ Enhancement: Issue 2850 http://code.google.com/p/lilypond/issues/detail?id=2850: Patch: Update help2man to latest release 1.40.12 - R 6540043 http://codereview.appspot.com/6540043/ Scripts: Issue 2846 http://code.google.com/p/lilypond/issues/detail?id=2846: Patch: Fix numeric tempi and detached lyrics in abc2ly - R 6526045 http://codereview.appspot.com/6526045/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
