Re: Enhancement suggestion
Cool. FYI I've had LilyPond for a week and I've gotten more done already than months of fiddleing with Finale and about ten other GUI based programs. LilyPond is a lifesaver in terms of reuseability and template implementation, great job. The real power lies in the ability to template your songs, then making standardized changes across all of them is a breeze, just a re-run with the new template. In typical GUI programs you have to go in and hand touch up each document separately. Wow. I can even write my own pre-processors to generate source .ly files! Having variables and include files alone allows you to set up rudimentary inheritance increasing productivity, and now smart tags. -- View this message in context: http://www.nabble.com/Enhancement-suggestion-t1395631.html#a3753951 Sent from the Gnu - Lilypond - Dev forum at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Enhancement suggestion
Read Section "8.2.8 Different editions from one source".
/Mats
Rick Hansen (aka RickH) wrote:
I'm a guitarist but have a suggestion for a new command LilyPond.
When entering a standatrd notes staff... on guitar music it is customary to
place roman numerals of the current fretting position just below the staff
(section 7.5.5 of v2.8.0 manual).
When entering a tab staff... it is also necessary to tell the TabStaff what
the current minimum-fret is (section 7.5.2 of v2.8.0 manual) so that it can
calculate the fingerings of the notes that follow.
It would be real handy to not have to re-enter all your notes twice when
creating both a TabStaff and standard Staff in your score.
So why not make a command that can enable both the TabStaff and Staff to be
generated from the same notes list? Here is the command I am proposing to
identify the current fetting position called \FrettingPosition:
\FrettingPosition { n } where n is the position.
Now when you code your notes list you can use for example:
myNotes = { g4^\FrettingPosition { 2 } a4 b4 c4 }
\new Staff { \myNotes }
\new TabStaff { \myNotes }
When \FrettingPosition finds itself in the Context of a Staff, it will
generate Roman Numeral position markers under the regular staff.
When \FrettingPosition finds itself in the Context of a TabStaff it will
simply reset the minimum-fret attribute.
Now a person only has to maintain one set of notes and can easily generate
one, the other, or both staffs, and only have one notes list to maintain.
--
View this message in context:
http://www.nabble.com/Enhancement-suggestion-t1395631.html#a3753197
Sent from the Gnu - Lilypond - Dev forum at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Enhancement suggestion
I'm a guitarist but have a suggestion for a new command LilyPond.
When entering a standatrd notes staff... on guitar music it is customary to
place roman numerals of the current fretting position just below the staff
(section 7.5.5 of v2.8.0 manual).
When entering a tab staff... it is also necessary to tell the TabStaff what
the current minimum-fret is (section 7.5.2 of v2.8.0 manual) so that it can
calculate the fingerings of the notes that follow.
It would be real handy to not have to re-enter all your notes twice when
creating both a TabStaff and standard Staff in your score.
So why not make a command that can enable both the TabStaff and Staff to be
generated from the same notes list? Here is the command I am proposing to
identify the current fetting position called \FrettingPosition:
\FrettingPosition { n } where n is the position.
Now when you code your notes list you can use for example:
myNotes = { g4^\FrettingPosition { 2 } a4 b4 c4 }
\new Staff { \myNotes }
\new TabStaff { \myNotes }
When \FrettingPosition finds itself in the Context of a Staff, it will
generate Roman Numeral position markers under the regular staff.
When \FrettingPosition finds itself in the Context of a TabStaff it will
simply reset the minimum-fret attribute.
Now a person only has to maintain one set of notes and can easily generate
one, the other, or both staffs, and only have one notes list to maintain.
--
View this message in context:
http://www.nabble.com/Enhancement-suggestion-t1395631.html#a3753197
Sent from the Gnu - Lilypond - Dev forum at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Style
It's up to you as a user to do this. Just write a .ly file with all your favourite style changes and use \include "mystyle.ly" in your scores. The thing is that it is possible to separate layout from content in LilyPond, but it is not enforced and maybe not even encouraged enough. /Mats Quoting Johannes Schindelin <[EMAIL PROTECTED]>: Hi, On Tue, 4 Apr 2006, David Feuer wrote: I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, [...] LaTeX deals with this through .sty files. And I suggest we continue along that path: Just \include the .sty file (like it is done for localized note names), and deal with the settings in the .sty file. Hth, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: implementation plan for music streams
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 reason for my ordering, is that 3 can be used to verify that 4 works.
> >
> > BTW, (1-3) are completely independent of (4), and I have just finished
> > step (1) locally. If you insist on getting (4) done before (1), then
> > that's perfectly OK with me; but is it OK for you to look at my patch for
> > (1) while I do (4)? I guess (1) is the step which requires the longest
> > discussion, so it might be good to start the discussion early.
>
> If you have a working patch, let's see it.
It's just a bunch of new files; all are attached.
Some known issues:
- scm/define-event-classes.scm contains rather unsorted functions which are
related to music streams. Most of them are probably in the wrong place. I
guess simplify-scheme should be in music-functions.scm, but where should I
place car< ?
- The Stream_event class duplicates its 'context property with a context_
member; this was originally intended to give speedups, but it is broken in
this version and requires some modifications to Context in order to work.
I'll probably remove the context_ member altogether in the next revision.
The dispatcher system has been tested with the following code:
#(begin
; event -> disp -> list
(define disp (ly:make-dispatcher))
(define list (ly:make-listener (lambda (ev) (display "received: \"")
(display ev) (display "\"\n"
(define ev (ly:make-stream-event '((class . StreamEvent) (id . 2) (foo .
"bar"
(ly:add-listener list disp 'StreamEvent)
(ly:broadcast disp ev)
; ev -> disp2 -> disp -> list
(define disp2 (ly:make-dispatcher))
(ly:connect-dispatchers disp disp2)
(ly:broadcast disp2 ev)
)
--
Erik
/*
dispatcher.cc -- implement Dispatcher
source file of the GNU LilyPond music typesetter
(c) 2005-2006 Erik Sandberg <[EMAIL PROTECTED]>
*/
#include "dispatcher.hh"
#include "international.hh"
#include "ly-smobs.icc"
#include "stream-event.hh"
#include "warn.hh"
// ES todo: move to lily-guile.hh
SCM appendable_list ();
void appendable_list_append (SCM l, SCM elt);
IMPLEMENT_SMOBS (Dispatcher);
IMPLEMENT_TYPE_P (Dispatcher, "dispatcher");
IMPLEMENT_DEFAULT_EQUAL_P (Dispatcher);
Dispatcher::~Dispatcher ()
{
}
Dispatcher::Dispatcher ()
{
self_scm_ = SCM_EOL;
listeners_ = SCM_EOL;
dispatchers_ = SCM_EOL;
listen_classes_ = SCM_EOL;
smobify_self ();
//TODO use resizable hash
listeners_ = scm_c_make_hash_table (17);
priority_count_ = 0;
}
SCM
Dispatcher::mark_smob (SCM sm)
{
Dispatcher *me = (Dispatcher *) SCM_CELL_WORD_1 (sm);
scm_gc_mark (me->dispatchers_);
scm_gc_mark (me->listen_classes_);
return me->listeners_;
}
int
Dispatcher::print_smob (SCM s, SCM p, scm_print_state*)
{
Dispatcher *me = (Dispatcher *) SCM_CELL_WORD_1 (s);
scm_puts ("#listeners_), p);
scm_puts (">", p);
return 1;
}
/*
Event dispatching:
- Collect a list of listeners for each relevant class
- Send the event to each of these listeners, in increasing priority order.
This is done by keeping a bubble-sorted temporary list of listener lists,
and iteratively send the event to the lowest-priority listener.
- An event is never sent twice to listeners with equal priority.
*/
IMPLEMENT_LISTENER (Dispatcher, dispatch) (Stream_event *ev)
{
SCM class_symbol = ev->get_property ("class");
if (!scm_symbol_p (class_symbol))
{
warning (_f ("Unknown event class %s", ly_symbol2string (class_symbol).c_str ()));
return;
}
SCM class_list = scm_primitive_eval (class_symbol);
bool sent = false;
// TODO: fix this loop.
int num_classes = 0;
for (SCM cl = class_list; cl != SCM_EOL; cl = scm_cdr (cl))
num_classes++;
// 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))
{
SCM list = scm_hashq_ref (listeners_, scm_car (cl), SCM_EOL);
if (list == SCM_EOL)
num_classes--;
else
{
// bubblesort.
int prio = scm_to_int (scm_caar (list));
int j;
for (j = i; j > 0 && lists[j-1].prio > prio; j--)
lists[j] = lists[j-1];
lists[j].prio = prio;
lists[j].list = list;
i++;
}
}
lists[num_classes].prio = INT_MAX;
// Never send an event to two listeners with equal priority.
int last_priority = -1;
// Iteratively process all event classes, in increasing priority.
while (num_classes)
{
// Send the event, if we haven't already sent it to this target.
if (lists[0].prio != last_priority)
{
// process the listener
assert (lists[0].prio > last_priority);
last_priority = lists[0].prio;
Listener *l = unsmob_listener (scm_cdar (lists[0].list));
Re: I solved the polygon problem.
David Feuer wrote: On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: David Feuer wrote: music-drawing-routines.ps to indicate level 2. I really don't have the time to set myself up to compile the LilyPond sources. Could you setting yourself is actually very easy nowadays, at least if you're running linux or macos X. Just go to I'm on Windows. I do have an account on a Linux system. How hard is FWIW, theoretically it should be possible to run GUB under cygwin as well, but noone has ever tried. -- 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: I solved the polygon problem.
David Feuer wrote: On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: David Feuer wrote: music-drawing-routines.ps to indicate level 2. I really don't have the time to set myself up to compile the LilyPond sources. Could you setting yourself is actually very easy nowadays, at least if you're running linux or macos X. Just go to I'm on Windows. I do have an account on a Linux system. How hard is it for a non-root user to install lilypond somewhere other than the usual system directories? It's trivial. Compiling does take a lot of resources though. I'd be real greatful though if you'd do the polygon thing for me. Well I'd be real grateful if you could do it for me; as much as I like tighter code, rewriting a SVG arc routine is a lot of work I'd rather spend on other aspects of music notation. But perhaps there is someone else who would like to do it? -- 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: Testing in draw_round_box
David Feuer wrote: Does anyone actually set /testing to test round boxes anymore, or is that a historical artifact? I've already fixed it (in a recent patch) artifact, please junk. so it doesn't waste time, but it's still wasting (a bit of) space and making the code less pretty. -- 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 plan for music streams
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) are completely independent of (4), and I have just finished step (1) locally. If you insist on getting (4) done before (1), then that's perfectly OK with me; but is it OK for you to look at my patch for (1) while I do (4)? I guess (1) is the step which requires the longest discussion, so it might be good to start the discussion early. If you have a working patch, let's see it. -- 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: I solved the polygon problem.
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > David Feuer wrote: > > music-drawing-routines.ps to indicate level 2. I really don't have > > the time to set myself up to compile the LilyPond sources. Could you > > setting yourself is actually very easy nowadays, at least if you're > running linux or macos X. Just go to I'm on Windows. I do have an account on a Linux system. How hard is it for a non-root user to install lilypond somewhere other than the usual system directories? I'd be real greatful though if you'd do the polygon thing for me. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I solved the polygon problem.
David Feuer wrote: music-drawing-routines.ps to indicate level 2. I really don't have the time to set myself up to compile the LilyPond sources. Could you setting yourself is actually very easy nowadays, at least if you're running linux or macos X. Just go to http://lilypond.org/~hanwen/gub/README it does take quite a bit of CPU time and disk space. -- 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 plan for music streams
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 independent of (4), and I have just finished step (1) locally. If you insist on getting (4) done before (1), then that's perfectly OK with me; but is it OK for you to look at my patch for (1) while I do (4)? I guess (1) is the step which requires the longest discussion, so it might be good to start the discussion early. -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Testing in draw_round_box
Does anyone actually set /testing to test round boxes anymore, or is that a historical artifact? I've already fixed it (in a recent patch) so it doesn't waste time, but it's still wasting (a bit of) space and making the code less pretty. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: I solved the polygon problem.
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > we don't do level 1 anyway. I think that glyphshow is L2. You're right! So I can remove the level 1 emulation code I put in for selectfont. And we should change the PostScript comment at the top of music-drawing-routines.ps to indicate level 2. I really don't have the time to set myself up to compile the LilyPond sources. Could you make the changes to the polygon C++ sources? Can someone rewrite the SVG polygon code? Note: You may want to put the polygon shrinking code on a shelf somewhere in case we ever need rounded unfilled polygons. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ vs. Scheme
David Feuer wrote: On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: The reason for having C++ is historical. I'm not certain that using Scheme for everything will lower hackability of the code, eg. I'm still not as fluent in Scheme as in C++ --with all its shortcomings. Also, having opaque C++ objects is convenient, because it makes it easy to enforce invariants and maintain encapsulation. If I were writing LilyPond, from scratch, alone, I'd probably write it in Standard ML. Unfortunately, not a lot of hackers are familiar with Well, me too ;) i'd probably use it as an excuse to learn ocaml or similar. However, it's not the case, so we'll have to live with bits of C++. that. As for opaqueness, that's certainly possible in Scheme, and implementations like PLT provide lots of object-oriented kinds of things if you're into that. What I'd really like to see is more functional (in the FP sense) management of Stencils. set!s make me nervous. Yes, me too. Feel free to rewrite them more functionally. -- 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: I solved the polygon problem.
David Feuer wrote: Use the postscript "arct" command. Drawing a filled polygon becomes x0 x1 add 2 div y0 y1 add 2 div moveto x1 y1 x2 y2 r arct x2 y2 x3 y3 r arct x3 y3 x4 y4 r arct ... x(n-1) y(n-1) x0 y0 r arct x0 y0 x1 y1 r arct closepath fill where n is the number of points and r is the radius of the arc. arct is a language level 2 feature, but it shouldn't be too hard to emulate it in level 1 if need be (using arc). we don't do level 1 anyway. I think that glyphshow is L2. -- 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: Contexts
I don't understand your question. Properties inherit from Score downwards. Usually, bottom context doesn't have any property set, only inherited values. David Feuer wrote: Why are properties set by default in the bottom context? I think it would make more sense to do what Postscript does with dictionaries and set them by default in the lowest context that has those properties. -- 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: I solved the polygon problem.
While I'm at it, the Scheme and Postscript polygon drawers are only ever called with the filled parameter true, so please get rid of that parameter. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Contexts
Why are properties set by default in the bottom context? I think it would make more sense to do what Postscript does with dictionaries and set them by default in the lowest context that has those properties. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ vs. Scheme
On 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > The reason for having C++ is historical. > > I'm not certain that using Scheme for everything will lower hackability > of the code, eg. I'm still not as fluent in Scheme as in C++ --with all > its shortcomings. Also, having opaque C++ objects is convenient, > because it makes it easy to enforce invariants and maintain encapsulation. If I were writing LilyPond, from scratch, alone, I'd probably write it in Standard ML. Unfortunately, not a lot of hackers are familiar with that. As for opaqueness, that's certainly possible in Scheme, and implementations like PLT provide lots of object-oriented kinds of things if you're into that. What I'd really like to see is more functional (in the FP sense) management of Stencils. set!s make me nervous. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
I solved the polygon problem.
Use the postscript "arct" command. Drawing a filled polygon becomes x0 x1 add 2 div y0 y1 add 2 div moveto x1 y1 x2 y2 r arct x2 y2 x3 y3 r arct x3 y3 x4 y4 r arct ... x(n-1) y(n-1) x0 y0 r arct x0 y0 x1 y1 r arct closepath fill where n is the number of points and r is the radius of the arc. arct is a language level 2 feature, but it shouldn't be too hard to emulate it in level 1 if need be (using arc). I don't know SVG, but it should be possible to use the same technique there. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: implementation plan for music streams
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 -- 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: C++ vs. Scheme
David Feuer wrote: What's the rationale behind the division into C++ and Scheme? I don't quite see why Lilypond uses C++ and Guile rather than using a serious Scheme implementation (like PLT) and working to shift code from C++ over to Scheme. The reason for having C++ is historical. I'm not certain that using Scheme for everything will lower hackability of the code, eg. I'm still not as fluent in Scheme as in C++ --with all its shortcomings. Also, having opaque C++ objects is convenient, because it makes it easy to enforce invariants and maintain encapsulation. -- 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: Style
Han-Wen Nienhuys wrote: it would actually be fairly trivial. You can already \tag music events; you'd only need to write an engraver that catches tagged grobs, and sorry, I meant: tagged events. applies any grob properties necessary. -- 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 plan for music streams
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 send stream events to the event_source_. 4. Refactor certain iterators (apply-context, time-scaled-music), so that all music events are sent to bottom contexts. 5. Refactor commands such as lyricsto, to eliminate busy-playing-event etc. 6. There should now be no dependency on the try_music return value, so it should be safe to make Translator_group::try_music an event handler. 7. Add stream events for CreateContext, ChangeContext, Prepare, OneTimeStep, SetProperty, etc. These are quite easy to implement. 8. Various cleanups; e.g., remove the unneeded Score_context class. Comments? I'd start with 4. because they're independent from the rest, and we can readily test the rest of those. -- 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: 2.8.1 pdf file size
David Feuer wrote: On 4/4/06, Geoff Horton <[EMAIL PROTECTED]> wrote: After upgrading to 2.8.1, I notice that the .pdf files produced are considerable larger, on the order of about 5 to 10 times the size formerly produced. This has a detrimental effect on my ability to store and distribute, so much that I have to back level to 2.6 to use. Is there any way in PDF to ask the interpreter to hang on to the file names for us so we can refer to them without copying them out every time? good question. I don't know. the problem with file sizes doesn't have anything to do with point & click though. It's usually that people are running unpatched Ghostscript 8.x instead of using the GUB builds. -- 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: Style
David Feuer wrote: I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, and I would suggest that Lilypond might do something similar: let users name timesteps, timestep edges, measures, and categories of such, and format them according to a separate program. Obviously this would be loads of work, and I don't even know if it would be feasible, but that's what I'm thinking. it would actually be fairly trivial. You can already \tag music events; you'd only need to write an engraver that catches tagged grobs, and applies any grob properties necessary. -- 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: C++ vs. Scheme
David Feuer wrote: On 4/4/06, Pedro Kröger <[EMAIL PROTECTED]> wrote: Paul Scott <[EMAIL PROTECTED]> writes: It's simple. Scheme code will probably never run as fast as C++. Unless, of couse, one uses a scheme compiler that can generate fast code, like bigloo [1]. Or a Scheme system like PLT that uses JIT compilation (mzscheme), supports separate compilation for time critical sections (mzc), and has a foreign function interface for C++ and C. The big advantage? Rapid development. If Scheme isn't fast enough for some things, they can be written in C. I suspect there are few of those. The choice for GUILE is mostly historical, and I'm all for switching to Mz, but I fear that such a move involves a tremendous amount of work, due to API differences. You're welcome to give an Mz port a try, if you think it's feasible. -- 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: 2.8.1 pdf file size
On 4/4/06, Geoff Horton <[EMAIL PROTECTED]> wrote: > > > After upgrading to 2.8.1, I notice that the .pdf files produced are > > > considerable larger, on the order of about 5 to 10 times the size > > > formerly produced. This has a detrimental effect on my ability to > > > store and distribute, so much that I have to back level to 2.6 > > > to use. Is there any way in PDF to ask the interpreter to hang on to the file names for us so we can refer to them without copying them out every time? David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Style
Hi, indeed, this topic has been brought up at least in early 2003 (maybe even earlier) and also went into Han-Wen's and Jan's XIV CIM 2003 paper (see right column of page 4 in this paper). There _is_ already an implicit way of writing style sheets (although somewhat limited), but let me explain in detail, using ancient notation as an example. Lily's ancient notation has been designed from its very beginning with having in mind the principle of separating musical content from notational style. A convincing argument for doing so is, for example, the task of generating both, old (i.e. original) and new (i.e. transcibed) notation of an ancient piece from a single source. This is done by controlling a bunch of grob and context properties, such as "TimeSignature #'style". Nowadays, in Lily you could achieve the goal of creating old and new notation from the same source with the \tag command, but it is still handy to collect control of style at a central spot in the source, rather than scattering tagged \set or \override commands all over the source. The point here is, that you may want to change whatever aspect of the notational style at a central place rather than having to scan through the whole source and maybe need to introduce a new tag name. In Lily, the notational style is currently unfotunately not explicitly factored out into a separate style file like .css or .sty. Still, it is in most cases possible and usually good practice to set such properties only once per staff (or score) at the beginning of the piece. Following this thought a little bit further, there actually _is_ a (limited) way of separating style into a different file. For example, the context definitions of VaticanaVoice and VaticanaStaff in ly/engraver-init.ly in combination with the definitions in ly/gregorian-init.ly initialize a bunch of properties, such that you will get ancient notation. If you replace all occurrences of \VaticanaStaff and \VaticanaVoice with \GregorianTranscriptionVoice and \GregorianTranscriptionStaff, you should (at least in theory) get the same music, but in contemporary notation. This way, the context definitions in ly/engraver-init.ly serve as predefined style sheets for a selected number of styles (at least for ancient notation). You can add new styles by overriding these context definitions. That is, writing a style sheet in Lily currently reduces to the matter of redefining context definitions. Greetings, Juergen On Tue, 4 Apr 2006, David Feuer wrote: I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, and I would suggest that Lilypond might do something similar: let users name timesteps, timestep edges, measures, and categories of such, and format them according to a separate program. Obviously this would be loads of work, and I don't even know if it would be feasible, but that's what I'm thinking. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ vs. Scheme
On 4/4/06, Pedro Kröger <[EMAIL PROTECTED]> wrote: > Paul Scott <[EMAIL PROTECTED]> writes: > > > It's simple. Scheme code will probably never run as fast as C++. > > Unless, of couse, one uses a scheme compiler that can generate fast > code, like bigloo [1]. Or a Scheme system like PLT that uses JIT compilation (mzscheme), supports separate compilation for time critical sections (mzc), and has a foreign function interface for C++ and C. The big advantage? Rapid development. If Scheme isn't fast enough for some things, they can be written in C. I suspect there are few of those. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Style
On 4/4/06, Carl D. Sorensen <[EMAIL PROTECTED]> wrote: > Carl Sorensen here: > > But this flies in the very face of Lilypond's objective. The objective > for lilypond is to have an automatic engraver that takes the music > information and creates a beautiful engraved score. We don't want to > tweak output, we want to eliminate all tweaks. > > Rather than use the effort to develop the tweaking system as a separate > program, lilypond would prefer to use the effort to improve the engraver > algorithms so no tweaking is necessary. Tweaks are (hopefully > temporary) hacks to deal with weakness in the engraving algorithms. 1. Different people will always want different things. 2. The same people will want different things for different pieces, and even for different sections of a single piece. 3. Different publishers will always have different standards. Any time there are several accepted notations for a single musical idea, composers will want to be able to decide which one they use. Every time there are two fonts, engravers will want to choose theirs. Every time there is a conflict between good-looking music and easy-to-play music, engravers will have to make a judgement. I am convinced that the right goal is to make the engraving algorithms so good that tweaking is rarely necessary, but to make the tweaking system as elegant as possible. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ vs. Scheme
Paul Scott <[EMAIL PROTECTED]> writes: > It's simple. Scheme code will probably never run as fast as C++. Unless, of couse, one uses a scheme compiler that can generate fast code, like bigloo [1]. Pedro Footnotes: [1] http://www-sop.inria.fr/mimosa/fp/Bigloo/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
trapezoids
Lilypond draws beams as polygons. The polygon code (in lookup.cc) is hairy, and probably slow. It'd be much easier and faster to make beams trapezoids. More generally, from reading the comments on the polygon code, I get the feeling it might be best to get rid of it altogether. I'm looking through the old polygon thread now, and I'll see if I can come up with a good solution. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Style
-Original Message- From: David Feuer [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 04, 2006 9:57 AM To: lily-devel Subject: Style I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, and I would suggest that Lilypond might do something similar: let users name timesteps, timestep edges, measures, and categories of such, and format them according to a separate program. Obviously this would be loads of work, and I don't even know if it would be feasible, but that's what I'm thinking. David Feuer Carl Sorensen here: But this flies in the very face of Lilypond's objective. The objective for lilypond is to have an automatic engraver that takes the music information and creates a beautiful engraved score. We don't want to tweak output, we want to eliminate all tweaks. Rather than use the effort to develop the tweaking system as a separate program, lilypond would prefer to use the effort to improve the engraver algorithms so no tweaking is necessary. Tweaks are (hopefully temporary) hacks to deal with weakness in the engraving algorithms. Lilypond has considered (and rejected) the Sibelius method of generating engraved output, then tweaking this output to produce the final output. While it's harder, I'm convinced that the Lilypond way is the fundamentally better way. Carl Sorensen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: C++ vs. Scheme
David Feuer wrote: What's the rationale behind the division into C++ and Scheme? I don't quite see why Lilypond uses C++ and Guile rather than using a serious Scheme implementation (like PLT) and working to shift code from C++ over to Scheme. It's simple. Scheme code will probably never run as fast as C++. Some fully compiled language is needed for speed for the heavy internal calculations. I doesn't have to be C++ but Han-Wen is not going to rewrite the C++ at this point. Check the archive for these discussions. Paul Scott ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
C++ vs. Scheme
What's the rationale behind the division into C++ and Scheme? I don't quite see why Lilypond uses C++ and Guile rather than using a serious Scheme implementation (like PLT) and working to shift code from C++ over to Scheme. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Style
Hi, On Tue, 4 Apr 2006, David Feuer wrote: > I'm sure someone has brought this up before, but I've been thinking a > bit about the way users tweak output in Lilypond. As it is, tweaks > are generally interspersed with actual music information. This seems > to make things difficult when someone tries to maintain a part that > has to be transposed a couple different ways, or printed on different > paper sizes, or whatever. The web deals with this problem through > CSS, [...] LaTeX deals with this through .sty files. And I suggest we continue along that path: Just \include the .sty file (like it is done for localized note names), and deal with the settings in the .sty file. Hth, Dscho ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Style
I'm sure someone has brought this up before, but I've been thinking a bit about the way users tweak output in Lilypond. As it is, tweaks are generally interspersed with actual music information. This seems to make things difficult when someone tries to maintain a part that has to be transposed a couple different ways, or printed on different paper sizes, or whatever. The web deals with this problem through CSS, and I would suggest that Lilypond might do something similar: let users name timesteps, timestep edges, measures, and categories of such, and format them according to a separate program. Obviously this would be loads of work, and I don't even know if it would be feasible, but that's what I'm thinking. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The new patch, slightly cleaned up, with (I hope) a proper Changelog
David Feuer schreef: Patch now has directory names. David Feuer looks good. -- 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: Patch to get rid of a lot of unnecessary gsave/grestore pairs
I should note that this patch probably has bugs. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The new patch, slightly cleaned up, with (I hope) a proper Changelog
Patch now has directory names. David Feuer newpatchdir.diff Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
implementation plan for music streams
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 the event_source_. 4. Refactor certain iterators (apply-context, time-scaled-music), so that all music events are sent to bottom contexts. 5. Refactor commands such as lyricsto, to eliminate busy-playing-event etc. 6. There should now be no dependency on the try_music return value, so it should be safe to make Translator_group::try_music an event handler. 7. Add stream events for CreateContext, ChangeContext, Prepare, OneTimeStep, SetProperty, etc. These are quite easy to implement. 8. Various cleanups; e.g., remove the unneeded Score_context class. Comments? -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The new patch, slightly cleaned up, with (I hope) a proper Changelog
Han-Wen Nienhuys wrote: Could you also update Documentation/topdocs/AUTHORS.texi and THANKS in a next patch? come to think of it, I already did :) -- 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: Patch to get rid of a lot of unnecessary gsave/grestore pairs
David Feuer wrote: The attached patch stops LilyPond from compulsively gsave/grestoring everything. It changes some procedures so they don't need gsave/grestore, and it adds gsave/grestore and translate to the ones that do. Do you think I should put the gsave/grestore back into draw_polygon, or is it okay as is? umm, good question. I'm not sure, it's starting to be your code more than mine :) I've applied your patch. -- 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: The new patch, slightly cleaned up, with (I hope) a proper Changelog
David Feuer wrote: 2006-04-03 David Feuer <[EMAIL PROTECTED]> * lilyponddefs.ps (set-ps-scale-to-lily-scale): Fixed code duplication. * Cleaned up interfaces between PostScript and Scheme, and moved computations from PostScript to Scheme: * music-drawing-routines.ps (*SF, stroke_and_fill): new procedures. Replaced stroke and fill with stroke_and_fill throughout. (euclidean_length, print_letter, draw_box): Deleted unused procedures. If someone needs draw_box, implement it using draw_round_box; don't duplicate code. (print_glyphs, draw_round_box, draw_polygon, draw_repeat_slash): Refactored/cleaned up interfaces. (mark_URI): Moved. * output-ps.scm: reordered arguments to PostScript functions to match new interfaces (glyph-string): Rewrote glyph-string. (grob-cause): Replaced string-append with format. (repeat-slash): Rewrote to do computation here. (round-filled-box): Rewrote to do computation here. I hope this does it. Thanks. Applied! I have some more requests. For the patch, can send a patch with directory names? The output of diff -ur lilypond-2.9.1.OLD/ lilypond-2.9.1.NEW/ is fine. Alternatively, if you're using CVS, you can take the output of cvs diff -u Could you also update Documentation/topdocs/AUTHORS.texi and THANKS in a next patch? Thanks! -- 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: make web fails for LilyPond 2.8.0/2.9.0 source drop [Also] Re: Futile attempts to build LilyPond 2.8.0
Herman Grootaers wrote: On Tuesday 04 April 2006 10:47, Andreas Scherer wrote: R. Mattes mh-freiburg.de> writes: Ok, i found the "bug". It looks like this is triggered by using guile-1.6.n instead of guile-1.8 - this also explains why Andreas' build failed. Confirmed. After updating OpenSUSE 10.0 with guile-1.8.0, all is well again. "make all web" runs to completion with both the LilyPond 2.8.1 source drop and the 2.9.1 CVS contents. I encountered the same error, But it is not a bug in itself; just that the configure tests against old versions of certain programs, guile and mftrace that i know about. Maybe an action for the main-core developers to update the files which contain old info, so an end-user who is familiar with the normal build-procedure can use it. the goal for 2.8 is to be compatible with guile 1.6 , and it largely is. For 2.9/3.0 we will require guile 1.8, as we'll likely drop our in-house rational number support for GUILE's. -- 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: The new patch, slightly cleaned up, with (I hope) a proper Changelog
David Feuer wrote: Attached is a patch that might be more controversial than the one I just submitted (it goes on top of that one, and is pretty small). This one creates a Scheme macro for using str4 in format calls. I don't know if you'll think it's great or just plain ugly. I'm not sure what I think of it myself. Let me know. I think this is a good intention, but the wrong way to go about this problem. Why not write a wrapper around "format"? Isn't it more logical to write ~4 for a 4 digit precision? There already is ~$ for two digit precision. -- 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: make web fails for LilyPond 2.8.0/2.9.0 source drop [Also] Re: Futile attempts to build LilyPond 2.8.0
On Tuesday 04 April 2006 10:47, Andreas Scherer wrote: > R. Mattes mh-freiburg.de> writes: > > Ok, i found the "bug". It looks like this is triggered > > by using guile-1.6.n instead of guile-1.8 - this also > > explains why Andreas' build failed. > > Confirmed. After updating OpenSUSE 10.0 with guile-1.8.0, all is well > again. "make all web" runs to completion with both the LilyPond 2.8.1 > source drop and the 2.9.1 CVS contents. > I encountered the same error, But it is not a bug in itself; just that the configure tests against old versions of certain programs, guile and mftrace that i know about. Maybe an action for the main-core developers to update the files which contain old info, so an end-user who is familiar with the normal build-procedure can use it. The GUB-option is nice, but has also some restrictions build in, and is not completely user-friendly when you are updating an older version. If I know what to change, I will try to update the CVS for the new versions (2.[89].X). Greetings, Herman Grootaers ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make web fails for LilyPond 2.8.0/2.9.0 source drop [Also] Re: Futile attempts to build LilyPond 2.8.0
R. Mattes mh-freiburg.de> writes: > Ok, i found the "bug". It looks like this is triggered > by using guile-1.6.n instead of guile-1.8 - this also > explains why Andreas' build failed. Confirmed. After updating OpenSUSE 10.0 with guile-1.8.0, all is well again. "make all web" runs to completion with both the LilyPond 2.8.1 source drop and the 2.9.1 CVS contents. Thanks, Ralf, for digging into this. Take care ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make cvsclean?
HiOn 4/4/06, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: I guess not, although I don't personally see the use (my sourcedirectory is a complete mess anyway because I dump all my debugging .lyfiles there)Well, I guess that there are other developers that might need this. I see no problem with the naming (since we've already got distclean and maintainerclean, cvsclean seems like a good name), but I'm not going to argue about that. New patch attached. Please apply. ChangeLog:2006-04-04 Erlend Aasland <[EMAIL PROTECTED]> * stepmake/stepmake/generic-targets.make: add cvs-clean target * stepmake/stepmake/toplevel- targets.make: print help info about cvs-clean--Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwenLilyPond Software Design -- Code for Music Notationhttp://www.lilypond-design.com cvsclean.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Resigning
Hi, I haven't had the time to catch up with all the bugs that have been reported over the past few weeks. This is largely because of Real Life issues (i.e., I haven't had time). Furthermore, I will start a new job next week, which will further restrict my lilypond time. I have concluded that the small amount of time I still will have for lilypond activity, will be best used by hacking (e.g., implementing music streams in the 2.9 branch). So, I'd like to resign from my position as Bug Meister. Is there anyone out there who is willing to take my position? -- Erik ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
