On Mon, Apr 18, 2011 at 4:49 AM, <percival.music...@gmail.com> wrote: > > http://codereview.appspot.com/4373046/diff/12001/input/regression/event-listener-output.ly > File input/regression/event-listener-output.ly (right): > > http://codereview.appspot.com/4373046/diff/12001/input/regression/event-listener-output.ly#newcode5 > input/regression/event-listener-output.ly:5: listeners. The .notes file > which is output from this file is not > On 2011/04/18 03:50:59, hanwenn wrote: >> >> please make this print whatever is relevant with ly:progress, so we > > can catch >> >> differences > > done, I think. It looks a bit cludgy to me, but I definitely don't want > to spam stuff to ly:progress all the time, or else it would be a pain to > use it in real life.
I cant see any changes. Did you upload? > http://codereview.appspot.com/4373046/diff/12001/input/regression/event-listener-output.ly#newcode7 > input/regression/event-listener-output.ly:7: done during the Grand > Organization Project." > On 2011/04/18 03:50:59, hanwenn wrote: >> >> can you put remarks like this in the bug tracker instead? > > no need with the new EVENT_LISTENER_CONSOLE_OUTPUT trick. > > http://codereview.appspot.com/4373046/diff/12001/ly/event-listener.ly > File ly/event-listener.ly (right): > > http://codereview.appspot.com/4373046/diff/12001/ly/event-listener.ly#newcode21 > ly/event-listener.ly:21: % http://percival-music.ca/vivi.html > On 2011/04/18 03:50:59, hanwenn wrote: >> >> frankly, I don't understand why this should be part of lilypond? Can > > you expand >> >> on what other uses it may have? > > Recent requests: > http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00728.html > http://lists.gnu.org/archive/html/lilypond-user/2010-01/msg00657.html > > solution inspired by: > http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00884.html > > Of course different researchers may want to examine different aspects of > the output; the documentation will address that, and once they've > modified event-listener.ly to their liking, they might send patches back > to us. The important thing IMO is to have the basic framework there, so > that researchers know that it's possible (and ideally how to get > started). FWIW, it looks as if you're mostly interested in this at the musical-semantic level. In that case, it would probably be cleaner to hook into the event listener framework directly, without having an engraver in between. The Scheme engraver mechanism is really for creating formatted output rather than siphoning off data. >> Document output format, perhaps with a small example. > > I like small, focused patches. Documentation comes after the code is > pushed. it's hard to do a sensible code review if I can't see what the code is meant for. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
