Re: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
Erlend Aasland schreef: CVSROOT:/sources/lilypond Module name:lilypond Branch: Changes by: Erlend Aasland [EMAIL PROTECTED]06/05/14 14:06:37 Modified files: . : ChangeLog lily : grob.cc stencil-interpret.cc stencil-scheme.cc stencil.cc lily/include : stencil.hh scm: define-grob-properties.scm define-markup-commands.scm output-ps.scm output-svg.scm Log message: Add rotation support a NEWS entry? perhaps an update of the manual? -- 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: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: a NEWS entry? perhaps an update of the manual?How's this for the news? I'll write something for the manual asap.Regards, Erlend news.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting the height of a system.
Joe Neeman schreef:
I think this could be even more expensive because my page breaker looks at a
_lot_ of different line breaking configurations. On the score I have been
using for coverage tests (Haydn op 76, no 3, 1st violin part), the page
breaker tests more than 4000 different line breaking configurations so this
is already much more expensive than doing it for 50-60 copies of the score.
ok
Also, it's not completely possible to compute the height of an isolated
system: some grobs (notably spanners like slur) look at the next system
to decide how to format across line breaks.
Would it be acceptable to skip those cases? This would be a good point to
Yes.
mention that I don't really need the exact height of the system -- just an
approximation. The current approximation I am using (setting a score-wide
system-height) is _very_ crude but it works pretty well as long as there are
no RemoveEmptyStaffContexts or very high notes.
I think that actually the RemoveEmptyStaffContexts are the difficult
parts, the high notes would be an exception.
Secondly, although it will be nicely portable, it also sounds like a lot
of work. Isn't it a lot easier to simply do a fork() and let the OS
clean up after us? Perhaps if the vertical spacing is completely
working, we can consider doing the full-blown copy and restore. Also,
for large scores, fork() is an interesting option, as we could get some
benefit from using SMP.
But then the OS would have to deal with copying the data and it can only do
that in page-sized chunks. So wouldn't this just increase the amount of stuff
that gets copied?
Yes, but it's a much easier to be certain that it is correct than
writing copying and cleanup stuff in C++.
There is actually another possibility that I've only just thought of so it's
pretty half-baked:
Add an approximate-Y-extent to each grob that
1) leaves the grob constant (in particular no caching)
2) ignores anything in the object_alist_ that doesn't have a system.
Then we could even get away with not doing any break-substitutions (until it's
time to typeset things, of course) with something like:
Real System::guess_line_height (Column_x_positions col)
{
set_bound (LEFT, col.cols_[0]);
set_bound (RIGHT, col.cols_.back ());
for (vsize i = 0; i col.cols_.size (); i++)
{
// translate axis (as in System::break_into_pieces)
col.cols_[i].system_ = this;
}
set_loose_columns (this, col);
SCM h = this-get_property (approximate-Y-extent);
for (vsize i = 0; i col.cols_.size (); i++)
{
// translate the axis back
col.cols_.system_ = 0;
}
return scm_to_double (h);
}
That is, we can pretend we're working on the original system and get away with
it because approximate-Y-extent will be guaranteed not to leave any
side-effects. Condition (2) means that we can get away with doing it a system
at a time. A spanner that crosses a line break will realise that it is
crossing the line break and will try to provide a sensible guess.
I think that's a sensible stop gap solution, but I have a feeling it
will be a lot of work. Perhaps it's better to approach from the other
side, and only explicitly do this for alignment spanners.
Perhaps you could even compute for each VerticalAxisGroup the range of
column ranks where it would disappear, and use that information add a
method to compute the approximate height of an alignment spanner, where
you explicitly call it with a (begin,end) pair of column ranks.
In that case, you could get the approximate height of one broken system
in logarithmic time.
--
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: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
Erlend Aasland schreef: On 5/15/06, *Han-Wen Nienhuys* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: a NEWS entry? perhaps an update of the manual? How's this for the news? I'll write something for the manual asap. Regards, Erlend wonderful. you can insert your name if you like (this feature contributed by .. ) -- 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: New attempt on tuplets/percent repeats
Erik Sandberg schreef: Hi, Here's a patch that massively refactors tuplets and percent repeats. Highlights: - tuplets are now signalled by start/stop events. This patch looks almost ready for inclusion. Can you address my tuplet-event nit, verify that a clean make web still work, and commit? The tuplet-engraver looks good, but I would still like the events to be generated in the Tuplet_iterator (which you may rename from time-scaled-music-iterator), so the music representation is analogous to the \times 2/3 syntax. Keeping the music representation and syntax as closely related as possible makes things easier, both for me (understanding the whole thing), Nicolas (maintaining display-music) and you (when you want to separate the parser and tree generation). In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Nicolas, does that make sense to you too? - each percent/slash is signalled by an individual event, whose repeat-count property tells whether it should be numbered (this moves some decisions from engraver to iterator) Huh, this doesn't correspond with your code, where countPercentRepeats is still the determining factor? I'd like to leave countPercentRepeats as is, btw. The diffs of some files are huge, so I'm sending the new files instead. I think it's a bit out of place to merge percent_repeat and double_percent_repeat into one engraver. yes, I agree. Some next steps that would be nice are: - move handling of double percent repeats to slash_engraver (or possibly to a new double_percent_engraver, but imho they are similar enough to share engraver) Mabye even make a brand new engraver? WE have a lot of precomputations that make adding another engraver rather cheap. - handle percent_repeat with start/stop event - create different event types for percent event, slash event and double percent event. Oh, there's another thing: it would also be nice to link back the synthetic events to the input, by setting their origins to the origins of the music expression. This is neccessary to provide sensible error messages. DoublePercentRepeatCounter, nitpick: add a ' ' before the final , and sort alphabetically. The same for all similar lists of properties. Music *percent = make_music_by_name (ly_symbol2scm (PercentEvent)); percent-set_spot (*mus-origin ()); percent-set_property (length, length); if (repeats 1) percent-set_property (repeat-count, scm_int2num (i - 1)); Music *percent_chord = make_music_by_name (ly_symbol2scm (EventChord)); percent_chord-set_spot (*mus-origin ()); percent_chord-set_property (elements, scm_list_1 (percent-self_scm ())); child_list_ = scm_cons (percent_chord-self_scm (), child_list_); can you double check that you're not leaking the percent event? I think it should be unprotect()ed somewhere. The same for any other synthetic event that you create. -- 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: Implementation of music streams
Erik Sandberg schreef:
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 the event_source_.
This step is now finished, patch attached. You can notice some
Can you also look my nits regarding warnings and SEND_EVENT_TO_CONTEXT
below, and commit if make web still works?
additional stuff that has been added as well, which currently is
unused but will be used in future patches. You will notice that this
patch makes lily spit out lots of Junking Event messages, which are
harmless.
Can you make sure that in this patch those warnings are surpressed?
I don't want to leave lily in a state where it prints bazillions of
messages.
Regarding SEND_EVENT_TO_CONTEXT(ctx, cl, ...) and EVENT_PROPERTY:
I think the proper unproctect method nowadays is
smob-unprotect()
also wouldn't it be possible to do away with EVENT_PROPERTY, and just do
send_event_to_context (c, ev,
ly_symbol2scm (key), val,
ly_symbol2scm (key2), val2)
and in the macro do something like
SCM args[] = { __VA_ARGS__ , 0 };
for (int i = 0; args[i]; i+=2)
..
I think that this reads more logically. Come to think of it, I don't see
why SEND_EVENT_TO_CONTEXT should be a macro. Is there a reason why it
can't be a function, except for the ly_symbol2scm() memoization?
If you want to keep the macro, then at least make sure the actual code
body which says
Stream_event *_e_ = new Stream_event (ctx, ly_symbol2scm (cl));
ctx-event_source ()-distribute (_e_);
scm_gc_unprotect_object (_e_-self_scm ());
is in a function. That makes debugging a bit easier and reads more
logically.
--
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: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
[EMAIL PROTECTED]
+Objects may be rotated using the @code{rotation} property.
[EMAIL PROTECTED],fragment,relative=2]
+{
+ \override NoteHead #'rotation = #'(45 0 0)
+ c1^\markup { \rotate #180 test }
+}
[EMAIL PROTECTED] lilypond
Well, rotating a note head is probably one of the more obscure
applications. I suggest that you replace it with a hairpin.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting the height of a system.
On Mon, 2006-05-15 at 12:20 +0200, Han-Wen Nienhuys wrote:
Joe Neeman schreef:
There is actually another possibility that I've only just thought of so
it's
pretty half-baked:
Add an approximate-Y-extent to each grob that
1) leaves the grob constant (in particular no caching)
2) ignores anything in the object_alist_ that doesn't have a system.
Then we could even get away with not doing any break-substitutions (until
it's
time to typeset things, of course) with something like:
Real System::guess_line_height (Column_x_positions col)
{
set_bound (LEFT, col.cols_[0]);
set_bound (RIGHT, col.cols_.back ());
for (vsize i = 0; i col.cols_.size (); i++)
{
// translate axis (as in System::break_into_pieces)
col.cols_[i].system_ = this;
}
set_loose_columns (this, col);
SCM h = this-get_property (approximate-Y-extent);
for (vsize i = 0; i col.cols_.size (); i++)
{
// translate the axis back
col.cols_.system_ = 0;
}
return scm_to_double (h);
}
That is, we can pretend we're working on the original system and get away
with
it because approximate-Y-extent will be guaranteed not to leave any
side-effects. Condition (2) means that we can get away with doing it a
system
at a time. A spanner that crosses a line break will realise that it is
crossing the line break and will try to provide a sensible guess.
I think that's a sensible stop gap solution, but I have a feeling it
will be a lot of work. Perhaps it's better to approach from the other
side, and only explicitly do this for alignment spanners.
Perhaps you could even compute for each VerticalAxisGroup the range of
column ranks where it would disappear, and use that information add a
method to compute the approximate height of an alignment spanner, where
you explicitly call it with a (begin,end) pair of column ranks.
In that case, you could get the approximate height of one broken system
in logarithmic time.
That sounds encouraging! I don't fully understand how alignment spanners
work since I haven't had much to do with that part of the code (yet).
But this looks like something I can go on with -- I'll be back if/when
I've made something useful out of it.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
On 5/15/06, Werner LEMBERG [EMAIL PROTECTED] wrote: Well, rotating a note head is probably one of the more obscureapplications.I suggest that you replace it with a hairpin.Done. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New attempt on tuplets/percent repeats
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg schreef: Hi, Here's a patch that massively refactors tuplets and percent repeats. Highlights: - tuplets are now signalled by start/stop events. This patch looks almost ready for inclusion. Can you address my tuplet-event nit, verify that a clean make web still work, and commit? The tuplet-engraver looks good, but I would still like the events to be generated in the Tuplet_iterator (which you may rename from time-scaled-music-iterator), so the music representation is analogous to the \times 2/3 syntax. ok, that's fine. Perhaps the music compression should be performed by the iterator as well? Keeping the music representation and syntax as closely related as possible makes things easier, both for me (understanding the whole thing), Nicolas (maintaining display-music) and you (when you want to separate the parser and tree generation). In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Is there a long-term plan to make iterators softcodable? The main thing I dislike about moving stuff to iterators is that it moves code to C++, so if someone wants to do a nonstandard tweak of time_scaled_music_iterator, he has to recompile lily locally. - each percent/slash is signalled by an individual event, whose repeat-count property tells whether it should be numbered (this moves some decisions from engraver to iterator) Huh, this doesn't correspond with your code, where countPercentRepeats is still the determining factor? I'd like to leave countPercentRepeats as is, btw. the difference is the check for whether there are too few repeats to bother about typesetting numbers (i.e., if there's only one percent) Some next steps that would be nice are: - move handling of double percent repeats to slash_engraver (or possibly to a new double_percent_engraver, but imho they are similar enough to share engraver) Mabye even make a brand new engraver? WE have a lot of precomputations that make adding another engraver rather cheap. It does however require code duplication. Anyway, I'll apply the other changes you requested, and then commit (the engraver can be split up later) BTW, what's your position on copyrights/licensing? I've added my name to files which I feel I have modified massively, do you have objections to that? (I'm ready to relicense any code I write to lgpl or gpl=3 if that's needed in the future) Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond ./ChangeLog lily/grob.cc lily/stencil-...
On 15-May-06, at 3:15 AM, Erlend Aasland wrote: On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: a NEWS entry? perhaps an update of the manual? How's this for the news? I'll write something for the manual asap. Actually, I think the news is good enough for now. If it goes in the manual, it would have to be in the new features chapter (not yet created). Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg schreef: 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 the event_source_. This step is now finished, patch attached. You can notice some Can you also look my nits regarding warnings and SEND_EVENT_TO_CONTEXT below, and commit if make web still works? additional stuff that has been added as well, which currently is unused but will be used in future patches. You will notice that this patch makes lily spit out lots of Junking Event messages, which are harmless. Can you make sure that in this patch those warnings are surpressed? I don't want to leave lily in a state where it prints bazillions of messages. ok Come to think of it, I don't see why SEND_EVENT_TO_CONTEXT should be a macro. Is there a reason why it can't be a function, except for the ly_symbol2scm() memoization? no, the memoization is the only reason. I can make the code less compact (inserting lots of ly_symbol2scm calls) and do it as a function, if you like. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New attempt on tuplets/percent repeats
Erik Sandberg schreef: Highlights: - tuplets are now signalled by start/stop events. This patch looks almost ready for inclusion. Can you address my tuplet-event nit, verify that a clean make web still work, and commit? The tuplet-engraver looks good, but I would still like the events to be generated in the Tuplet_iterator (which you may rename from time-scaled-music-iterator), so the music representation is analogous to the \times 2/3 syntax. ok, that's fine. Perhaps the music compression should be performed by the iterator as well? I've been toying with that idea for a long time, but I haven't been able to work out how we could do that easily and cleanly. Keeping the music representation and syntax as closely related as possible makes things easier, both for me (understanding the whole thing), Nicolas (maintaining display-music) and you (when you want to separate the parser and tree generation). In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Is there a long-term plan to make iterators softcodable? The main thing I dislike about moving stuff to iterators is that it moves code to C++, so if someone wants to do a nonstandard tweak of time_scaled_music_iterator, he has to recompile lily locally. No plans, but I understand your concern. However, I haven't seen instances that need SCM-written iterators. Let's wait for situations where that is necessary before we start changing things. FWIW, there is a lot in the parser that is softcodable (eg. the meaning of articulation scripts, the \bar command etc), but nobody ever uses that functionality. BTW, what's your position on copyrights/licensing? I've added my name to files which I feel I have modified massively, do you have objections to that? No, go ahead. Remember to update AUTHORS.texi too. (I'm ready to relicense any code I write to lgpl or gpl=3 if that's needed in the future) I have toyed with the idea of getting disclaimers from all contributors, but haven't actually gone through with the idea. Regarding GPLv3 vs GPL vs LGPL, let's wait before the v3 storm settles down before changing licensing terms. Also, we might consider removing the names from copyright headers completely - as it puts ownership stamps on files, which not desirable from a engineering perspective. Perhaps it would be better to have a separate legal entity to carry the copyrights. -- 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: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: 2006/5/15, Erik Sandberg [EMAIL PROTECTED]: On 5/14/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: 2006/5/14, Erik Sandberg [EMAIL PROTECTED]: What should be the value of the 'unique field of a CreateContext event? When writing, the 'unique field to be written is determined by the file writer. OK, so file writers have direct listeners to all contexts then? (I've implemented it previously using the events_below dispatcher, which is more convenient) I agree it would be nice to get rid of unique. Sorry, I think we're miscommunicating something. Can you explain what the value unique is used for? AFAICS, it's only used for reading and writing streams, and isn't per se necessary inside the context tree. That observation is true. The purpose of unique is to make the reader/writer understand which newly created contexts that are connected to which events. Before a context is created, the parent decides a unique value, with which the child will tag all its events. It's a very clear and easy way to make sure that everyone agrees on which context that belong to which parent, and which stream event that belongs to which context. However, I have found one good alternative, where the stream event has no unique field. This approach involves a dummy event AnnounceContext, which are sent by newly created contexts. These messages have no musical meaning, and should not be part of any output file, but you must listen to them if you want to find out about the context structure. I'd suggest that an AnnounceContext event contains a direct reference to the newly created context, as well as a direct reference to the CreateContext event. This makes it very clear which CreateContext events that result in which contexts. I like my new design better than my original one, because data is separated in a more logical way, and because I think it eliminates a bad hack in create_context. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New attempt on tuplets/percent repeats
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: (I'm ready to relicense any code I write to lgpl or gpl=3 if that's needed in the future) I have toyed with the idea of getting disclaimers from all contributors, but haven't actually gone through with the idea. Regarding GPLv3 vs GPL vs LGPL, let's wait before the v3 storm settles down before changing licensing terms. The main change I'm thinking of, is to LGPL parts of lily (separate a lib around Context and Dispatcher), so non-free programs can use the music stream interface in a lilypond-compatible way. I doubt anyone is interested, but it may be a bad thing to prohibit it. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implementation of music streams
Erik Sandberg schreef: However, I have found one good alternative, where the stream event has no unique field. This approach involves a dummy event AnnounceContext, which are sent by newly created contexts. These messages have no musical meaning, and should not be part of any output file, but you must listen to them if you want to find out about the context structure. I'd suggest that an AnnounceContext event contains a direct reference to the newly created context, as well as a direct reference to the CreateContext event. This makes it very clear which CreateContext events that result in which contexts. I like my new design better than my original one, because data is separated in a more logical way, and because I think it eliminates a bad hack in create_context. It sounds better, but I'm still not following you completely. Why can't you connect the StreamEvents to the appropriate context in the stream reader? Ie. why does it need the intervention of (dummy) events? -- 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: New attempt on tuplets/percent repeats
Erik Sandberg schreef: On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: (I'm ready to relicense any code I write to lgpl or gpl=3 if that's needed in the future) I have toyed with the idea of getting disclaimers from all contributors, but haven't actually gone through with the idea. Regarding GPLv3 vs GPL vs LGPL, let's wait before the v3 storm settles down before changing licensing terms. The main change I'm thinking of, is to LGPL parts of lily (separate a lib around Context and Dispatcher), so non-free programs can use the music stream interface in a lilypond-compatible way. I doubt anyone is interested, but it may be a bad thing to prohibit it. I see your point, but I would reverse the reasoning: let's keep things GPL, so non-free programs cannot link to the music stream interface directly. I want to be careful with having nonfree programs exploit our efforts for free. -- 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: New attempt on tuplets/percent repeats
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Erik Sandberg schreef: Hi, Here's a patch that massively refactors tuplets and percent repeats. Highlights: - tuplets are now signalled by start/stop events. This patch looks almost ready for inclusion. Can you address my tuplet-event nit, verify that a clean make web still work, and commit? The tuplet-engraver looks good, but I would still like the events to be generated in the Tuplet_iterator (which you may rename from time-scaled-music-iterator), so the music representation is analogous to the \times 2/3 syntax. Keeping the music representation and syntax as closely related as possible makes things easier, both for me (understanding the whole thing), Nicolas (maintaining display-music) and you (when you want to separate the parser and tree generation). In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Nicolas, does that make sense to you too? I'm clueless about what you're both talking about... (I don't know what iterators do). So it does not make sense to me, sorry :o) nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New attempt on tuplets/percent repeats
Nicolas Sceaux schreef: In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Nicolas, does that make sense to you too? I'm clueless about what you're both talking about... (I don't know what iterators do). So it does not make sense to me, sorry :o) The subject is the internal representation for syntactical constructs. For example, \clef G translates to 3 property set commands. I was speculating that for display-music it would be easier to maintain if we had a ClefChangeEvent, and move the translation of G to values for clefGlyph/middleCPosition/clefPosition further to the back of LilyPond. -- 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: Implementation of music streams
On 5/15/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg schreef: However, I have found one good alternative, where the stream event has no unique field. This approach involves a dummy event AnnounceContext, which are sent by newly created contexts. These messages have no musical meaning, and should not be part of any output file, but you must listen to them if you want to find out about the context structure. I'd suggest that an AnnounceContext event contains a direct reference to the newly created context, as well as a direct reference to the CreateContext event. This makes it very clear which CreateContext events that result in which contexts. I like my new design better than my original one, because data is separated in a more logical way, and because I think it eliminates a bad hack in create_context. It sounds better, but I'm still not following you completely. Why can't you connect the StreamEvents to the appropriate context in the stream reader? Ie. why does it need the intervention of (dummy) events? The main problem is in the stream writer: Even if you hear a CreateContext event from a context, you don't have a clue how to find the newly created context (except that you can look at the parent's children and find the best match, which isn't robust without a unique value). There is a similar problem in the reader: When the reader sends a CreateContext event, it only knows that the event will trigger a context creation; I don't see a nice way of finding the newly created context without adding a dummy event. Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New attempt on tuplets/percent repeats
Han-Wen Nienhuys [EMAIL PROTECTED] writes: Nicolas Sceaux schreef: In general, I think it makes sense to move parser substitutions as much as possible to the iterators, eg. at some point, we should also change the implementation of mmrests, \clef and \time. Nicolas, does that make sense to you too? I'm clueless about what you're both talking about... (I don't know what iterators do). So it does not make sense to me, sorry :o) The subject is the internal representation for syntactical constructs. For example, \clef G translates to 3 property set commands. I was speculating that for display-music it would be easier to maintain if we had a ClefChangeEvent, and move the translation of G to values for clefGlyph/middleCPosition/clefPosition further to the back of LilyPond. Oh yes, ok, indeed it would ease the translation back from music expression to lilypond notation. The patterns matchers are easily breakable. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Bleeding edge documentation
On 14-May-06, at 4:23 AM, Nicolas Sceaux wrote:
11.1.1 Overview of music functions
Thanks, done.
11.1.2 Simple substitution functions
tempoMark: a string argument can be written without the sharp. This
looks cleaner: \tempoMark Allegro #3.0
Also it's usual, for instance in the case of markup commands, to have
the integer argument before the other. Otherwise, if the string is very
long, the number would be lost after.
True, fixed.
11.2.1 Input variables and Scheme
Done.
11.3.1 Displaying music expressions
Perhaps, the output of the \displayMusic example could be explained a
bit.
Done.
Between that section and the following one, the functions used to
access
and set music properties may be introduced.
Err, ok. I added all this pretty much as you explained it here, but
I'm not sure that I understood it fully. Could you check this section
when we have another release to make sure I didn't omit or change
anything important?
11.3.3 Adding articulation to notes (example)
I don't know where you got this example from, but there are mistakes.
From you, :)
http://lists.gnu.org/archive/html/lilypond-devel/2006-05/msg00039.html
(you did write it's late, short story for the rest, so evidently you
were tired when you wrote it)
`cons' is used to add an element to a list
The wording is poor: cons does not modify the existing list. Maybe that
should be precised, for instance: (without modifying the original
list).
Hmm... how's this?
[EMAIL PROTECTED]' is used to add an element to a list without modifying the
original list.
11.4.1 Markup construction in Scheme
One can not feed the #:line, #:center, or #:column) commands with a
variable or the result of a function call.
This sentence should more general, we're talking here about commands
accepting markup-list arguments, eg. #:line, #:center-align or #:column
(but there are others, like #:fill-line).
Does this work?
Commands which accept markup-list arguments (such as
@code{#:line}, @code{#:center}, [EMAIL PROTECTED]:column}) cannottake commands
with a variable or commands which are the
result of a function call.
Thanks,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
patch for \transposedCueDuring
Here is my updated patch which implements \transposedCueDuring as
discussed earlier on this list.
Werner
==
2006-05-15 Werner Lemberg [EMAIL PROTECTED]
* lily/lexer.ll (init_signature_has_table): Add
`scm-scm-music-music'.
* lily/parser.yy (MUSIC_FUNCTION_SCM_SCM_MUSIC_MUSIC): New token.
(Generic_prefix_music_scm): Add rule for it.
* lily/quote-iterator.cc (Quote_iterator::process): Handle
`quoted-transposition' property.
* ly/music-functions-init.ly (transposedCueDuring): New function.
* scm/define-music-properties.scm (all-music-properties): Updated.
* Documenation/topdocs/NEWS.itely: Document it.
==
--- ./ly/music-functions-init.ly.old2006-05-06 15:09:43.0 +0200
+++ ./ly/music-functions-init.ly2006-05-16 00:02:11.0 +0200
@@ -207,6 +207,20 @@
'origin location))
+transposedCueDuring = #
+(define-music-function
+ (parser location what dir pitch-note main-music)
+ (string? ly:dir? ly:music? ly:music?)
+ (make-music 'QuoteMusic
+ 'element main-music
+ 'quoted-context-type 'Voice
+ 'quoted-context-id cue
+ 'quoted-music-name what
+ 'quoted-voice-direction dir
+ 'quoted-transposition (pitch-of-note pitch-note)
+ 'origin location))
+
+
quoteDuring = #
(define-music-function
(parser location what main-music)
@@ -217,7 +231,6 @@
'origin location))
-
pitchedTrill =
#(define-music-function
(parser location main-note secondary-note)
--- ./scm/define-music-properties.scm.old 2006-05-09 10:04:56.0
+0200
+++ ./scm/define-music-properties.scm 2006-05-16 00:05:27.0 +0200
@@ -80,6 +80,7 @@
(quoted-voice-direction ,ly:dir? Should the quoted voice be up-stem or
down-stem?)
(quoted-context-type ,symbol? The name of the context to direct quotes
to, eg., @code{Voice}.)
(quoted-context-id ,string? The id of the context to direct quotes to,
eg., @code{cue}.)
+ (quoted-transposition ,ly:pitch? The pitch used for the quote,
overriding \\transposition)
(to-relative-callback ,procedure? How to transform a piece of music to
relative pitches)
(tweaks ,list? An alist of properties to override in the backend
for the grob made of this event.)
--- ./lily/quote-iterator.cc.old2006-04-03 01:36:51.0 +0200
+++ ./lily/quote-iterator.cc2006-05-16 00:03:48.0 +0200
@@ -222,7 +222,9 @@
/*
The pitch that sounds like central C
*/
- Pitch *me_pitch = unsmob_pitch (get_outlet ()-get_property
(instrumentTransposition));
+ Pitch *me_pitch = unsmob_pitch (get_music ()-get_property
(quoted-transposition));
+ if (!me_pitch)
+ me_pitch = unsmob_pitch (get_outlet ()-get_property
(instrumentTransposition));
for (SCM s = scm_cdr (entry); scm_is_pair (s); s = scm_cdr (s))
{
--- ./lily/parser.yy.old2006-04-07 03:05:57.0 +0200
+++ ./lily/parser.yy2006-05-16 06:35:40.0 +0200
@@ -282,6 +282,7 @@
%token scm MUSIC_FUNCTION_SCM
%token scm MUSIC_FUNCTION_SCM_MUSIC
%token scm MUSIC_FUNCTION_SCM_MUSIC_MUSIC
+%token scm MUSIC_FUNCTION_SCM_SCM_MUSIC_MUSIC
%token scm MUSIC_FUNCTION_SCM_SCM
%token scm MUSIC_FUNCTION_SCM_SCM_MUSIC
%token scm MUSIC_FUNCTION_SCM_SCM_SCM
@@ -1037,6 +1038,11 @@
$4-unprotect ();
$3-unprotect ();
}
+ | MUSIC_FUNCTION_SCM_SCM_MUSIC_MUSIC function_scm_argument
function_scm_argument Music Music {
+ $$ = scm_list_n ($1, make_input (@$), $2, $3, $4-self_scm (),
$5-self_scm (), SCM_UNDEFINED);
+ $4-unprotect ();
+ $5-unprotect ();
+ }
| MUSIC_FUNCTION_MARKUP_MUSIC_MUSIC full_markup Music Music {
$$ = scm_list_5 ($1, make_input (@$), $2, $3-self_scm (),
$4-self_scm ());
$3-unprotect ();
--- ./lily/lexer.ll.old 2006-04-06 14:54:23.0 +0200
+++ ./lily/lexer.ll 2006-05-16 06:28:16.0 +0200
@@ -895,6 +895,7 @@
{scm-scm, MUSIC_FUNCTION_SCM_SCM},
{music-music, MUSIC_FUNCTION_MUSIC_MUSIC},
{scm-music-music, MUSIC_FUNCTION_SCM_MUSIC_MUSIC},
+ {scm-scm-music-music, MUSIC_FUNCTION_SCM_SCM_MUSIC_MUSIC},
{scm-scm-music, MUSIC_FUNCTION_SCM_SCM_MUSIC},
{scm-scm-scm-music, MUSIC_FUNCTION_SCM_SCM_SCM_SCM_MUSIC},
{scm-scm-scm-scm-music, MUSIC_FUNCTION_SCM_SCM_SCM_MUSIC},
--- ./Documentation/topdocs/NEWS.tely.old 2006-05-15 22:42:10.0
+0200
+++ ./Documentation/topdocs/NEWS.tely 2006-05-16 00:14:56.0 +0200
@@ -66,6 +66,17 @@
@end ignore
+
[EMAIL PROTECTED]
+A new command @code{\transposedCueDuring} has been
strange spacing
Using CVS 2006-May-15 22:42, I get a strange spacing for the New
Century Schoolbook fonts. Does anybody else see this?
Werner
==
{ c''-\markup { foo } }
foo.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
