On 2016/08/12 22:04:52, dak wrote:
I repeat:
Can we get to some version of the code where the code paths supposed
to be
equivalent (is there agreement about that?) actually looks the same?
I think the simplest options here are to (1) make the same changes in
both code paths for
https://codereview.appspot.com/308890043/diff/1/lily/dynamic-performer.cc
File lily/dynamic-performer.cc (right):
https://codereview.appspot.com/308890043/diff/1/lily/dynamic-performer.cc#newcode412
lily/dynamic-performer.cc:412: volume = equalize_volume
(Audio_span_dynamic::DEFAULT_VOLUME);
On
On 2016/08/04 23:30:17, Dan Eble wrote:
On 2016/08/04 21:23:12, ht wrote:
> (define-public dynamic-default-volume 0.71)
>
> I wonder whether this (possibly obsolete, "git grep" doesn't show it
being
> currently referenced from anywhere, certainly not from
Dynamic_performer)
> definition
https://codereview.appspot.com/308890043/diff/1/lily/dynamic-performer.cc
File lily/dynamic-performer.cc (right):
https://codereview.appspot.com/308890043/diff/1/lily/dynamic-performer.cc#newcode412
lily/dynamic-performer.cc:412: volume = equalize_volume
(Audio_span_dynamic::DEFAULT_VOLUME);
I
LGTM except for a small question (still) about the process_music logic.
Also, I noticed the following definition in scm/midi.scm:
;; 90 == 90/127 == 0.71 is supposed to be the default value
;; urg: we should set this at start of track
(define-public dynamic-default-volume 0.71)
I wonder
It indeed seems much more logical to associate the Audio_span_dynamic of
each note in Dynamic_performer rather than Staff_performer, and avoid
the side effects caused by identifying Voices by their name in
Staff_performer (in the corner case of identically named Voices).
(I don't really have a
Reviewers: ,
Message:
Hi,
I'm sorry to edit the NR section on output file metadata so soon after
Issue 4921 was fixed, but that issue actually reminded me about the
missing documentation for the "midititle" header variable (which can be
used to set the sequence name for MIDI files independently
In short: LGTM. The rest of this comment is just continuing discussion
on some of the points in your previous response.
On 2016/07/12 05:01:16, Dan Eble wrote:
> What are the main user-level justifications for increasing the
> complexity of the Dynamic_performer
It also improves an example
On 2016/07/11 16:39:01, Carl wrote:
I think the current behavior of changing dynamics
in identically-named but distinct voices is flawed, so I think it
should be a
known issue, not in the main documentation.
I agree that bugs should not be documented as the rules about the
behavior.
Reviewers: ,
Description:
Doc: Add a section about handling MIDI dynamics with multiple voices
As MIDI dynamics of every Voice are by default independent of
dynamic changes occurring in all other Voices, writing LilyPond
input using multiple voices may require some additional
considerations to
Reviewers: ,
Message:
Midi_walker::do_start_note: skip ignored notes in stop_note_queue
For each semitone pitch value, stop_note_queue is likely supposed to
contain
at most one Midi_note event with its "ignore_" flag set to false, and
the
comparisons between notes of equal semitone pitch to be
Do I understand correctly that this change in effect automatically
replaces every { ... CC ... DD ... } (where CC and DD can be either \<
or \>, with no (de)crescendo events between them) with { ... CC ... \!
DD ... }, which has worked "as expected" even before?
Making crescendos immediately
I understand from this patch that you are in favor of removing the
warning altogether, which - I agree - works very inconsistently in
current versions (as demonstrated by the examples in the issues about
the warning). As you yourself have noted on a discussion attached to
issue 4104, however,
This looks great!
Even though this question has little relevance to these code changes, I
can't resist asking whether you might have ideas about the best way to
fix the "reverse" problem of ties attached to *individual notes of a
chord* ending up ignored when processing articulations using the
On 2016/01/21 15:21:22, dak wrote:
I am not happy about the increasing abuse of context properties for
not actually
setting context properties but rather sending Midi messages. The
previous
interfaces at least actually set a queryable property. This one takes
a
pair/value pair instead
Reviewers: ,
Message:
Hi,
This patch introduces an interface for adjusting the values of all MIDI
controllers responding to Control Change events from within LilyPond
input
using context properties. Instead of adding a new context property for
every controller, however, this change adds a
On 2016/01/16 18:50:43, dan_faithful.be wrote:
On Jan 16, 2016, at 13:08 , mailto:ht.lilypond.developm...@gmail.com
wrote:
>
> This patch introduces an interface for adjusting the values of all
MIDI
> controllers responding to Control Change events from within LilyPond
> input
> using
Hi,
Thank you for the quick response to this documentation request, here are
some comments.
I'd like to inform also that the patch (issue 4539) for setting the
sequence name for MIDI files, using the midititle (if set) or
title header variables, got added to the master source tree, so this
On 2015/08/09 13:35:35, Dan Eble wrote:
I'm not sure I understand you properly; is the entire motivation for
this
change? It sounds like Because there can be two ways to do things,
there
should be.
My response is to question whether it is worth maintaining two ways.
Does
articulate.ly
Hi,
This is a small enhancement which I've had lying around for a while...
Since the portato articulation is nowadays supported when generating
MIDI without using articulate.ly, there's really no reason why this
articulation couldn't be supported by articulate.ly as well.
This changeset updates
https://codereview.appspot.com/256230045/diff/1/lily/performance.cc
File lily/performance.cc (right):
https://codereview.appspot.com/256230045/diff/1/lily/performance.cc#newcode41
lily/performance.cc:41: header_ (SCM_EOL)
On 2015/08/06 11:22:27, dak wrote:
On 2015/08/06 11:05:56, ht wrote:
I
https://codereview.appspot.com/256230045/diff/1/lily/include/performance.hh
File lily/include/performance.hh (right):
https://codereview.appspot.com/256230045/diff/1/lily/include/performance.hh#newcode44
lily/include/performance.hh:44: void write_output (string filename,
const string name)
Reviewers: ,
Message:
This patch adds support for setting the MIDI sequence name for MIDI
output files using the value of the midititle field from a relevant
\header block, and falling back to using the title field if
midititle
has not been defined. (This should be analogous to how pdftitle and
Hi James,
Just to let you know, for me the changes to the content have been OK
already since patch set 13 - many thanks for this effort! (Found still
one small typo, though...)
Heikki
https://codereview.appspot.com/120480043/diff/320001/Documentation/notation/input.itely
File
https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/120480043/diff/220001/Documentation/notation/input.itely#newcode2890
Documentation/notation/input.itely:2890: @warning{The
On 2014/10/25 12:09:13, ht wrote:
In the PDF output, this example about changing the default output
file
extension
gets formatted as if it belonged to the known issues list (which I
think is
wrong). A more logical place for these examples would be after the
section on
the MIDI block.
Another batch of minor comments about the latest version (based somewhat
on an assumption of having a list of supported instead of unsupported
MIDI features in the manual - please just ignore the comments if they do
not make sense the other way around).
Some comments based on looking through the articulate.ly script code
(after having made similar observations about the accuracy of the
supported/unsupported lists as Trevor Daniels did).
Since the default behavior of articulations is about to change in the
next release (issue 3664), I'm worried
Here are some comments on minor details (and some technical details as
well). The logical flow of the section has improved a lot!
https://codereview.appspot.com/120480043/diff/11/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/147860043/diff/50001/Documentation/changes.tely
File Documentation/changes.tely (right):
https://codereview.appspot.com/147860043/diff/50001/Documentation/changes.tely#newcode104
Documentation/changes.tely:104: @end example
Just a small note: While this example
Reviewers: J_lowe,
Message:
On 2014/08/05 09:12:06, J_lowe wrote:
This has now been approved, I assume you still have push access so if
so make
sure you push to HEAD:staging and not directly to master.
Having been just an occasional small contributor, I believe I've never
had
direct commit
On 2013/10/06 02:23:00, Keith wrote:
Thanks, Heikki; this looks very good.
Panning will help people to proof-read complex scores by listening to
the MIDI
output. I added an item to the bug tracker to add some documentation
when this
is done.
Thanks. If there's any additional information
32 matches
Mail list logo
