Re: Please rewrite << { ... } \\ { ... } >> construct

2010-11-11 Thread David Kastrup
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

2010-11-10 Thread Graham Percival
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

2010-11-08 Thread Phil Holmes
"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

2010-11-08 Thread David Kastrup
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

2010-11-08 Thread Xavier Scheuer
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

2010-11-08 Thread Valentin Villenave
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

2010-11-08 Thread Xavier Scheuer
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