Needs a tweak for \endSpanners
http://codereview.appspot.com/5440084/diff/14005/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/5440084/diff/14005/ly/music-functions-init.ly#newcode296
ly/music-functions-init.ly:296: (if (memq
Great work David. I like how \harmonic works properly for single notes
now. :)
http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc
File lily/music-scheme.cc (right):
http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc#newcode79
lily/music-scheme.cc:79: Is
On 2012/01/24 22:47:31, Neil Puttock wrote:
Great work David. I like how \harmonic works properly for single
notes now. :)
As opposed to an earlier version of the patch or to LilyPond's previous
behavior?
All of your code comments are quite spot on and touch some sore spots
that I decided
http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc
File lily/music-scheme.cc (right):
http://codereview.appspot.com/5440084/diff/14005/lily/music-scheme.cc#newcode79
lily/music-scheme.cc:79: Is @var{obj} a proper (non-rhythmic) event
object?)
On 2012/01/24 22:47:32, Neil
Ok, this latest iteration is quite close to what I want to end up
committing. All the work of picking apart articulations and events have
gone into the rhythmic event iterator. What it does is to broadcast all
articulations that have a listener, and keep the rest as articulations.
One side
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy#newcode432
lily/parser.yy:432: %type scm list_music
I must *strongly* recommend that the name of either music_list or
list_music be changed.
http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc#newcode62
lily/rhythmic-music-iterator.cc:62: if (scm_is_true
ly_lily_module_constant
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy
File lily/parser.yy (right):
http://codereview.appspot.com/5440084/diff/7001/lily/parser.yy#newcode432
lily/parser.yy:432: %type scm list_music
On 2012/01/20 13:55:56, md5i wrote:
I must *strongly* recommend that the name of either
On 2012/01/20 14:08:18, MikeSol wrote:
http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5440084/diff/11001/lily/rhythmic-music-iterator.cc#newcode62
On 2012/01/20 14:55:38, dak wrote:
On 2012/01/20 14:08:18, MikeSol wrote:
Otherwise, it's better to use the C++ function. In this case:
ly_is_listened_event_class
(in translator.cc)
Will do.
Very funny. After putting the (required) prototype into
translator.hh, it takes hours to
On 2012/01/20 15:33:07, dak wrote:
Should I be forking the rhythmic-music-iterator stuff into the
separate review
I'd say leave it with this - it's easy to forget that two patches need
to be tested in concert.
http://codereview.appspot.com/5440084/
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
- error: syntax error, unexpected EVENT_IDENTIFIER
\foo
If I add a note
n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
\relative c' {
\foo
c1
}
You have the newest. The problem is
On 2012/01/20 17:33:44, dak wrote:
mailto:n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one
here?
I've tried it out briefly on a real music example, and have a
problem
with identifiers:
foo = \mark \default
\relative c' {
On 20 January 2012 17:32, David Kastrup d...@gnu.org wrote:
n.putt...@gmail.com writes:
Hi David,
Should I wait for a new patch or can I test using the latest one here?
I've tried it out briefly on a real music example, and have a problem
with identifiers:
foo = \mark \default
On 2012/01/20 17:59:40, Neil Puttock wrote:
I can't think of anything better than adding another type such as
`command-event' to things like TempoChangeEvent and MarkEvent and
filtering that out too.
Emacs stands for Editor Macros.
;; Keyboard Macro Editor. Press C-c C-c to finish; press
Wow -- what a lot of work. And it really seems to be cleaning things
up!
Thanks!
http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm
File scm/modal-transforms.scm (right):
http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm#newcode129
http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm
File scm/modal-transforms.scm (right):
http://codereview.appspot.com/5440084/diff/11001/scm/modal-transforms.scm#newcode129
scm/modal-transforms.scm:129: (define (make-scale music)
On 2012/01/20 23:02:21, Carl wrote:
I'm
Ok, I need some pointers here. In order to make this work compatibly at
the lowest level, articulations need to behave differently depending on
whether they are on note events that are children of an EventChord
(which all of them are currently) or not.
Ok, so now since I don't actually have a
Reviewers: MikeSol,
Message:
On 2011/12/02 19:50:03, MikeSol wrote:
Hey David,
This patch is way over my head, so I can't really comment on the
details of the
implementation, but I just wanted to voice one concern for me (and
possibly
other) algorithmic composers.
I have a lot of
Hey David,
This patch is way over my head, so I can't really comment on the details
of the implementation, but I just wanted to voice one concern for me
(and possibly other) algorithmic composers.
I have a lot of algorithms written that comb through music streams and
finagle with the elements.
21 matches
Mail list logo
