Re: Please rewrite << { ... } \\ { ... } >> construct
Graham Percival writes: > On Mon, Nov 08, 2010 at 01:26:41PM +0100, Xavier Scheuer wrote: >> On 8 November 2010 13:05, Valentin Villenave wrote: >> > Please repost your mail as a comment there, I think it will be more >> > appropriate, useful and (possibly) efficient :-) >> >> Actually I'm sad when I see this issue is tagged "Type-Enhancement" >> and "Priority-Postponed". >> From a user point of view it is really a "HIGH annoyance" issue, since > > Then offer a bounty, or start investigating how to fix it > yourself. Let me just point out that if ties are resolved at the voice level, and \\ introduces subvoices/threads/whatever (presumably one level above "chord" level which would be responsible for the stemming), then we would not be losing our voice when entering a { \\ } construct. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite << { ... } \\ { ... } >> construct
On Mon, Nov 08, 2010 at 01:26:41PM +0100, Xavier Scheuer wrote: > On 8 November 2010 13:05, Valentin Villenave wrote: > > Please repost your mail as a comment there, I think it will be more > > appropriate, useful and (possibly) efficient :-) > > Actually I'm sad when I see this issue is tagged "Type-Enhancement" > and "Priority-Postponed". > From a user point of view it is really a "HIGH annoyance" issue, since Then offer a bounty, or start investigating how to fix it yourself. > And besides I see other issues that are *not* postponed and have a far > higher priority level that are issues purely "hypothetical" that have > almost no chances to appear in "real-world" scores. If the different of priority levels are important to you, point out the "hypothetical" problems and I'll lower their priority. > We could have a kind of "polling system" to determine what are the > features/issues that are really wanted by users. That already exists; there's a "stars" function built-in to google code. It's not particularly useful, but go ahead and "star" issues that you care about. > And also a point about bounties/sponsors in relation (there are people > on the french mailing list that wants to donate to the project but it > currently lacks a structure to manage these donations). Such a discussion would happen during GOP, after 2.14 is out. I have added it to list. - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite << { ... } \\ { ... } >> construct
"David Kastrup" wrote in message news:87oca00yi7@lola.goethe.zz... Xavier Scheuer writes: Dear LilyPond developers, Kieren, We have had a discussion one year ago about a project to rewrite the << { ... } \\ { ... } >> so it behaves exactly like << { % continuation of the "main" Voice from outside the polyphony \voiceOne ... } \context Voice = "2" { \voiceTwo ... } >> \oneVoice That would kinda solve the issue that what is inside the << { ... } \\ { ... } >> construct is in different voices than the non-polyphonic voice from outside, thus forbidding slurs etc. from outside to inside the polyphonic passage. Slurs, ties etc from outside to the second voice would still be forbidden. The problem really is that Lilypond's notion of continuity (we have that also in repeat alternatives, codas and similar) is too naive. But if we simply said this in the docs it would make it clear it's at least possible. For me, the most annoying aspect of this behaviour is that lyrics aren't continuous across the initial voice and the implicit voices, and when you're setting songs that's a real pain. -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite << { ... } \\ { ... } >> construct
Xavier Scheuer writes: > Dear LilyPond developers, > Kieren, > > We have had a discussion one year ago about a project to rewrite the > << { ... } \\ { ... } >> > so it behaves exactly like > > << > { > % continuation of the "main" Voice from outside the polyphony > \voiceOne > ... > } > \context Voice = "2" { > \voiceTwo > ... > } > >> \oneVoice > > > That would kinda solve the issue that what is inside the > << { ... } \\ { ... } >> construct is in different voices than > the non-polyphonic voice from outside, thus forbidding slurs etc. > from outside to inside the polyphonic passage. Slurs, ties etc from outside to the second voice would still be forbidden. The problem really is that Lilypond's notion of continuity (we have that also in repeat alternatives, codas and similar) is too naive. > This is not well understood by users and it would really help if > this could be solved. The above would not solve it. Some things would work, some things would not. Depending on the voice they happen in. So don't get your expectations too high about what gains can be expected from implementing that proposal. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite << { ... } \\ { ... } >> construct
On 8 November 2010 13:05, Valentin Villenave wrote: > > Hi Xavier, > isn't that the discussion I tried to sum up on > http://code.google.com/p/lilypond/issues/detail?id=1316 > ? Yes, it is exactly that! I looked into the tracker but did not find this issue. Typing "<< \\ >>" into the search bar gives 493 and I must have missed it! > Please repost your mail as a comment there, I think it will be more > appropriate, useful and (possibly) efficient :-) Actually I'm sad when I see this issue is tagged "Type-Enhancement" and "Priority-Postponed". >From a user point of view it is really a "HIGH annoyance" issue, since it obliges me (the user) to use the "explicitly instantiating voices", with a syntax far heavier (and more complex, less user-friendly). When you have to use it a lot in a score you would have preferred the "<< \\ >> construct" *Did The Right Thing*. And besides I see other issues that are *not* postponed and have a far higher priority level that are issues purely "hypothetical" that have almost no chances to appear in "real-world" scores. Sorry to grumble in a non-constrictive way. @Graham Maybe you could add a point about "issue priorities" and/or "highest wanted (by users) features". We could have a kind of "polling system" to determine what are the features/issues that are really wanted by users. And also a point about bounties/sponsors in relation (there are people on the french mailing list that wants to donate to the project but it currently lacks a structure to manage these donations). Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Please rewrite << { ... } \\ { ... } >> construct
On Mon, Nov 8, 2010 at 12:46 PM, Xavier Scheuer wrote: > We have had a discussion one year ago about a project to rewrite the > << { ... } \\ { ... } >> Hi Xavier, isn't that the discussion I tried to sum up on http://code.google.com/p/lilypond/issues/detail?id=1316 ? Please repost your mail as a comment there, I think it will be more appropriate, useful and (possibly) efficient :-) Cheers, Valentin ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Please rewrite << { ... } \\ { ... } >> construct
Dear LilyPond developers, Kieren, We have had a discussion one year ago about a project to rewrite the << { ... } \\ { ... } >> so it behaves exactly like << { % continuation of the "main" Voice from outside the polyphony \voiceOne ... } \context Voice = "2" { \voiceTwo ... } >> \oneVoice That would kinda solve the issue that what is inside the << { ... } \\ { ... } >> construct is in different voices than the non-polyphonic voice from outside, thus forbidding slurs etc. from outside to inside the polyphonic passage. This is not well understood by users and it would really help if this could be solved. http://lists.gnu.org/archive/html/lilypond-devel/2009-09/msg00096.html Maybe I could add a suggestion (if it is possible from a development point of view, of course): I'd like the second voice to be named from first voice's name. For example, if first voice is called "PianoUpper", then the second voice created *within* the << \\ >> construct would be called "PianoUpper2". That would help for "Quoting other voices" or cued voice. Kieren thought it could be possible last time we spoke about this, i.e. 10 months ago. Thank you. Cheers, Xavier -- Xavier Scheuer ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond