Re: The \\ construct for simultaneous voices
I invite you to search the archives for a patch from me. I posted some improvements (maybe last year?) for use with vocal music. Han Wen wanted something more general, which I started but became too busy to complete. I was going to have the C++ part combiner consult a state machine (defined in scheme) with state names corresponding to the list generated by \partcombine, whose nodes hold the names of output contexts to receive part A notes, part A rests, part B notes, etc, and whose edges hold the text to put out when a transition happens. Currently, for instrumental music, I'm using a modified copy of the partcombine scm (attached) which skips solo/a2 analysis, keeps unisons and close notes pointing the right directions, and combines simultaneous rests properly. There are still shortcomings involving multi-measure rests. (Please don't ask for a proper patch, as I have no time.) You'll also need something like this to combine voices with the different options: voicecombine = #(define-music-function (parser location part1 part2) (ly:music? ly:music?) (dfe-make-voice-combine-music parser (list part1 part2))) -- Dan part-combiner.scm Description: Binary data On 2009-09-13, at 19:18 , Anthony W. Youngman wrote: In message , Kieren MacMillan writes Hi Reinhold, Wol, et al: I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad choices the partcombiner makes). What say we make a serious effort at rewriting the partcombiner from the ground up? There are at least three of us who want and are willing to tackle the problem, learn/improve our Scheme as necessary, etc. I can't think of very many feature fixes that would have a bigger bang-for-the-buck. I'm game. My two problems are (1) finding time, and (2) I'll need a fair bit of hand-holding to start off with, I expect. I'm very much a procedurally trained programmer (C, Fortran, *decent* BASICs). Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
"Anthony W. Youngman" writes: > I'm game. My two problems are (1) finding time, and (2) I'll need a > fair bit of hand-holding to start off with, I expect. I'm very much a > procedurally trained programmer (C, Fortran, *decent* BASICs). You'll find that most of the "functional" claim in Scheme (and Lisp) is a lie in practice. It's mostly a different syntax, but the programming style is appallingly similar. C preprocessor programming, for example, is often "I can warp it to look like a function call". In Scheme and its ilk, pretty much everything looks like a function call without warping. And that's almost all. A functional programming style without global variables and states, like ((lambda (f n) (f f n)) (lambda(f n) (if (< n 1) 1 (* n (f f (- n 1) 5) is not something you'll find in Lilypond. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
> "Anthony" == Anthony W Youngman writes:
Anthony> I'm game. My two problems are (1) finding time, and (2) I'll
Anthony> need a fair bit of hand-holding to start off with, I
Anthony> expect. I'm very much a procedurally trained programmer (C,
Anthony> Fortran, *decent* BASICs).
In the meantime, using
TromboneOne=\relative c'' { }
TromboneTwo=\relative c'' {}
\score {
\context Staff = trombone <<
\context Voice = tromboneOne { \voiceOne \TromboneOne}
\context Voice = tromboneTwo { \voiceTwo \TromboneTwo}
>>
}
may do what you want.
Peter C
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
In message , Kieren MacMillan writes Hi Reinhold, Wol, et al: I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad choices the partcombiner makes). What say we make a serious effort at rewriting the partcombiner from the ground up? There are at least three of us who want and are willing to tackle the problem, learn/improve our Scheme as necessary, etc. I can't think of very many feature fixes that would have a bigger bang-for-the-buck. I'm game. My two problems are (1) finding time, and (2) I'll need a fair bit of hand-holding to start off with, I expect. I'm very much a procedurally trained programmer (C, Fortran, *decent* BASICs). Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Reinhold, Wol, et al: I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad choices the partcombiner makes). What say we make a serious effort at rewriting the partcombiner from the ground up? There are at least three of us who want and are willing to tackle the problem, learn/improve our Scheme as necessary, etc. I can't think of very many feature fixes that would have a bigger bang-for-the-buck. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
In message <200909140024.50780.reinh...@kainhofer.com>, Reinhold Kainhofer writes Am Sonntag, 13. September 2009 23:22:04 schrieb Anthony W. Youngman: If it hasn't been done, it sounds like it would be a good idea to try and combine the voice combining and part combining code with switches to say how much should be merged/dropped. I'll try and take a look (it'll probably be a good project to learn C++ :-) That would be a good project to learn scheme / guile. ;-) C++ won't bring you very far, since everything is implemented in scheme I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad choices the partcombiner makes). I've just found another glitch ... (although it's a slightly odd one). Again, it's rest-related. One part has r4\fermata, the other has r4. The part as printed is just r4. "Correcting" the second part to add the fermata does add the fermata to the printed part. And there's something funny about dynamics. Some dynamics print above the staff, some below. And some (despite being identical) print both. Weird. Oh well. I'm thinking I might separate the dynamics into their own voice. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 13. September 2009 23:22:04 schrieb Anthony W. Youngman: > If it hasn't been done, it sounds like it would be a good idea to try > and combine the voice combining and part combining code with switches to > say how much should be merged/dropped. I'll try and take a look (it'll > probably be a good project to learn C++ :-) That would be a good project to learn scheme / guile. ;-) C++ won't bring you very far, since everything is implemented in scheme I've been thinking about implementing something like that myself (basically controlling combined/split voices via context properties, overriding the bad choices the partcombiner makes). Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKrXEwTqjEwhXvPN0RAoIMAJwMt3oBrECiaPjjpqKF3jPtZhsJRQCdHtOD /XbFkctgVoPYPWW8O7WvjcE= =kW27 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
In message , James E. Bailey writes On 13.09.2009, at 17:59, Anthony W. Youngman wrote: Using partcombine, I think it's doing its job properly. But the result is a mass of "a2", "Solo I", "Solo II" which I don't want. I'd like both parts printed in full, with only "a2" where they're both playing the same. I haven't tried it, but under selected snippets for partcombine, there's a bit about combining two parts on the same staff that says that the property printPartCombineTexts can be set to "false". Shouldn't that get rid of the solo/a2 texts? James E. Bailey But (I suspect, I haven't tried it) it will probably also lose the associated rests. partcombine loses them which is fine if it prints the solo/a2 stuff, but not if it doesn't. If it hasn't been done, it sounds like it would be a good idea to try and combine the voice combining and part combining code with switches to say how much should be merged/dropped. I'll try and take a look (it'll probably be a good project to learn C++ :-) but as usual my problem is finding time. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
On 13.09.2009, at 17:59, Anthony W. Youngman wrote: Using partcombine, I think it's doing its job properly. But the result is a mass of "a2", "Solo I", "Solo II" which I don't want. I'd like both parts printed in full, with only "a2" where they're both playing the same. I haven't tried it, but under selected snippets for partcombine, there's a bit about combining two parts on the same staff that says that the property printPartCombineTexts can be set to "false". Shouldn't that get rid of the solo/a2 texts? James E. Bailey ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
In message , Kieren
MacMillan writes
Hi all,
\\ is quite more convenient than explicit voices and thus an important
idiom that makes Lilypond friendlier to the user.
Yes, but as previously discussed, the confusion it (ultimately) causes is a
poor trade-off. The whole problem would be solved if \\ Did The Right Thing,
i.e.
<< { musicA } \\ { musicB }>>
would automagically expand to
<< { \voiceOne musicA } \context Voice = "2" { \voiceTwo musicB }>>
\oneVoice
I can take this on as my next Frog task, if it requires no C++. Then, the
documentation can simply use \\ early on (e.g., in the LM), and show what
it does later.
Dunno if this will require some C++, but I've just tried using \\
instead of partcombine, and neither really do what I want. \\ looked
awful.
I've got two parts - Trombone 1 and Trombone 2. On the music I've got,
they're printed on one piece of music. Obviously I want to enter them as
two separate music variables, so I can print them as one part or two as
appropriate (and I also want, at some point, to print condensed scores
...)
If I use \\, it sort of does what I want - prints the two parts on the
same staff. But it's a right mess - so far I've discovered that if you
have multi-bar rests it just double prints the numbers one above the
other :-( And if one voice ends just before the other has a multibar
rest, the barcount doesn't print. Don't know if there are any other
oddities.
Using partcombine, I think it's doing its job properly. But the result
is a mass of "a2", "Solo I", "Solo II" which I don't want. I'd like both
parts printed in full, with only "a2" where they're both playing the
same.
Okay, I'm trying to find time to investigate this for myself, but if
somebody else is already looking at this sort of thing, I'll just throw
this into the mix for them...
Cheers,
Wol
--
Anthony W. Youngman - anth...@thewolery.demon.co.uk
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Kieren MacMillan wrote Tuesday, September 08, 2009 5:08 PM Does this mean you don't need me to immediately rework how \\ voicifies? I think I'll go ahead with the reordering anyway, although it might take a while, as I have limited time at present. So let's decouple the rewrite of docs and voicify. I'll bear in mind that the details of \\ might change a little, but as I shall downplay \\ it shouldn't be a problem. Would that still be a good thing regardless of how the docs are written? Yes, I think making it "do the right thing", i.e add a second (and third, etc) voice to the main voice) is worth-while. It fits better with its most useful role, which is to add a voice to a passage for a short while. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Trevor, I now think teaching the \new Voice method at the start gives a better and sounder grounding. I've always thought so... Does this mean you don't need me to immediately rework how \\ voicifies? Would that still be a good thing regardless of how the docs are written? Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Kieren MacMillan wrote Monday, September 07, 2009 7:40 PM which works fine, if I understand what you want. So I was wondering if Trevor was referring to something else... Yes, I was thinking more of \lyricsto, which needs a named context, and perhaps SATB on two staves. I originally placed the \\ construct first as it seemed simpler, but too many people adopted it as the only or at least the recommended way of writing concurrent music, only to find difficulties when they moved on to more complex scores. The \\ construct has its use, but I now think teaching the \new Voice method at the start gives a better and sounder grounding. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Karl,
or when there are lyrics to assign.
What do you mean here?
Do you mean lyrics to assign to the *second voice* (since the first
voice assignment would be automagic)?
Try:
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << g \\ d >> g2 }
}
\addlyrics{ a b c }
}
No voice in the << \\ >> section gets any lyrics here.
My point was, if \\ did the right thing, your example would
automagically expand to become
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << { \voiceOne g } \context Voice =
"2" { \voiceTwo d } >> \oneVoice g2 }
}
\addlyrics{ a b c }
}
which works fine, if I understand what you want. So I was wondering
if Trevor was referring to something else...
Regards,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
...
> > or when there are lyrics to assign.
> What do you mean here?
> Do you mean lyrics to assign to the *second voice* (since the first
> voice assignment would be automagic)?
Try:
\version "2.13.0"
\score {
\new Staff {
\time 4/4
\relative g' { g4 << g \\ d >> g2 }
}
\addlyrics{ a b c }
}
No voice in the << \\ >> section gets any lyrics here.
Regards,
/Karl
---
Karl HammarAspö Data k...@aspodata.se
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Hi Trevor, This change would help, but I don't think it would solve the whole problem. You'd still have an implied name for the second context, so it doesn't work in more than one staff Probably true... I'll have to examine the ramifications. or when there are lyrics to assign. What do you mean here? Do you mean lyrics to assign to the *second voice* (since the first voice assignment would be automagic)? Thanks, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
Kieren MacMillan wrote Sunday, September 06, 2009 3:34 PM
\\ is quite more convenient than explicit voices and thus an
important
idiom that makes Lilypond friendlier to the user.
Yes, but as previously discussed, the confusion it (ultimately)
causes is a poor
trade-off. The whole problem would be solved if \\ Did The Right
Thing, i.e.
<< { musicA } \\ { musicB }>>
would automagically expand to
<< { \voiceOne musicA } \context Voice = "2" { \voiceTwo
musicB }>> \oneVoice
This change would help, but I don't think it
would solve the whole problem. You'd still have
an implied name for the second context, so it
doesn't work in more than one staff, or when
there are lyrics to assign.
I can take this on as my next Frog task, if it requires no C++.
Then, the
documentation can simply use \\ early on (e.g., in the LM), and
show what it does > later.
I think this is implemented in voicify-music
in scm/music-functions.scm.
I'll hold fire on the re-documentation a bit
longer until you've had a look at this.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: The \\ construct for simultaneous voices
Hi all,
> \\ is quite more convenient than explicit voices and thus an important
> idiom that makes Lilypond friendlier to the user.
Yes, but as previously discussed, the confusion it (ultimately) causes is a
poor trade-off. The whole problem would be solved if \\ Did The Right Thing,
i.e.
<< { musicA } \\ { musicB }>>
would automagically expand to
<< { \voiceOne musicA } \context Voice = "2" { \voiceTwo musicB }>> \oneVoice
I can take this on as my next Frog task, if it requires no C++. Then, the
documentation can simply use \\ early on (e.g., in the LM), and show what it
does later.
Cheers,Kieren.___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The \\ construct for simultaneous voices
"Trevor Daniels" writes: > I've finally got around to thinking about the introduction to parallel > voices in the Learning Manual - currently sections 3.2.1 and 3.2.2. > You'll remember the many discussions about the two constructs - > explicit voices and the \\ construct, and the > final agreement to introduce explicit voices first, reversing the > present order. I'm now minded to remove mention of the \\ construct > from the LM altogether, except for a brief reference to the topic in > the NR. This seems the simplest way of avoiding the confusion that > frequently arises with the current approach. > > Before I start merging 3.2.1 and 3.2.2 to do this I'd welcome your > comments. \\ is quite more convenient than explicit voices and thus an important idiom that makes Lilypond friendlier to the user. I would tend to introduce its use first, then mention what it does behind the scene and when you would rather use explicit voices (and then point to the requisite section where \\ might be briefly explained in the context of explicit voices as well, like "We already mentioned how to do two-voice parts with \\, let's take a look at what this actually does, now that we know how voices are instantiated"). But since it can be used with less brain investment (naming something is always a chore), it belongs earlier in the introduction to the hopeful newcomer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
The \\ construct for simultaneous voices
I've finally got around to thinking about the introduction to parallel voices in the Learning Manual - currently sections 3.2.1 and 3.2.2. You'll remember the many discussions about the two constructs - explicit voices and the \\ construct, and the final agreement to introduce explicit voices first, reversing the present order. I'm now minded to remove mention of the \\ construct from the LM altogether, except for a brief reference to the topic in the NR. This seems the simplest way of avoiding the confusion that frequently arises with the current approach. Before I start merging 3.2.1 and 3.2.2 to do this I'd welcome your comments. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
