Erik Sandberg schreef:
I think you can just use Sequential_iterator for that, which you give a
SCM list of elements. It will also do the Right Thing if there is a
grace note involved.
I don't understand. How can I do that without creating a dummy
Sequential_music object?
see the use of
Se
On 5/12/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
Erik Sandberg schreef:
> Hm, I guess the easiest/cleanest way would be to let the
> percent-repeat-iterator create an implicit SequentialMusic around the music,
> with the additional percent elements, and then to let process_music pretend
>
On Friday 12 May 2006 12:17, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > eliminate the parser's need to wrap expressions inside \context Bottom. I
> > can implement this when I've finished some more of the music stream
> > refactorings.
>
> come to think of it, I'm still missing the define
Erik Sandberg schreef:
eliminate the parser's need to wrap expressions inside \context Bottom. I can
implement this when I've finished some more of the music stream refactorings.
come to think of it, I'm still missing the define-event-classes.scm file.
--
Han-Wen Nienhuys - [EMAIL PROTECTED]
Erik Sandberg schreef:
On Thursday 11 May 2006 00:54, Han-Wen Nienhuys wrote:
2006/5/10, Erik Sandberg <[EMAIL PROTECTED]>:
Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:
Known issue: unfold-repeats will probably not work for percent
I don't understand this. unfold-repeats is on the front end,
On Thursday 11 May 2006 00:54, Han-Wen Nienhuys wrote:
> 2006/5/10, Erik Sandberg <[EMAIL PROTECTED]>:
> > Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> > > > Known issue: unfold-repeats will probably not work for percent
> > > I don't understand this. unfold-repeats is on the front end, we can
>
2006/5/10, Erik Sandberg <[EMAIL PROTECTED]>:
Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:> > Known issue: unfold-repeats will probably not work for percent repeats.> (the> > repeat will be unfolded, but percents will still remain). I'd suggest to
> fix> > this by scrapping percent-repeat-iterator
Citerar Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> Erik Sandberg schreef:
> > I'm more or less done with repeats now. Patch attached.
> >
> > Known issue: unfold-repeats will probably not work for percent repeats.
> (the
> > repeat will be unfolded, but percents will still remain). I'd suggest to
>
Erik Sandberg schreef:
I'm more or less done with repeats now. Patch attached.
Known issue: unfold-repeats will probably not work for percent repeats. (the
repeat will be unfolded, but percents will still remain). I'd suggest to fix
this by scrapping percent-repeat-iterator, and to create a Se
On Wednesday 05 April 2006 13:19, Erik Sandberg wrote:
> On Tuesday 04 April 2006 20.42, Han-Wen Nienhuys wrote:
> > I'd start with 4. because they're independent from the rest, and we can
> > readily test the rest of those.
>
> I'm now reworking repeats.
I'm more or less done with repeats now. P
Erik Sandberg schreef:
If there's a rule that LY_DEFINEs should be in their own files, then there are
some inconsistencies:
Sure. All the more reason to fix the inconsistencies.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Mus
On Wednesday 03 May 2006 11:07, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > LY_DEFINE (ly_make_listener, "ly:make-listener",
>
> scm-listener-scheme.cc
> >>>
> >
> > sorry, I don't do stuff I don't understand. I have renamed the class and
> > placed it in a file listener-sche
2006/5/3, Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> During the past week I haven't been able to make web with unpatched CVS, so> this requirement is rather tough (currently laissez-vibrer-ties.ly causes a> segfault).
Strange. I may have let a bug slip. It's running now.that was a bug, but it's fixed
Erik Sandberg schreef:
LY_DEFINE (ly_make_listener, "ly:make-listener",
scm-listener-scheme.cc
Scm_listener is only intended to be used locally by that function;
splitting the file into two modules would feel artificial/meaningless.
no, just do it.
sorry, I don't do stuff I don't understand
On Thursday 27 April 2006 16:08, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > I have changed the definition to:
> > IMPLEMENT_LISTENER (Scm_listener, listener, (Stream_event *ev))
> > {
> > ...
> > }
> >
> > Your suggestion doesn't work well because of some magic inside the macro.
>
> Can't
Erik Sandberg schreef:
Hi,
Sorry for the delay. Here's a new revision of the dispatcher system. Known
issues:
- Some trivial changes should be done to other files, e.g. lily.scm and
lily-proto.hh.
- I added the unique_ member to Context. It's just an int that's supposed to
be unique for each
Hi,
Sorry for the delay. Here's a new revision of the dispatcher system. Known
issues:
- Some trivial changes should be done to other files, e.g. lily.scm and
lily-proto.hh.
- I added the unique_ member to Context. It's just an int that's supposed to
be unique for each context. unique might not
Han-Wen Nienhuys wrote:
// Collect all listener lists.
struct { int prio; SCM list; } lists[num_classes+1];
int i = 0;
for (SCM cl = class_list; cl != SCM_EOL; cl = scm_cdr (cl))
also, always use scm_is_pair() iso. checking for SCM_EOL.This will
crash on malformed lists.
--
H
Erik Sandberg wrote:
Some known issues:
- scm/define-event-classes.scm contains rather unsorted functions which are
i'm missing that file.
- The Stream_event class duplicates its 'context property with a context_
member; this was originally intended to give speedups, but it is broken in
thi
Erik Sandberg wrote:
On Tuesday 04 April 2006 20.42, Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
I'm now reworking repeats. While I'm at it, I attempt to generally clean up
the repeat code.
No, better not. I
On Tuesday 04 April 2006 20.42, Han-Wen Nienhuys wrote:
> I'd start with 4. because they're independent from the rest, and we can
> readily test the rest of those.
I'm now reworking repeats. While I'm at it, I attempt to generally clean up
the repeat code.
Plan:
- Move some repeat C++ code from
On Tuesday 04 April 2006 21.37, Han-Wen Nienhuys wrote:
> Erik Sandberg wrote:
> > On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
> >> Han-Wen Nienhuys wrote:
> >>> I'd start with 4. because they're independent from the rest, and we can
> >>> readily test the rest of those.
> >
> > The rea
Erik Sandberg wrote:
On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
The reason for my ordering, is that 3 can be used to verify that 4 works.
BTW, (1-3) ar
On Tuesday 04 April 2006 20.46, Han-Wen Nienhuys wrote:
> Han-Wen Nienhuys wrote:
> > I'd start with 4. because they're independent from the rest, and we can
> > readily test the rest of those.
The reason for my ordering, is that 3 can be used to verify that 4 works.
BTW, (1-3) are completely ind
Han-Wen Nienhuys wrote:
I'd start with 4. because they're independent from the rest, and we can
readily test the rest of those.
I mean: test the results of those.
(I need to take a break :-)
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-
Erik Sandberg wrote:
Hi,
Here's my plan on how to front-port music streams to the 2.9 branch.
1. Implement classes Dispatcher, Stream_event, Listener (move modules from my
thesis fork)
2. Add dispatchers event_source_, and possibly events_below_, to Context
class.
3. Make Context::try_music
Hi,
Here's my plan on how to front-port music streams to the 2.9 branch.
1. Implement classes Dispatcher, Stream_event, Listener (move modules from my
thesis fork)
2. Add dispatchers event_source_, and possibly events_below_, to Context
class.
3. Make Context::try_music send stream events to th
27 matches
Mail list logo
