Re: Yet another 2 patches for music streams
Erik Sandberg schreef: On Monday 22 May 2006 11:47, Han-Wen Nienhuys wrote: Erik Sandberg schreef: + if (start_moment_.main_part_.is_infinity () && start_moment_ < 0) +start_moment_ = now; + I don't understand. What is this for? I remember now. When I streamified Score::Prepare, I introduced a new convention: Before iteration starts, the current moment is set to -inf. (I think it was 0 before, which is confusing if a piece starts with grace notes). With this convention, the above lines are required because the part-combiner's start_moment_ is set in construct_children, which might be called before iteration starts. I suspect this fixes a bug that nobody has found yet. ok, sounds good. Can you document in a comment? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
On Monday 22 May 2006 11:47, Han-Wen Nienhuys wrote: > Erik Sandberg schreef: > > + if (start_moment_.main_part_.is_infinity () && start_moment_ < 0) > > +start_moment_ = now; > > + > > I don't understand. What is this for? I remember now. When I streamified Score::Prepare, I introduced a new convention: Before iteration starts, the current moment is set to -inf. (I think it was 0 before, which is confusing if a piece starts with grace notes). With this convention, the above lines are required because the part-combiner's start_moment_ is set in construct_children, which might be called before iteration starts. I suspect this fixes a bug that nobody has found yet. -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Erik Sandberg schreef: >> On Tuesday 23 May 2006 13:01, Han-Wen Nienhuys wrote: >>> *Please commit the 1st patch after lyricsto works again. >> I have committed now. There are two problems still, whihc I ignored >> (they do not affect make web): >> - input/no-notation/denneboom.ly uses \oldaddlyrics. However, it >> didn't work before my patch either, so I guess the file is obsolete >> anyways > > yes, removed. > >> - input/no-notation/display-lily-tests.ly also contains an >> oldaddlyrics reference, but lily fails on the file anyway. > > Hmm. Nicolas? it should be fixed now ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Erik Sandberg schreef:
On Tuesday 23 May 2006 13:01, Han-Wen Nienhuys wrote:
*Please commit the 1st patch after lyricsto works again.
I have committed now. There are two problems still, whihc I ignored (they do
not affect make web):
- input/no-notation/denneboom.ly uses \oldaddlyrics. However, it didn't work
before my patch either, so I guess the file is obsolete anyways
- input/no-notation/display-lily-tests.ly also contains an oldaddlyrics
reference, but lily fails on the file anyway.
Graham, I have changed the syntax of \applyOutput; instead of \context Staff
\applyOutput {..} you should now write \applyoutput #'Staff {..} . The manual
might be affected by this change.
Erik,
I asked you to check "make web". The manual is part of that, now it
barfs with
/Users/lilytest/testing/gub/target/darwin-ppc/build/lilypond-HEAD/Documentation/user/out-www/lily-1173155923.ly:70:3:
error: syntax error, unexpected '<'
/Users/lilytest/testing/gub/target/darwin-ppc/build/lilypond-HEAD/Documentation/user/out-www/lily-1173155923.ly:73:50:
error: syntax error, unexpected RESTNAME
\repeat unfold 5 { \applyOutput #mc-squared
s8 }
Can you actually check "make web-clean ; make web", even for the tiniest
change that you commit?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Erik Sandberg schreef: On Tuesday 23 May 2006 13:01, Han-Wen Nienhuys wrote: *Please commit the 1st patch after lyricsto works again. I have committed now. There are two problems still, whihc I ignored (they do not affect make web): - input/no-notation/denneboom.ly uses \oldaddlyrics. However, it didn't work before my patch either, so I guess the file is obsolete anyways yes, removed. - input/no-notation/display-lily-tests.ly also contains an oldaddlyrics reference, but lily fails on the file anyway. Hmm. Nicolas? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
On Tuesday 23 May 2006 13:01, Han-Wen Nienhuys wrote:
> *Please commit the 1st patch after lyricsto works again.
I have committed now. There are two problems still, whihc I ignored (they do
not affect make web):
- input/no-notation/denneboom.ly uses \oldaddlyrics. However, it didn't work
before my patch either, so I guess the file is obsolete anyways
- input/no-notation/display-lily-tests.ly also contains an oldaddlyrics
reference, but lily fails on the file anyway.
Graham, I have changed the syntax of \applyOutput; instead of \context Staff
\applyOutput {..} you should now write \applyoutput #'Staff {..} . The manual
might be affected by this change.
--
Erik
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Hi,
I've made the suggested modifications to the first patch. In order to proceed,
I had to do some additional modifications:
- Music_iterator::try_music now autodescends to a bottom context, and the
method has been renamed to report_music.
- Event_iterator has been introduced. Music events are iterated by
event_iterator by default (was Simple_music_iterator before). I don't think
Event_chord_iterator adds anything over Simultaneous_music_iterator (apart
from speed, possibly), so it can probably be junked.
- I have junked:
- old-lyric-combine
- output-property-iterator
- try_music_in_children everywhere
I'll probably be away from CVS access from Thursday to Monday or so, so it
would be convenient for me to commit these changes tomorrow (more-or-less all
remaining work depends on this megapatch).
A new todo element popped up also:
It should be fairly easy to create a Scheme_sequential_iterator, where the
get_music_list method is customised from Scheme. This can be used to softcode
Chord_tremolo_iterator, Percent_iterator, Sequential_music_iterator and
Time_scaled_music_iterator.
Known issue: \lyricsto is slightly broken (fails on morgenlied.ly), I haven't
had the time to check it up but hope to fix it soon.
> > - (tremolo-type ,integer? "")
> > + (tremolo-type ,integer? "speed of tremolo, e.g. 16 for c4:16")
>
> hmm. That sucks, we should store the negative log (-4 for 16) rather
> than 16.
I also haven't made this change yet
--
Erik
? lily/On
? lily/busy-playing-listener.cc
? lily/event-iterator.cc
? lily/foo.pdf
? lily/foo.ps
? lily/lilypond
? lily/lilypond.gdt
? lily/lilypond.gpr
? lily/out
? lily/out-scons
? lily/out-www
? lily/include/.sconsign
? lily/include/busy-playing-listener.hh
? lily/include/event-iterator.hh
? lily/include/out
? lily/include/out-www
? ly/out
? ly/out-www
? scm/out
? scm/out-www
Index: lily/chord-tremolo-engraver.cc
===
RCS file: /sources/lilypond/lilypond/lily/chord-tremolo-engraver.cc,v
retrieving revision 1.99
diff -u -r1.99 chord-tremolo-engraver.cc
--- lily/chord-tremolo-engraver.cc 7 May 2006 19:51:11 - 1.99
+++ lily/chord-tremolo-engraver.cc 23 May 2006 06:36:58 -
@@ -4,12 +4,12 @@
source file of the GNU LilyPond music typesetter
(c) 2000--2006 Han-Wen Nienhuys <[EMAIL PROTECTED]>
+ Erik Sandberg <[EMAIL PROTECTED]>
*/
#include "math.h" // ceil
#include "beam.hh"
-#include "chord-tremolo-iterator.hh"
#include "engraver-group.hh"
#include "international.hh"
#include "item.hh"
@@ -39,92 +39,72 @@
*/
class Chord_tremolo_engraver : public Engraver
{
- void typeset_beam ();
TRANSLATOR_DECLARATIONS (Chord_tremolo_engraver);
protected:
Music *repeat_;
- /// moment (global time) where beam started.
- Moment start_mom_;
- Moment stop_mom_;
int flags_;
- int total_duration_flags_;
+ // number of beams for short tremolos
+ int expected_beam_count_;
+ // current direction of beam (first RIGHT, then LEFT)
+ Direction beam_dir_;
- /// location within measure where beam started.
- Moment beam_start_location_;
-
- bool body_is_sequential_;
Spanner *beam_;
- Spanner *finished_beam_;
- Item *stem_tremolo_;
protected:
virtual void finalize ();
virtual bool try_music (Music *);
- void stop_translation_timestep ();
- void start_translation_timestep ();
void process_music ();
DECLARE_ACKNOWLEDGER (stem);
};
Chord_tremolo_engraver::Chord_tremolo_engraver ()
{
- beam_ = finished_beam_ = 0;
+ beam_ = 0;
repeat_ = 0;
flags_ = 0;
- stem_tremolo_ = 0;
- body_is_sequential_ = false;
+ expected_beam_count_ = 0;
+ beam_dir_ = CENTER;
}
bool
Chord_tremolo_engraver::try_music (Music *m)
{
- if (m->is_mus_type ("repeated-music")
- && m->get_property ("iterator-ctor") == Chord_tremolo_iterator::constructor_proc
- && !repeat_)
+ if (m->is_mus_type ("tremolo-span-event"))
{
- Moment l = m->get_length ();
- repeat_ = m;
- start_mom_ = now_mom ();
- stop_mom_ = start_mom_ + l;
-
- Music *body = Repeated_music::body (m);
- body_is_sequential_ = body->is_mus_type ("sequential-music");
-
- int elt_count = body_is_sequential_ ? scm_ilength (body->get_property ("elements")) : 1;
-
- if (body_is_sequential_ && elt_count != 2)
- m->origin ()->warning (_f ("expect 2 elements for chord tremolo, found %d", elt_count));
-
- if (elt_count <= 0)
- elt_count = 1;
-
- Rational total_dur = l.main_part_;
- Rational note_dur = total_dur / Rational (elt_count * Repeated_music::repeat_count (repeat_));
-
- total_duration_flags_ = max (0, (intlog2 (total_dur.den ()) - 2));
-
- flags_ = intlog2 (note_dur.den ()) -2;
-
+ Direction span_dir = to_dir (m->get_property ("span-direction"));
+ if (span_dir == START)
+ {
+ repeat_ = m;
+ int type = scm_to_int (m->get_property ("tremolo-type"));
+ /* e.g. 1 for type 8, 2 for type 16 */
+ flags_ = in
Re: Yet another 2 patches for music streams
Hi,
On Mon, 22 May 2006, Erik Sandberg wrote:
> On Monday 22 May 2006 17:43, Johannes Schindelin wrote:
> > > You might want to experiment with some of the newer VC systems. Someone
> > > on the list mirrors lilypond CVS with GIT.
> >
> > I do.
> >
> > If you are interested, I can make it public.
> >
> > At the moment, I track the CVS every morning (Greenwich time).
>
> That sounds great, if it's not too much work for you. Can one perform cvs
> commits and GIT updates from the same source dir?
The basic commands are very similar to CVS. IMHO the biggest three
differences are:
- no server needed ("git commit" commits to the .git directory)
- no "cvs update", as there can be many servers, but
"git fetch "
- you can switch branches easily by "git checkout "
So, typically I just update with
git fetch origin
which updates my origin branch to what was in CVS this morning. Then, I
just create a throw-away branch to hack on lilypond:
git checkout -b wonderfulNewWork origin
This sets up a branch "wonderfulNewWork" starting at the HEAD of "origin".
Now I hack on lilypond as much as I want. At the same mile-stones as with
CVS, I commit with
git commit -a -m "a short comment to remember what I did"
The "-a" means "all changes". If I were to commit only the changes to a
couple of files, it would do
git commit -m "some other comment" GNUmakefile flower/random.cxx
After a couple of days of work, I do the equivalent to "cvs update":
git pull origin
Note the "pull", not "fetch". It means to pull the "origin" branch, and
merge it into the current branch. Then I get the patch with
git diff origin > my.patch
Actually, you can do more quite cool things with git. For example, you can
look at the history with "git log". And if you want to see the patches
right away, do "git log -p" to see the patch after each commit. To do that
with the branch "origin" instead of the current one, do
"git log -p origin".
You can use the "pickaxe" to search when a function or variable or
whatever was added: "git log -Sthefunction" will show you only the commits
where the patch contains "thefunction". If you know which file contains
it, you can make that even faster with "git log -Sthefunction
that/file.c".
Of course, there is at least one down-side, too. Since there is no central
server, you actually have all the history in the .git folder. In packed
format this means about 55 megabyte for lilypond.
Ah, and the most important thing: you can clone the initial repository by
git clone http://wbgn013.biozentrum.uni-wuerzburg.de/lilypond.git
This downloads the 55meg and sets up a local clone in the folder
"lilypond". Please be nice to the server...
Ciao,
Dscho
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
On Monday 22 May 2006 17:43, Johannes Schindelin wrote: > > You might want to experiment with some of the newer VC systems. Someone > > on the list mirrors lilypond CVS with GIT. > > I do. > > If you are interested, I can make it public. > > At the moment, I track the CVS every morning (Greenwich time). That sounds great, if it's not too much work for you. Can one perform cvs commits and GIT updates from the same source dir? (I had a quick look on the field of revision control systems; currently svn, darcs and git look like the best choices. I haven't decided which system to use yet.) -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Hi, On Mon, 22 May 2006, Han-Wen Nienhuys wrote: > Erik Sandberg schreef: > > > Also, in general, I think it should be possible to split patches up > > > further, eg. the tremolo stuff seems independent of the > > > partcombine/lyriccombine stuff. > > > > A problem is my limited internet access. I can cvs diff very seldom; I > > often work several days on lily between the diffs. This makes it > > difficult/troublesome to keep patches atomic. > > > > Currently I keep 3 copies of the lily tree, so I can maintain 2 > > independent diff branches + one unmodified version; this already leads > > to problems (the tremolo stuff was first supposed to go into branch 2, > > but was accidentally added to branch 1 instead). > > You might want to experiment with some of the newer VC systems. Someone > on the list mirrors lilypond CVS with GIT. I do. If you are interested, I can make it public. At the moment, I track the CVS every morning (Greenwich time). Ciao, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Erik Sandberg schreef: > I think the proper way is to make it a music macro; is it OK to keep > it a music function until music macros exist? (also, the music > function code attempts to signal errors when \once is used in the > wrong place, so from a user's point of view, little changes) Why do you want to make it a macro? It removes a rule from the parser, and it makes it possible to reuse \once for future commands where it's relevant. Because \once is tied to property settings, \set #'foo=#bar translates into somethign like (property-operation 'set '() 'foo 'bar) and \once \set #'foo=#bar would naturally translates into something like (property-operation 'set '() 'foo 'bar #t) i.e., it's natural to view \once as operating on the syntax. (I realise now that I can achieve the same inside parser by shuffling around rules a bit, but I don't see any advantage) I don't see how you can apply to anything else besides property settings, and that's exactly why I want to keep it with property settings. Making it a macro, which is processed at a later stage sounds like a fragile solution to me. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
On 5/22/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: Erik Sandberg schreef: > I think the proper way is to make it a music macro; is it OK to keep > it a music function until music macros exist? (also, the music > function code attempts to signal errors when \once is used in the > wrong place, so from a user's point of view, little changes) Why do you want to make it a macro? It removes a rule from the parser, and it makes it possible to reuse \once for future commands where it's relevant. Because \once is tied to property settings, \set #'foo=#bar translates into somethign like (property-operation 'set '() 'foo 'bar) and \once \set #'foo=#bar would naturally translates into something like (property-operation 'set '() 'foo 'bar #t) i.e., it's natural to view \once as operating on the syntax. (I realise now that I can achieve the same inside parser by shuffling around rules a bit, but I don't see any advantage) Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
Erik Sandberg schreef:
Also, in general, I think it should be possible to split patches up
further, eg. the tremolo stuff seems independent of the
partcombine/lyriccombine stuff.
A problem is my limited internet access. I can cvs diff very seldom; I
often work several days on lily between the diffs. This makes it
difficult/troublesome to keep patches atomic.
Currently I keep 3 copies of the lily tree, so I can maintain 2
independent diff branches + one unmodified version; this already leads
to problems (the tremolo stuff was first supposed to go into branch 2,
but was accidentally added to branch 1 instead).
You might want to experiment with some of the newer VC systems. Someone
on the list mirrors lilypond CVS with GIT.
>+ dir_ = RIGHT;
>+ }
>+ if (dir == STOP)
>+ {
They don't represent the same thing. RIGHT means that the right
beam-count is modified, STOP means that an event stops a spanner.
I know they don't, that's why I suggest to use different names.
> + SCM tremolo_symbol = ly_symbol2scm ("TremoloSpanEvent");
>+ SCM start_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (START));
>+ unsmob_music (start_event_scm)->set_spot (*origin);
>+ SCM stop_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (STOP));
>+
>+ Music *start_event = unsmob_music (start_event_scm);
>+ Music *stop_event = unsmob_music (stop_event_scm);
I think you're leaking memory here, some unprotects are necessary.
The Music objects are created by SCM code, I thought stuff returned
from Scheme was unprotected in general?
Yes, you're right. sorry.
I don't understand. What is this for?
I don't remember right now (I added those lines last summer). It might
be related to problems with grace notes, or somethign like that.
Should I remove hte lines if I can't find a more clear justification?
Yes.
> - (tremolo-type ,integer? "")
> + (tremolo-type ,integer? "speed of tremolo, e.g. 16 for c4:16")
hmm. That sucks, we should store the negative log (-4 for 16) rather
than 16.
why negative?
negative log of the duration, log2(1/16) = -4
> +#define LOWLEVEL_MAKE_SYNTAX(proc, args) \
> + scm_apply_0 (proc, args)
> +/* Syntactic Sugar. */
> #define MAKE_SYNTAX(name, location, ...) \
> - scm_apply_0 (ly_lily_module_constant (name), scm_list_n
(make_input (location), __VA_ARGS__, SCM_UNDEFINED));
> + LOWLEVEL_MAKE_SYNTAX (ly_lily_module_constant (name), scm_list_n
(make_input (location), __VA_ARGS__, SCM_UNDEFINED));
>
I don't see the point of LOWLEVEL_MAKE_SYNTAX
It was used for music functions first, then I found a different way to
implement music functions. The macro can be used to use arbitrary
function objects iso. symbols to represent functions.
I think the proper way is to make it a music macro; is it OK to keep
it a music function until music macros exist? (also, the music
function code attempts to signal errors when \once is used in the
wrong place, so from a user's point of view, little changes)
Why do you want to make it a macro?
> (define-ly-syntax-loc (repeat type num body alts)
>(make-repeat type num body alts))
> +
> +(define-ly-syntax-loc (context-specification type id mus ops
create-new?)
I believe that according to Scheme coding standards, the ? is only used
on procedures, so this should just be create-new.
ok. I recall seeing a ? in an existing non-procedure symbol in lily;
I'll remove it the next time I see it.
please do.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Yet another 2 patches for music streams
On 5/22/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Also, in general, I think it should be possible to split patches up
further, eg. the tremolo stuff seems independent of the
partcombine/lyriccombine stuff.
A problem is my limited internet access. I can cvs diff very seldom; I
often work several days on lily between the diffs. This makes it
difficult/troublesome to keep patches atomic.
Currently I keep 3 copies of the lily tree, so I can maintain 2
independent diff branches + one unmodified version; this already leads
to problems (the tremolo stuff was first supposed to go into branch 2,
but was accidentally added to branch 1 instead).
>+ dir_ = RIGHT;
>+ }
>+ if (dir == STOP)
>+ {
They don't represent the same thing. RIGHT means that the right
beam-count is modified, STOP means that an event stops a spanner.
>
> + SCM tremolo_symbol = ly_symbol2scm ("TremoloSpanEvent");
>+ SCM start_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (START));
>+ unsmob_music (start_event_scm)->set_spot (*origin);
>+ SCM stop_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (STOP));
>+
>+ Music *start_event = unsmob_music (start_event_scm);
>+ Music *stop_event = unsmob_music (stop_event_scm);
I think you're leaking memory here, some unprotects are necessary.
The Music objects are created by SCM code, I thought stuff returned
from Scheme was unprotected in general?
>+ SCM start_chord = scm_call_1 (ly_lily_module_constant
("chordify-event"), start_event_scm);
>+ SCM stop_chord = scm_call_1 (ly_lily_module_constant
>("chordify-event"), stop_event_scm);
>+
>+ child_list_ = scm_list_3 (start_chord, body->self_scm (),
>stop_chord);+
I think it should be possible to do without the chord_event, and simply
insert the events themselves. Possibly you will need to make an
Event_iterator, which is similar to Event_chord_iterator.
ok, I'll look into that.
>+ child_list_ = scm_list_3 (start_chord, body->self_scm (), stop_chord);+
}
>+
>+ Sequential_iterator::construct_children ();
>+void
>+Chord_tremolo_iterator::derived_mark () const
> {
>- return child_iter_->try_music (m);
>+ scm_gc_mark (child_list_);
It's better style to construct the child_list in get_music_list, and not
store it all, as it's already stored in the base class in the cursor_
variable. Then you also don't need a derived_mark() member.
I notice that you've done this with the other iterators too. Can you
change this, also in time-scaled-music-iterator and percent-repeat-iterator?
ok
> + // Wait for a Create_context event, to catch implicitly created
voices before it's too late.
> + t->events_below ()->add_listener (GET_LISTENER (check_new_context),
ly_symbol2scm ("CreateContext"));
> + listening_ = true;
> +}
why does this happen in find_voice() ?
Isn't it more natural to set the listener in construct_children?
good idea (which btw seems to make a dirty workaround clean).
> + // UGH. Only swallow the output property event in the context
> + // it was intended for. This is inelegant but not inefficient.
> + if (context ()->context_name_symbol () == m->get_property
("context-type"))
> +{
> + props_.push_back (m);
> + return true;
> +}
this doesn't work with \alias. Can you use context::is_alias() ?
ok
> + get_outlet ()->context_name_symbol ());
You're modifying the input; that's not allowed.
Can you write a convert-ly rule to change
\context Foo \applyOutput XXX
->
\applyOutput #'Foo
and change the \applyOutput to set context-type.
ok
> +/*
> +* Processes a moment in an iterator, and returns whether any new music was
reported.
> +*/
> +bool
> +Part_combine_iterator::try_process (Music_iterator *i, Moment m)
> +{
> + Dispatcher *disp = i->get_outlet ()->event_source ();
> +
> + disp->add_listener (GET_LISTENER (set_busy), ly_symbol2scm ("MusicEvent"));
> + busy_ = false;
> +
> + i->process (m);
> +
> + disp->remove_listener (GET_LISTENER (set_busy), ly_symbol2scm
("MusicEvent"));
> + return busy_;
> +}
I don't understand this. Why are you adding and removing listeners all
the time? Why don't you signal the state of the Part_combine_iterator to
set_busy through another boolean member? ie.
Good idea, thanks (I just tried to emulate the previous behaviour as
closely as possible)
I don't understand. What is this for?
I don't remember right now (I added those lines last summer). It might
be related to problems with grace notes, or somethign like that.
Should I remove hte lines if I can't find a more clear justification?
> - (tremolo-type ,integer? "")
> + (tremolo-type ,integer? "speed of tremolo, e.g. 16 for c4:16")
hmm. That sucks, we should store the negative log (-4 for 16) rather
Re: Yet another 2 patches for music streams
Erik Sandberg schreef:
Hi,
I've finished 2 more patches for music streams. One of them is considerably
larger than the other, but the two should be independent.
Some comments.
Also, in general, I think it should be possible to split patches up
further, eg. the tremolo stuff seems independent of the
partcombine/lyriccombine stuff.
+ dir_ = RIGHT;
+ }
+ if (dir == STOP)
+ {
This looks a bit confusing. Maybe we can rename things to more clear?
>+ // number of beams for short tremolos
>+ int expected_beaming_;
please use expected_beam_count_ . In general, if you need these 1-line
comments to explain what a member does, you have to rename that member.
>
+ SCM tremolo_symbol = ly_symbol2scm ("TremoloSpanEvent");
+ SCM start_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (START));
+ unsmob_music (start_event_scm)->set_spot (*origin);
+ SCM stop_event_scm = scm_call_2 (ly_lily_module_constant
("make-span-event"), tremolo_symbol, scm_from_int (STOP));
+
+ Music *start_event = unsmob_music (start_event_scm);
+ Music *stop_event = unsmob_music (stop_event_scm);
I think you're leaking memory here, some unprotects are necessary.
>+ SCM start_chord = scm_call_1 (ly_lily_module_constant
("chordify-event"), start_event_scm);
>+ SCM stop_chord = scm_call_1 (ly_lily_module_constant
>("chordify-event"), stop_event_scm);
>+
>+ child_list_ = scm_list_3 (start_chord, body->self_scm (),
>stop_chord);+
I think it should be possible to do without the chord_event, and simply
insert the events themselves. Possibly you will need to make an
Event_iterator, which is similar to Event_chord_iterator.
+ child_list_ = scm_list_3 (start_chord, body->self_scm (), stop_chord);+
}
+
+ Sequential_iterator::construct_children ();
+void
+Chord_tremolo_iterator::derived_mark () const
{
- return child_iter_->try_music (m);
+ scm_gc_mark (child_list_);
It's better style to construct the child_list in get_music_list, and not
store it all, as it's already stored in the base class in the cursor_
variable. Then you also don't need a derived_mark() member.
I notice that you've done this with the other iterators too. Can you
change this, also in time-scaled-music-iterator and percent-repeat-iterator?
Questions:
- It seems that the OutputPropertySetMusic music type is unused. Should I
remove it?
yes.
- I have not yet done anything about old-lyric-combine-music-iterator. Should
I spend time on making it work, or can we junk oldaddlyrics for the next
release? (there's no regression test for oldaddlyrics, btw)
let's junk it.
- What's the Right Way to pass warnings and errors from Scheme code? I want
some warning messages to make use of Input objects.
(ly:message INPUT-SMOB "format string ~a" argument .. )
+ // Wait for a Create_context event, to catch implicitly created
voices before it's too late.
+ t->events_below ()->add_listener (GET_LISTENER (check_new_context),
ly_symbol2scm ("CreateContext"));
+ listening_ = true;
+}
why does this happen in find_voice() ?
Isn't it more natural to set the listener in construct_children?
+#if 0
bool b = get_outlet ()->try_music ((Music *)m); // ugh
Music_iterator *it = b ? (Music_iterator *) this : 0;// ugh
if (!it)
can you strip the #if 0 sections from patches?
+ // UGH. Only swallow the output property event in the context
+ // it was intended for. This is inelegant but not inefficient.
+ if (context ()->context_name_symbol () == m->get_property
("context-type"))
+{
+ props_.push_back (m);
+ return true;
+}
this doesn't work with \alias. Can you use context::is_alias() ?
s_name ()));
+ // Send the event to a bottom context. The context-type property
+ // will later be used to apply the event in this context
Minor nit: can you use /* */ for multiline comments, with indents like
/* bla bla blah
bla bla bla
*/
+ get_music ()->set_property ("context-type",
+ get_outlet ()->context_name_symbol ());
You're modifying the input; that's not allowed.
Can you write a convert-ly rule to change
\context Foo \applyOutput XXX
->
\applyOutput #'Foo
and change the \applyOutput to set context-type.
+IMPLEMENT_LISTENER (Part_combine_iterator, set_busy);
+void
+Part_combine_iterator::set_busy (SCM se)
+{
+ Stream_event *e = unsmob_stream_event (se);
+ SCM mus = e->get_property ("music");
+ Music *m = unsmob_music (mus);
+ assert (m);
+
+ if (m->is_mus_type ("note-event") || m->is_mus_type ("cluster-note-event"))
+busy_ = true;
+}
+
+/*
+* Processes a moment in an iterator, and returns whether any new music was
reported.
+*/
+bool
+Part_combine_iterator::try_process (Music_iterator *i, Moment m)
+{
+ Dispatcher *disp = i->get_outlet ()
Yet another 2 patches for music streams
Hi, I've finished 2 more patches for music streams. One of them is considerably larger than the other, but the two should be independent. Pathc 1: - lyric-combine-music.cc, partcombine-iterator.cc: updated to use stream events for busy testing. - chord-tremolo: massively cleaned up (iterator either generates ChordEvent, which is handled like :, or generates span start/stop events. Engraver is shrinked) - Translator_group::try_music is now invoked through listeners. Patch 2: - output-property-*: prepare for bottomification of try_music - exported some more rules to scheme: - \once is converted to music function (we might later want to make it a music macro) - context-specification -> ly-syntax rule - ly-syntax rule for music functions. Two generic utility functions have been introduced, chordify-event and music-is-of-type? Todo: - create contexts through music streams (add new event for context creation announcements) - make try_music auto-descend to bottom context. Some of the current places where stream-events are sent should then be replaced with try_music calls. - Make other commands (SetProperty, ChangeContext, Prepare, OneTimeStep) use stream events. Questions: - It seems that the OutputPropertySetMusic music type is unused. Should I remove it? - I have not yet done anything about old-lyric-combine-music-iterator. Should I spend time on making it work, or can we junk oldaddlyrics for the next release? (there's no regression test for oldaddlyrics, btw) - What's the Right Way to pass warnings and errors from Scheme code? I want some warning messages to make use of Input objects. -- Erik ? .sconf_temp ? build-stamp ? context-unique.diff ? def-rel-music-funciton.diff ? delay-music-functions.diff ? exjobb.diff3 ? fonts ? lib ? lilypond.kdevelop ? lilypond.kdevelop.pcs ? lilypond.kdevses ? optimized ? os ? ref1.diff ? ref2.diff ? repeat.diff ? scons.cache ? Documentation/out ? Documentation/out-www ? Documentation/bibliography/out ? Documentation/misc/out ? Documentation/pictures/out ? Documentation/topdocs/out ? Documentation/user/out ? Documentation/user/out-www ? buildscripts/out ? buildscripts/out-www ? cygwin/out ? cygwin/out-www ? debian/out ? elisp/out ? elisp/out-www ? flower/out ? flower/out-scons ? flower/out-www ? flower/include/.sconsign ? flower/include/out ? flower/include/out-www ? input/Diagram1.dia.autosave ? input/les-nereides.pdf ? input/les-nereides.ps ? input/out ? input/out-www ? input/mutopia/out ? input/mutopia/out-www ? input/mutopia/E.Satie/out ? input/mutopia/E.Satie/out-www ? input/mutopia/F.Schubert/out ? input/mutopia/F.Schubert/out-www ? input/mutopia/J.S.Bach/out ? input/mutopia/J.S.Bach/out-www ? input/mutopia/R.Schumann/out ? input/mutopia/R.Schumann/out-www ? input/mutopia/W.A.Mozart/out ? input/mutopia/W.A.Mozart/out-www ? input/no-notation/out ? input/no-notation/out-www ? input/no-notation/to-xml.pdf ? input/no-notation/to-xml.ps ? input/regression/chord-tremolo.pdf ? input/regression/chord-tremolo.ps ? input/regression/out ? input/regression/out-www ? input/template/out ? input/test/out ? input/test/out-www ? input/tutorial/out ? input/tutorial/out-www ? kpath-guile/out ? kpath-guile/out-scons ? lily/On ? lily/busy-playing-listener.cc ? lily/foo.pdf ? lily/foo.ps ? lily/lilypond ? lily/lilypond.gdt ? lily/lilypond.gpr ? lily/out ? lily/out-scons ? lily/out-www ? lily/include/.sconsign ? lily/include/busy-playing-listener.hh ? lily/include/out ? lily/include/out-www ? ly/out ? ly/out-www ? make/out ? make/out-www ? mf/feta-alphabet11.600pk ? mf/feta-alphabet13.600pk ? mf/feta-alphabet14.600pk ? mf/feta-alphabet16.600pk ? mf/feta-alphabet18.600pk ? mf/feta-alphabet20.600pk ? mf/feta-alphabet23.600pk ? mf/feta-alphabet26.600pk ? mf/feta-braces-a.600pk ? mf/feta-braces-b.600pk ? mf/feta-braces-c.600pk ? mf/feta-braces-d.600pk ? mf/feta-braces-e.600pk ? mf/feta-braces-f.600pk ? mf/feta-braces-g.600pk ? mf/feta-braces-h.600pk ? mf/feta-braces-i.600pk ? mf/feta11.600pk ? mf/feta13.600pk ? mf/feta14.600pk ? mf/feta16.600pk ? mf/feta18.600pk ? mf/feta20.600pk ? mf/feta23.600pk ? mf/feta26.600pk ? mf/out ? mf/out-scons ? mf/out-www ? mf/parmesan11.600pk ? mf/parmesan13.600pk ? mf/parmesan14.600pk ? mf/parmesan16.600pk ? mf/parmesan18.600pk ? mf/parmesan20.600pk ? mf/parmesan23.600pk ? mf/parmesan26.600pk ? po/out ? po/out-www ? ps/out ? ps/out-www ? python/convertrules.pyc ? python/fontextract.pyc ? python/lilylib.pyc ? python/out ? python/out-www ? scm/out ? scm/out-www ? scripts/lilypond-book-36.py ? scripts/lilypond-book.py.new ? scripts/out ? scripts/out-www ? scripts/stat ? stepmake/out ? stepmake/out-www ? stepmake/bin/out ? stepmake/bin/out-www ? stepmake/bin/packagepython.pyc ? stepmake/stepmake/out ? stepmake/stepmake/out-www ? tex/out ? tex/out-www ? ttftool/out ? ttftool/out-scons ? ttftool/include/.sconsign ? ttftool/include/out ? vim/out ? vim/out-www Index: ChangeLog =
