Reviewers: ,
Description:
Part combiner: Ignore skips coinciding with rests within a part
Please review this at https://codereview.appspot.com/240790043/
Affected files (+19, -14 lines):
M input/regression/part-combine-silence-mixed.ly
M scm/part-combiner.scm
Index: input/regression/part
https://codereview.appspot.com/228700043/diff/40001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/228700043/diff/40001/ly/music-functions-init.ly#newcode1135
ly/music-functions-init.ly:1135: \context Voice = "one" \with {
#one-context-settings
Reviewers: ,
Description:
Part combiner: generate mark events in scheme rather than C++
Please review this at https://codereview.appspot.com/228700043/
Affected files (+93, -66 lines):
M lily/part-combine-iterator.cc
M ly/engraver-init.ly
M ly/music-functions-init.ly
M scm/part
Dear Kristof,
Am 2015-04-20 um 11:16 schrieb Kristof Bastiaensen:
I have a hard time to believe that anyone actually uses the part combiner
seriously, but please prove me wrong.
I'm using the partcombiner with all my orchestral scores. For an example
see my edition of Schubert's St
Hi Dan,
It's been a long time I wrote this code, so it may take me some time to
incorporate it
and produce samples. I can do this if there is interest in my
part-combiner.
Those samples wouldn't show the heuristics I used though, for that you'd
have to look into the code comments
On 2015/04/19 18:29:18, Keith wrote:
https://codereview.appspot.com/226430043/diff/40001/lily/part-combine-iterator.cc#oldcode396
lily/part-combine-iterator.cc:396: SCM lst = get_music
()->get_property
("elements");
Later, it would be good to have PartCombineMusic contain a
ContextSpecdMusic
On 2015/04/19 18:29:18, Keith wrote:
Given that \displayLilyMusic does not reverse-engineer \voiceXxx, it
seems it
would take some work to teach it to reverse-engineer
\partcombineUp/Down
In patch set 3, I managed to fake it by continuing to rely on the
'direction property just for \displayLi
Looks good to me.
https://codereview.appspot.com/226430043/diff/20001/input/regression/display-lily-tests.ly
File input/regression/display-lily-tests.ly (right):
https://codereview.appspot.com/226430043/diff/20001/input/regression/display-lily-tests.ly#newcode224
input/regression/display-lily-t
On 2015/04/19 11:55:40, dak wrote:
On 2015/04/19 11:40:31, Dan Eble wrote:
> Call \displayLilyMusic output "NOT A BUG"
Why would that be not a bug?
That was my interpretation of Valentin's feedback in
https://code.google.com/p/lilypond/issues/detail?id=4348#c5 . If you
want something else,
> Comment #7 on issue 4345 by kristofbastiaensen: Patch: Part combiner: allow
> a2 chords
> https://code.google.com/p/lilypond/issues/detail?id=4345
>
> I've put up my code on github: https://github.com/kuribas/part-combiner
>
> I honestly don't understand why the
On 2015/04/19 11:40:31, Dan Eble wrote:
Call \displayLilyMusic output "NOT A BUG"
Why would that be not a bug?
https://codereview.appspot.com/226430043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/li
Reviewers: ,
Description:
Part combiner: move direction handling out of iterator
Please review this at https://codereview.appspot.com/226430043/
Affected files (+18, -67 lines):
M lily/part-combine-iterator.cc
M ly/music-functions-init.ly
M scm/part-combiner.scm
Index: lily/part
Reviewers: ,
Description:
Part combiner: allow a2 chords
Please review this at https://codereview.appspot.com/228110043/
Affected files (+92, -51 lines):
A input/regression/part-combine-strings.ly
M scm/part-combiner.scm
___
lilypond-devel
Keith OHara writes:
> Urs Liska openlilylib.org> writes:
>
>> Keith wrote:
>> > I suggest looking over the existing partcombine bugs, and orchestral
>> > scores, to see what problems generally need solving.
>
>> If there's anything I can do to help (without understanding more than
>> basic Sch
Urs Liska openlilylib.org> writes:
> Keith wrote:
> > I suggest looking over the existing partcombine bugs, and orchestral
> > scores, to see what problems generally need solving.
> If there's anything I can do to help (without understanding more than
> basic Scheme and without any option to h
Hi Dan and Keith,
I just wanted to let you know that I'm following your discussion with
interest, although I don't understand most of it. Any improvements in
the partcombiner are highly welcome and appreciated.
If there's anything I can do to help (without understanding more than
basic Schem
On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble wrote:
I have a question. If the Scheme code produces something like (‘apart “one”
“two”) with “one” and “two” being the chosen output voices for the input parts
at the moment, would it make sense to write those decisions back to the input
parts
On Nov 30, 2014, at 01:17 , Keith OHara wrote:
>
> If \partcombine can only assume part of the responsibility for routing
> decisions, though, I seems cleaner to enhance the set of split-state tags to
> completely describe the results of \partcombine's analysis, rather than tell
> part_combine
"Keith OHara" writes:
> I am eager for either nameable outputs from \partcombine, or
> VoiceGroup, in LilyPond so we can have a stable and functional
> \partcombineUp/Down.
VoiceGroup won't help with merging multiple outputs into one context.
We'd need something like
\context Voice = "unisilen
On Sat, 29 Nov 2014 18:09:34 -0800, Dan Eble wrote:
On Nov 29, 2014, at 18:48 , Keith OHara wrote:
Oh, so you meant let the Scheme portion dictate to partcombine_iterator which
_input_ voice, as it iterates the music expression produced by \partcombine, to
use.
My reasoning probably need
On Nov 29, 2014, at 18:48 , Keith OHara wrote:
>
> Oh, so you meant let the Scheme portion dictate to partcombine_iterator which
> _input_ voice, as it iterates the music expression produced by \partcombine,
> to use.
My reasoning probably needs more clarification. The iterator takes sequence
On Nov 29, 2014, at 18:48 , Keith OHara wrote:
>
> On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble wrote:
>
>> This suggestion was motivated by recent work on cases in which both parts
>> are resting. If the desired action is to route only one of the voices to the
>> shared voice, the Scheme hal
On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble wrote:
On Nov 29, 2014, at 16:46 , Keith OHara wrote:
Dan Eble faithful.be> writes:
I would like the Scheme portion of the part
combiner to dictate the names of the voices to use at every moment.
Simply letting us specify the Voices _on
On Nov 29, 2014, at 16:46 , Keith OHara wrote:
>
> Dan Eble faithful.be> writes:
>
>> I would like the Scheme portion of the part
>> combiner to dictate the names of the voices to use at every moment.
>
> Simply letting us specify the Voices _once_ for the
s that music properties are the only
places to put it. Maybe one property that takes the full list of context
names...
> I would like the Scheme portion of the part
> combiner to dictate the names of the voices to use at every moment.
Simply letting us specify the Voices _once_ for the whole outp
To those familiar with the part combiner:
I would like to break the rigid link between the split states (apart,
unisilence, etc.) and the names of the voices into which the
Part_combine_iterator routes events. I would like the Scheme portion of the
part combiner to dictate the names of the
I’ve been using a modified determine-split-list scheme function for a while and
I’d like to contribute it for use by others. I have just started to enumerate
regression test cases, but before I get very far, I would appreciate some
feedback on the approach so that I don’t waste time on things t
https://codereview.appspot.com/13302048/diff/3001/input/regression/part-combine-mmrest-apart.ly
File input/regression/part-combine-mmrest-apart.ly (right):
https://codereview.appspot.com/13302048/diff/3001/input/regression/part-combine-mmrest-apart.ly#newcode5
input/regression/part-combine-mmres
texidoc string comment nit-pick, otherwise LGTM.
https://codereview.appspot.com/13302048/diff/3001/input/regression/part-combine-mmrest-apart.ly
File input/regression/part-combine-mmrest-apart.ly (right):
https://codereview.appspot.com/13302048/diff/3001/input/regression/part-combine-mmrest-a
http://codereview.appspot.com/4132045/diff/1/Documentation/notation/simultaneous.itely
File Documentation/notation/simultaneous.itely (right):
http://codereview.appspot.com/4132045/diff/1/Documentation/notation/simultaneous.itely#newcode842
Documentation/notation/simultaneous.itely:842: if one o
While workign on some real-world score, I ran into another problem with part-
combining that I don't know how to solve:
Sometimes in a part-combined staff, after a multi-measure rest, one of the two
instruments sets in a little earlier than the second one. During that measure,
the second instrum
hich voice contexts to use for each state
> that is created by determine-split-list? Something like ((apart . ("one"
> "two")) (solo1 . ("one" ())) ...) ? Or callbacks? It might not be that
> simple, since the part combiner does some things other than just
ted by determine-split-list? Something like
((apart . ("one" "two")) (solo1 . ("one" ())) ...) ? Or callbacks?
It might not be that simple, since the part combiner does some things
other than just switching contexts around.
I was originally trying to change as
On Sun, Sep 7, 2008 at 7:13 PM, Dan Eble <[EMAIL PROTECTED]> wrote:
>> If we go through with this (which I doubt), the handles_ should be a
>> vector<> so we get bounds checking.
>
> No argument there, but I don't understand what you mean by "which I doubt".
I doubt that we should have any sort of
If we go through with this (which I doubt), the handles_ should be a
vector<> so we get bounds checking.
No argument there, but I don't understand what you mean by "which I
doubt".
1. why is this a music property? Since it is all about contexts, I
think a context property would be better,
rt2 = construct_child ("apart-two-context-id");
+ ctx_.solo1 = construct_child ("solo-one-context-id");
+ ctx_.solo2 = construct_child ("solo-two-context-id");
+ (apart-one-context-id ,string?
+ "Name of up-facing Voice
span1 span2 measurepos
measurelimits)))
(fix-rests-in-measures! types #f #f)
(let loop ()
(if (fix-blocks! types #f #t music-end)
(if (fix-rests-in-measures! types #f #f)
loop)))
(synthesize-types types)))
> >
comments that don't make sense, I would gladly modify
them.
To me, the new code reads like a long list of small function
definitions. It's difficult to tell how the different parts are related.
In addition, the whole design of the part-combiner will be trashed
anyway when we hav
Kristof Bastiaensen writes:
> It doesn't have as far as I know (as much as that is possible to say
> about new code). The regression tests that came with the previous
> part-combiner will not work anymore, but that is deliberatly.
That need not be a problem, as long as it is docu
could simplify the whole thing.
If there are comments that don't make sense, I would gladly modify
them.
> In addition, the whole design of the part-combiner will be trashed
> anyway when we have sensible music stream datastructures (see the
> mail in lilypond-devel by Erik S)
>
Hi,
I'd like to ask how the part-combiner is progressing. I see that my
patch isn't committed yet, so I wonder if there is a reason to delay
the patch. The patch should be standalone, it shouldn't break
existing code. There could be unsuspected bugs, but then, that's
Kristof Bastiaensen wrote:
However, then I have to understand the code, and I'm missing the big
picture of what is happening. Maybe you could write a short overview of
the structure of your implementation? In particular, what data do you
use, and how do you store it?
Actually I have only ch
At Sat, 09 Jul 2005 10:20:01 +0200,
Han-Wen Nienhuys wrote:
>
> Hi,
>
> it's Officially Highly Cool that you have managed to rewrite the part
> combiner. I would love to help solve the remaining problems with it.
>
That's very nice to hear!
> However, then I h
[EMAIL PROTECTED] wrote:
Hi,
I finished the scheme part of the part-combiner. Attached is the patch.
There are still bugs in the C part which I cannot solve:
- When there are two voices unisilence, one of them a multimeasure rest,
and the other a smaller rest, than sometimes the multimeasure
* ly/declarations-init.ly: Set the properties to record for the
part-combiner.
* scm/part-combiner.scm: Complete rewrite of the part-combiner.
* lily/moment-scheme.cc: Added the scheme function ly:sub-moment
to subtract moments.
* lily/recording-group-engra
> I finished the scheme part of the part-combiner. Attached is the patch.
Great, thanks. Do you have an example of what cases/bugs have been
fixed? Do the regression tests still work?
> There are still bugs in the C part which I cannot solve:
It would be nice to create small snippe
Hi,
I finished the scheme part of the part-combiner. Attached is the patch.
There are still bugs in the C part which I cannot solve:
- When there are two voices unisilence, one of them a multimeasure rest,
and the other a smaller rest, than sometimes the multimeasure rest
swallows the other
[EMAIL PROTECTED] wrote:
Ok, I have added the process_music() method. However, it doesn't seem
to
get run. I saw that the other engravers derive from Engraver, but
Recording_group_engraver from Engraver_group_engraver. Perhaps that has
anything to do with it?
it should get run from the tg->*
Carter Brey <[EMAIL PROTECTED]> writes:
[cc: devel list]
> Yes, it would be great if texts could avoid any staff grobs by
> default. I experimented with two kinds of padding, as you can see.
Han-Wen and I discussed this a bit; what would needed to be done is to
make a staff-text-engraver, that m
49 matches
Mail list logo
