Re: Silently depressed keys

[Heikki Tauriainen]

On Monday, 2016-05-30 at 21:53 -0400, Dan Eble wrote:
> Here’s something else I could use help with.  The person who wrote
> Midi_note decided that a negative (“unknown”?) Audio_dynamic should
> be treated as 90/127, whereas the person who wrote Midi_dynamic
> decided that a negative Audio_dynamic should be treated as
> 100/127.  Unless there is a good reason for this inconsistency, I
> would like to move the default into Audio_dynamic itself; but I’m not
> sure which value to use.  Are these specific values important, or are
> they just two individuals’ fingers in the wind?

I don't know any better about the importance of the particular values
(and haven't thought of whether, and how easily, it would be possible
to actually trigger a case where an Audio_dynamic has a negative
value).

To my understanding, however, Midi_dynamic events are no longer used
for MIDI output by default (as a result of changes for issue #4730),
unless the "encode_dynamics_as_velocity_" flag (hard-coded to be always
true) in Staff_performer::acknowledge_audio_element is set to false
before compiling the code.  Therefore, the default value 100/127 does
probably not get used very much (and could be safely made consistent
with the Midi_note default, for example).

-- 
Heikki Tauriainen

> 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Request for developer status on the issue tracker

[Heikki Tauriainen]

On pe, 2016-01-08 at 16:36 +, Trevor Daniels wrote:
> Heikki, you wrote Friday, January 08, 2016 4:18 PM
> 
> > I still managed (like I always seem to do when I run git-cl with
> > several months having passed since the last time...) to fail to
> > submit
> > a patch with git-cl fully successfully (*), so I had to create a
> > new
> > issue for the tracker (https://sourceforge.net/p/testlilyissues/iss
> > ues/
> > 4730/) manually. I'm sorry if I didn't get the values of all
> > metadata
> > fields right when creating the issue - I'd be grateful for any help
> > whether something still needs to be fixed there.
> 
> Only the Owner field was missing, so I added your username,
> and Accepted the Issue.

Thank you!

Heikki


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Request for developer status on the issue tracker

[Heikki Tauriainen]

On pe, 2016-01-08 at 13:54 +, Trevor Daniels wrote:
> 
> Added to Devs as requested.
> 
> Trevor

Thanks!

I still managed (like I always seem to do when I run git-cl with
several months having passed since the last time...) to fail to submit
a patch with git-cl fully successfully (*), so I had to create a new
issue for the tracker (https://sourceforge.net/p/testlilyissues/issues/
4730/) manually.  I'm sorry if I didn't get the values of all metadata
fields right when creating the issue - I'd be grateful for any help
whether something still needs to be fixed there.

(*) Failing with git-cl was simply my own fault, as I didn't anticipate
(remember) that git-cl would need to open a web browser in the middle
of the patch submission procedure - this didn't work well as I wasn't
logged on in a GUI session, and had to abort the script.

-- 
Heikki Tauriainen


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Request for developer status on the issue tracker

[Heikki Tauriainen]

Hi,

I understand that running git-cl to create new issues requires
developer status on the issue tracker at Sourceforge.  I've just
created a SourceForge account, and would kindly request developer
access to the issue tracker (if possible).  My username at SourceForge
is "htlily".

Thanks,
Heikki


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Support for controlling MIDI expression (issue 114500045 by ht.lilypond.developm...@gmail.com)

[Heikki Tauriainen]

On Wed, 2014-08-06 at 10:52 +0100, James wrote:

> I don't make the decision who has commit access but if you do want it 
> someone hopefully will pipe up here on this list. But if you do have a 
> git formatted patch I can push it for you.

Here it is.  Thanks for the help!

-- 
Heikki Tauriainen

>From f3d8c075180901aeae5cf4610deca5b601a6fc2b Mon Sep 17 00:00:00 2001
From: Heikki Tauriainen 
Date: Sat, 28 Dec 2013 11:49:58 +0200
Subject: [PATCH] Support for controlling MIDI expression

---
 lily/audio-item.cc  | 1 +
 lily/include/audio-item.hh  | 2 +-
 lily/midi-control-function-performer.cc | 1 +
 lily/midi-item.cc   | 1 +
 scm/define-context-properties.scm   | 3 +++
 5 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lily/audio-item.cc b/lily/audio-item.cc
index 8204d45..4d63ff8 100644
--- a/lily/audio-item.cc
+++ b/lily/audio-item.cc
@@ -217,6 +217,7 @@ Audio_control_function_value_change::context_properties_[] = {
   // property name, enum constant, lower bound for range, upper bound for range
   { "midiBalance", BALANCE,  -1.0, 1.0 },
   { "midiPanPosition", PAN_POSITION, -1.0, 1.0 },
+  { "midiExpression",  EXPRESSION,0.0, 1.0 },
   { "midiReverbLevel", REVERB_LEVEL,  0.0, 1.0 },
   { "midiChorusLevel", CHORUS_LEVEL,  0.0, 1.0 },
   // extra element to signify the end of the mapping, must be kept last
diff --git a/lily/include/audio-item.hh b/lily/include/audio-item.hh
index b704743..bd996a5 100644
--- a/lily/include/audio-item.hh
+++ b/lily/include/audio-item.hh
@@ -144,7 +144,7 @@ public:
   // Supported control functions.
   enum Control
   {
-BALANCE = 0, PAN_POSITION, REVERB_LEVEL, CHORUS_LEVEL,
+BALANCE = 0, PAN_POSITION, EXPRESSION, REVERB_LEVEL, CHORUS_LEVEL,
 // pseudo value for representing the size of the enum; must be kept last
 NUM_CONTROLS
   };
diff --git a/lily/midi-control-function-performer.cc b/lily/midi-control-function-performer.cc
index 4269baf..f1bd36f 100644
--- a/lily/midi-control-function-performer.cc
+++ b/lily/midi-control-function-performer.cc
@@ -125,6 +125,7 @@ ADD_TRANSLATOR (Midi_control_function_performer,
 /* read */
 "midiBalance "
 "midiPanPosition "
+"midiExpression "
 "midiReverbLevel "
 "midiChorusLevel ",
 
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index 4909217..514436c 100644
--- a/lily/midi-item.cc
+++ b/lily/midi-item.cc
@@ -393,6 +393,7 @@ Midi_control_function_value_change::to_string () const
 
   {  8, 40 }, // balance
   { 10, 42 }, // pan position
+  { 11, 43 }, // expression
   { 91, -1 }, // reverb level (only coarse resolution available)
   { 93, -1 }  // chorus level (only coarse resolution available)
 };
diff --git a/scm/define-context-properties.scm b/scm/define-context-properties.scm
index b88c8f5..5f92397 100644
--- a/scm/define-context-properties.scm
+++ b/scm/define-context-properties.scm
@@ -458,6 +458,9 @@ associated with the current context.  Ranges from@tie{}@w{-1} to@tie{}1,
 where the values@tie{}@w{-1} (@code{#LEFT}),@tie{}0 (@code{#CENTER})
 and@tie{}1 (@code{#RIGHT}) correspond to hard left, center, and hard
 right, respectively.")
+ (midiExpression ,number? "Expression control for the MIDI
+channel associated with the current context.  Ranges from 0
+to@tie{}1 (0=off,@tie{}1=full effect).")
  (midiReverbLevel ,number? "Reverb effect level for the MIDI
 channel associated with the current context.  Ranges from 0
 to@tie{}1 (0=off,@tie{}1=full effect).")
-- 
2.0.1

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: git-cl: Problems with Rietveld authentication

[Heikki Tauriainen]

On Thu, 2014-07-31 at 13:53 +0300, Heikki Tauriainen wrote:
> On Thu, 2014-07-31 at 10:01 +0100, Phil Holmes wrote:
> > 
> > > However, running "git cl upload origin/master" just keeps failing for me
> > > at the authentication phase with codereview.appspot.com – the script
> > > only repeats "Invalid username or password" despite the fact that I am
> > > able to log in to Rietveld (or to my Google account) via the web
> > > interface using the exact same credentials.
> > 
> > > Has anyone had this kind of problem before?  Is there something I could
> > > do to try and debug it, or work around it?
> > 
> > 
> > There was an earlier report where a contributor was using 2 factor 
> > authentication for their Google account.  Are you using simple 
> > username/password?
> 
> The 2-step verification is disabled on the Google account; username
> +password authentication is sufficient for the Rietveld web login.

Apparently the problem was that access to the Google account was not
enabled for "less secure apps" in the account's security settings;
git-cl worked after changing this option.  Sorry about the noise.

-- 
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: git-cl: Problems with Rietveld authentication

[Heikki Tauriainen]

On Thu, 2014-07-31 at 10:01 +0100, Phil Holmes wrote:
> 
> > However, running "git cl upload origin/master" just keeps failing for me
> > at the authentication phase with codereview.appspot.com – the script
> > only repeats "Invalid username or password" despite the fact that I am
> > able to log in to Rietveld (or to my Google account) via the web
> > interface using the exact same credentials.
> 
> > Has anyone had this kind of problem before?  Is there something I could
> > do to try and debug it, or work around it?
> 
> 
> There was an earlier report where a contributor was using 2 factor 
> authentication for their Google account.  Are you using simple 
> username/password?

The 2-step verification is disabled on the Google account; username
+password authentication is sufficient for the Rietveld web login.

-- 
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

git-cl: Problems with Rietveld authentication

[Heikki Tauriainen]

Hi,

I'm trying to submit a small patch for review by using the git-cl
scripts, trying to follow the instructions in the Contributor's guide.

However, running "git cl upload origin/master" just keeps failing for me
at the authentication phase with codereview.appspot.com – the script
only repeats "Invalid username or password" despite the fact that I am
able to log in to Rietveld (or to my Google account) via the web
interface using the exact same credentials.

Has anyone had this kind of problem before?  Is there something I could
do to try and debug it, or work around it?

(FWIW, the exception which leads the upload.py script to
output the "Invalid username or password" error message in the
AbstractRpcServer._Authenticate method contains the reason
"WebLoginRequired" in its "info" field, however first logging into
Rietveld via the web interface and only then running the script doesn't
help.  I've already tried also reinstalling and reconfiguring git-cl
without success.)

I'll attach the patch in case someone else is willing to open a new
issue for it on my behalf (I'll then add comments about the patch to
that issue), although this will likely make it impossible for me to
update the patch myself later even if I manage to get git-cl working...

Thanks,

-- 
Heikki Tauriainen

>From 6d2c83142168eacbf69a03eea7145fe56c2ebc23 Mon Sep 17 00:00:00 2001
From: Heikki Tauriainen 
Date: Sat, 28 Dec 2013 11:49:58 +0200
Subject: [PATCH] Support for controlling MIDI expression

---
 lily/audio-item.cc  | 1 +
 lily/include/audio-item.hh  | 2 +-
 lily/midi-control-function-performer.cc | 1 +
 lily/midi-item.cc   | 1 +
 scm/define-context-properties.scm   | 3 +++
 5 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/lily/audio-item.cc b/lily/audio-item.cc
index 8204d45..4d63ff8 100644
--- a/lily/audio-item.cc
+++ b/lily/audio-item.cc
@@ -217,6 +217,7 @@ Audio_control_function_value_change::context_properties_[] = {
   // property name, enum constant, lower bound for range, upper bound for range
   { "midiBalance", BALANCE,  -1.0, 1.0 },
   { "midiPanPosition", PAN_POSITION, -1.0, 1.0 },
+  { "midiExpression",  EXPRESSION,0.0, 1.0 },
   { "midiReverbLevel", REVERB_LEVEL,  0.0, 1.0 },
   { "midiChorusLevel", CHORUS_LEVEL,  0.0, 1.0 },
   // extra element to signify the end of the mapping, must be kept last
diff --git a/lily/include/audio-item.hh b/lily/include/audio-item.hh
index b704743..bd996a5 100644
--- a/lily/include/audio-item.hh
+++ b/lily/include/audio-item.hh
@@ -144,7 +144,7 @@ public:
   // Supported control functions.
   enum Control
   {
-BALANCE = 0, PAN_POSITION, REVERB_LEVEL, CHORUS_LEVEL,
+BALANCE = 0, PAN_POSITION, EXPRESSION, REVERB_LEVEL, CHORUS_LEVEL,
 // pseudo value for representing the size of the enum; must be kept last
 NUM_CONTROLS
   };
diff --git a/lily/midi-control-function-performer.cc b/lily/midi-control-function-performer.cc
index 36f2163..29a8fd2 100644
--- a/lily/midi-control-function-performer.cc
+++ b/lily/midi-control-function-performer.cc
@@ -125,6 +125,7 @@ ADD_TRANSLATOR (Midi_control_function_performer,
 /* read */
 "midiBalance "
 "midiPanPosition "
+"midiExpression "
 "midiReverbLevel "
 "midiChorusLevel ",
 
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index 4909217..514436c 100644
--- a/lily/midi-item.cc
+++ b/lily/midi-item.cc
@@ -393,6 +393,7 @@ Midi_control_function_value_change::to_string () const
 
   {  8, 40 }, // balance
   { 10, 42 }, // pan position
+  { 11, 43 }, // expression
   { 91, -1 }, // reverb level (only coarse resolution available)
   { 93, -1 }  // chorus level (only coarse resolution available)
 };
diff --git a/scm/define-context-properties.scm b/scm/define-context-properties.scm
index b88c8f5..5f92397 100644
--- a/scm/define-context-properties.scm
+++ b/scm/define-context-properties.scm
@@ -458,6 +458,9 @@ associated with the current context.  Ranges from@tie{}@w{-1} to@tie{}1,
 where the values@tie{}@w{-1} (@code{#LEFT}),@tie{}0 (@code{#CENTER})
 and@tie{}1 (@code{#RIGHT}) correspond to hard left, center, and hard
 right, respectively.")
+ (midiExpression ,number? "Expression control for the MIDI
+channel associated with the current context.  Ranges from 0
+to@tie{}1 (0=off,@tie{}1=full effect).")
  (midiReverbLevel ,number? "Reverb effect level for the MIDI
 channel associated with the current context.  Ranges from 0
 to@tie{}1 (0=off,@tie{}1=full effect).")
-- 
2.0.1

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB failing

[Heikki Tauriainen]

On Sun, 2013-10-20 at 15:32 +0200, David Kastrup wrote:
> "Phil Holmes"  writes:
> 
> > So will we have to wait for Heikki to provide a fix, or are you able
> > to fix it yourself?
> 
> Pushed a fix to staging.

This patch just keeps on giving trouble...  I'm very sorry for breaking
things this badly for other people, this certainly never was my
intention.

(I wasn't aware of the existence of "my_round", although this could've
again be remedied by just studying more of the existing code, and in
searching the manpages for a suitable standard library function, I made
the unfortunate additional mistake of not checking whether "lround" had
been part of any pre-C++11 standard.  Thanks for fixing this on my
behalf.)


A small question out of curiosity (and ignorance, I'm not familiar with
the nature of the automatic checks that are made on submitted patches):
why wasn't this problem caught before the issue was allowed to enter the
"Patch-push" stage?  (According to the issue page
<http://code.google.com/p/lilypond/issues/detail?id=3581>, several
versions of the patchset managed to pass make.  Ideally, this step
should probably have failed to prevent the patch from proceeding any
further through the stages...)

-- 
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Patch: Setting pan, chorus and reverb in MIDI

[Heikki Tauriainen]

Hi,

Here are the Git-formatted patches for issue 3581
<http://code.google.com/p/lilypond/issues/detail?id=3581>, corresponding
to the latest patchset on Rietveld
<https://codereview.appspot.com/14434043>.

(The patches reached the "push" status on 16th October, but, if this
means that they have now also been approved for inclusion in the
codebase, they still need to be picked up by someone who can push them
to staging since I don't have the access rights to do this.)

Thanks to the development team for all the comments and help that I got
during the patch submission and review process.  I'm sorry for all the
extra work that I may have caused you especially in starting it - thanks
for the patience!

-- 
Heikki Tauriainen


>From 5cf487c93861c600c1cb9ea8fdc9345d7967db93 Mon Sep 17 00:00:00 2001
From: Heikki Tauriainen 
Date: Sat, 19 Oct 2013 09:56:37 +0300
Subject: [PATCH 1/5] Issue 3581: New data types for adjusting MIDI control
 functions

---
 lily/audio-item.cc | 16 ++
 lily/include/audio-item.hh | 32 
 lily/include/lily-proto.hh |  2 ++
 lily/include/midi-item.hh  | 15 ++
 lily/midi-item.cc  | 73 ++
 5 files changed, 138 insertions(+)

diff --git a/lily/audio-item.cc b/lily/audio-item.cc
index b7a5ef2..a41357b 100644
--- a/lily/audio-item.cc
+++ b/lily/audio-item.cc
@@ -204,3 +204,19 @@ Audio_text::Audio_text (Audio_text::Type type, const string &text_string)
   type_ = type;
 }
 
+Audio_control_function_value_change
+::Audio_control_function_value_change (Control control, Real value)
+  : control_ (control), value_ (value)
+{
+}
+
+const Audio_control_function_value_change::Context_property
+Audio_control_function_value_change::context_properties_[] = {
+  // property name, enum constant, lower bound for range, upper bound for range
+  { "midiBalance", BALANCE,  -1.0, 1.0 },
+  { "midiPanPosition", PAN_POSITION, -1.0, 1.0 },
+  { "midiReverbLevel", REVERB_LEVEL,  0.0, 1.0 },
+  { "midiChorusLevel", CHORUS_LEVEL,  0.0, 1.0 },
+  // extra element to signify the end of the mapping, must be kept last
+  { 0, NUM_CONTROLS,  0.0, 0.0 }
+};
diff --git a/lily/include/audio-item.hh b/lily/include/audio-item.hh
index 544dd83..43ed2e0 100644
--- a/lily/include/audio-item.hh
+++ b/lily/include/audio-item.hh
@@ -137,6 +137,38 @@ public:
   int one_beat_;
 };
 
+class Audio_control_function_value_change : public Audio_item
+{
+public:
+  // Supported control functions.
+  enum Control
+  {
+BALANCE = 0, PAN_POSITION, REVERB_LEVEL, CHORUS_LEVEL,
+// pseudo value for representing the size of the enum; must be kept last
+NUM_CONTROLS
+  };
+
+  Audio_control_function_value_change (Control control, Real value);
+
+  // Information about a context property corresponding to a control function
+  // (name, the corresponding enumeration value, and the allowed range for the
+  // value of the context property).
+  struct Context_property
+  {
+const char *name_;
+Control control_;
+Real range_min_;
+Real range_max_;
+  };
+
+  // Mapping from supported control functions to the corresponding context
+  // properties.
+  static const Context_property context_properties_[];
+
+  Control control_;
+  Real value_;
+};
+
 int moment_to_ticks (Moment);
 Real moment_to_real (Moment);
 Moment remap_grace_duration (Moment);
diff --git a/lily/include/lily-proto.hh b/lily/include/lily-proto.hh
index 53e863c..80240d5 100644
--- a/lily/include/lily-proto.hh
+++ b/lily/include/lily-proto.hh
@@ -24,6 +24,7 @@
 
 class All_font_metrics;
 class Audio_column;
+class Audio_control_function_value_change;
 class Audio_dynamic;
 class Audio_element;
 class Audio_instrument;
@@ -104,6 +105,7 @@ class Lyric_performer;
 class Lyric_phrasing_engraver;
 class Mensural_ligature_engraver;
 class Midi_chunk;
+class Midi_control_function_value_change;
 class Midi_duration;
 class Midi_dynamic;
 class Midi_event;
diff --git a/lily/include/midi-item.hh b/lily/include/midi-item.hh
index c5a9cc9..492e2e9 100644
--- a/lily/include/midi-item.hh
+++ b/lily/include/midi-item.hh
@@ -46,11 +46,26 @@ public:
 class Midi_channel_item : public Midi_item
 {
 public:
+  virtual ~Midi_channel_item ();
   int channel_;
   DECLARE_CLASSNAME (Midi_channel_item);
   Midi_channel_item (Audio_item *ai);
 };
 
+/**
+   Midi control function value changes.
+*/
+class Midi_control_function_value_change : public Midi_channel_item
+{
+public:
+  DECLARE_CLASSNAME (Midi_control_function_value_change);
+  Midi_control_function_value_change (Audio_control_function_value_change *ai);
+  virtual ~Midi_control_function_value_change ();
+  virtual string to_string () const;
+  Audio_control_function_value_change::Control control_;
+  Real value_;
+};
+
 class Midi_duration : public Midi_item
 {
 public:
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index 0

Re: Patch: Setting pan, chorus and reverb in MIDI

[Heikki Tauriainen]

Quoting Janek Warcho? :


As for the patches themselves, are you using Git?  It would be
slightly more convenient for us if you sent us "Git-formatted" patches
(i.e. patches representing complete git commits), [...]


Here are the Git-formatted patches.

--
Heikki Tauriainen

>From b50ccdc9e06acc1bd8a909e06f83b88fbf8cbc86 Mon Sep 17 00:00:00 2001
From: Heikki Tauriainen 
Date: Sat, 21 Sep 2013 23:17:55 +0300
Subject: [PATCH 1/4] Fix definition of default MIDI instrument in
 performer-init.ly

---
 ly/performer-init.ly | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ly/performer-init.ly b/ly/performer-init.ly
index 816bb2f..9fb4dff 100644
--- a/ly/performer-init.ly
+++ b/ly/performer-init.ly
@@ -193,7 +193,7 @@
   \name Score
 
   melismaBusyProperties = #default-melisma-properties
-  instrumentName = #"bright acoustic"
+  midiInstrument = #"bright acoustic"
   midiChannelMapping = #'staff
 
   %% quarter = 60
-- 
1.8.4.rc3

>From 10f023acfc259957586635dd06bc2c02fd491783 Mon Sep 17 00:00:00 2001
From: Heikki Tauriainen 
Date: Sat, 21 Sep 2013 23:18:28 +0300
Subject: [PATCH 2/4] New data types for controlling pan position, reverb and
 chorus levels

---
 lily/audio-item.cc | 19 ++
 lily/include/audio-item.hh | 26 +++
 lily/include/lily-proto.hh |  8 ++
 lily/include/midi-item.hh  | 39 +
 lily/midi-item.cc  | 62 ++
 5 files changed, 154 insertions(+)

diff --git a/lily/audio-item.cc b/lily/audio-item.cc
index b7a5ef2..d7cbced 100644
--- a/lily/audio-item.cc
+++ b/lily/audio-item.cc
@@ -204,3 +204,22 @@ Audio_text::Audio_text (Audio_text::Type type, const string &text_string)
   type_ = type;
 }
 
+Audio_controller_value_change::Audio_controller_value_change (int value)
+  : value_ (value)
+{
+}
+
+Audio_pan_position::Audio_pan_position (int position)
+  : Audio_controller_value_change (position)
+{
+}
+
+Audio_reverb_level::Audio_reverb_level (int level)
+  : Audio_controller_value_change (level)
+{
+}
+
+Audio_chorus_level::Audio_chorus_level (int level)
+  : Audio_controller_value_change (level)
+{
+}
diff --git a/lily/include/audio-item.hh b/lily/include/audio-item.hh
index 544dd83..ed594f9 100644
--- a/lily/include/audio-item.hh
+++ b/lily/include/audio-item.hh
@@ -137,6 +137,32 @@ public:
   int one_beat_;
 };
 
+class Audio_controller_value_change : public Audio_item
+{
+public:
+  Audio_controller_value_change (int value);
+
+  int value_;
+};
+
+class Audio_pan_position : public Audio_controller_value_change
+{
+public:
+  Audio_pan_position (int position);
+};
+
+class Audio_reverb_level : public Audio_controller_value_change
+{
+public:
+  Audio_reverb_level (int level);
+};
+
+class Audio_chorus_level : public Audio_controller_value_change
+{
+public:
+  Audio_chorus_level (int level);
+};
+
 int moment_to_ticks (Moment);
 Real moment_to_real (Moment);
 Moment remap_grace_duration (Moment);
diff --git a/lily/include/lily-proto.hh b/lily/include/lily-proto.hh
index 53e863c..8873677 100644
--- a/lily/include/lily-proto.hh
+++ b/lily/include/lily-proto.hh
@@ -23,14 +23,18 @@
 #include "flower-proto.hh"
 
 class All_font_metrics;
+class Audio_chorus_level;
 class Audio_column;
+class Audio_controller_value_change;
 class Audio_dynamic;
 class Audio_element;
 class Audio_instrument;
 class Audio_item;
 class Audio_key;
 class Audio_note;
+class Audio_pan_position;
 class Audio_piano_pedal;
+class Audio_reverb_level;
 class Audio_staff;
 class Audio_tempo;
 class Audio_text;
@@ -103,7 +107,9 @@ class Lyric_engraver;
 class Lyric_performer;
 class Lyric_phrasing_engraver;
 class Mensural_ligature_engraver;
+class Midi_chorus_level;
 class Midi_chunk;
+class Midi_controller_value_change;
 class Midi_duration;
 class Midi_dynamic;
 class Midi_event;
@@ -114,7 +120,9 @@ class Midi_key;
 class Midi_note;
 class Midi_note_event;
 class Midi_note_off;
+class Midi_pan_position;
 class Midi_piano_pedal;
+class Midi_reverb_level;
 class Midi_stream;
 class Midi_tempo;
 class Midi_text;
diff --git a/lily/include/midi-item.hh b/lily/include/midi-item.hh
index c5a9cc9..89396dc 100644
--- a/lily/include/midi-item.hh
+++ b/lily/include/midi-item.hh
@@ -46,11 +46,23 @@ public:
 class Midi_channel_item : public Midi_item
 {
 public:
+  virtual ~Midi_channel_item ();
   int channel_;
   DECLARE_CLASSNAME (Midi_channel_item);
   Midi_channel_item (Audio_item *ai);
 };
 
+class Midi_controller_value_change : public Midi_channel_item
+{
+public:
+  DECLARE_CLASSNAME (Midi_controller_value_change);
+  Midi_controller_value_change (Audio_controller_value_change *ai);
+  virtual ~Midi_controller_value_change ();
+  virtual int get_controller_number () const = 0;
+  virtual string to_string () const;
+  int value_;
+};
+
 class Midi_duration : public Midi_item
 {
 public:
@@ -175,4 +187,31 @@ public:
   Audio

Re: Patch: Setting pan, chorus and reverb in MIDI

[Heikki Tauriainen]

David Kastrup  gnu.org> writes:

> Heikki Tauriainen  welho.com> writes:
> 
> > In short, these patches will add the following three context properties
> > for controlling additional MIDI parameters:
> >
> > Staff.midiPanPosition   [an integer from 0 to 127]
> >  Pan position (0 = hard left, 64 = center, 127 = hard right)
> 
> Should be #LEFT hard left  #CENTER center  #RIGHT  hard right.
> 
> The range is not entirely symmetric.  Pan has a fine control also where
>  is left, 2000 is center, and 3fff is hard right.  I think I'd use
> the conversion formula
> round ((dir+1)*max/2)
> where max is the available maximal value and round is the normal
> round-to-even rule.

It seems to be recommended that synthesizers should treat both values 0 and
1 as "hard left" to overcome the problem of having no way to represent the
exact center position otherwise (see <http://www.midi.org/techspecs/rp36.php>).

As to the "fine control" (14-bit) values, I didn't consider them (again for
simplicity) since, according to the source that I used as a reference
(<http://home.roadrunner.com/~jgglatt/tech/midispec/pan.htm>; this is only a
secondary source, but I don't own a copy of the official MIDI specification):

   Most all devices ignore the Fine adjust (#42) for Pan, and just 
   implement Coarse adjust (#10) because 14-bit resolution isn't needed for 
   this.

Of course, this statement doesn't necessarily give sufficient reason to
restrict support for setting the pan position to 7-bit accuracy.
 
> > Staff.midiReverbLevel   [an integer from 0 to 127]
> >  Reverb effect level (0 = no effect, 127 = full effect)
> > Staff.midiChorusLevel   [an integer from 0 to 127]
> >  Chorus effect level (0 = no effect, 127 = full effect)
> 
> Effects should probably scale from 0 to 1 rather than 0 to 127.

This is certainly true if the goal is to have the new settings behave like
the current settings for adjusting MIDI velocity (volume).

On the other hand, it could be worth considering if it were (even if the
values were scaled by default) possible to still have a way to control the
actual controller values that will end up in the generated MIDI files
directly so that the scaling does not "get in the way" of those who think
they know better what they're doing (and are used to thinking in terms of
the 0–127 range used in MIDI).  When thinking in this range, the additional
scaling just forces one to perform extra calculations.

One way to achieve this could possibly be to implement the scaled versions
of controlling the MIDI parameters using higher-level music functions which
set the properties by converting input values in the 0.0 to 1.0 range to the
"raw" integer values in the 0–127 range, and have the low-level properties
work using the 0–127 range.  The same could be done the other way around, of
course (that is, provide music functions which take care of scaling values
given in the 0–127 range to the 0.0 to 1.0 range for the properties,
although in this case the values in the input will end up being converted
from one range into another and then back).

I don't have any strong opinions about whether the effect parameters should
be given in the 0.0 to 1.0 range or not as I am no expert on neither
LilyPond design principles nor MIDI.

> I don't see "Balance".

It's hard to see something that isn't there... please don't read too much
into this omission, I only picked a set of properties that I remember having
seen in some software synthesizers just as a first attempt. Now that there's
possibly a mechanism available to handle changes to MIDI controller values,
it's easy to extend the implementation with support for additional
controllers which differ only in their control number.

(If I'd not considered ever sharing my changes to the code, I'd probably
have been satisfied with just a single new property to set the value of an
arbitrary controller, instead of defining explicit properties for separate
controllers.  However, this seemed to be against the existing principle of
having separate Midi_items in the code for representing different controls,
so I tried to keep following this design.  The idea of having a more generic
property to set the value of "any" controller might become more attractive
if the number of control numbers that need to be supported grows significantly.)

-- 
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Patch: Setting pan, chorus and reverb in MIDI

[Heikki Tauriainen]

n to SetProperty events in the first place –
   couldn't the MIDI parameter changes be handled by listening to some
   other type of events (such as note events) instead, similar to how
   changes in MIDI instruments are already handled?   This is because I
   wanted to try whether I could implement support for constructs such as
   those used in the above example, where MIDI parameters may vary even in
   between individual notes.  (This could possibly be useful also if one
   were to try to implement more fine-grained control over MIDI volume for
   (de)crescendos.)  Since there's no note event between the tied notes, a
   performer listening to such events wouldn't be able to react to the
   change in the MIDI parameter at the proper moment in time.  (Maybe the
   same end result could be alternatively achieved by listening also to
   skip events.  Hmm.)

   
   Allow customizing implementations of Translator::connect_to_context and
   Translator::disconnect_from_context
   <http://koti.welho.com/htauriai/lilypond/translator.diff>
   


4. The final patch in this set adds code to introduce new context
   properties for changing the additional MIDI parameters, and to actually
   handle them in the input (by defining a new performer which will listen
   to SetProperty events as described above).

   Again, my first attempt at doing this was to try to make
   Staff_performer itself listen to SetProperty events and then add the
   relevant new Audio_items to the performer's Audio_staff objects in
   Staff_performer::acknowledge_audio_element, just as is done for note
   events.  (Handling the property change events requires determining the
   MIDI channel similarly to MIDI instrument changes, and access to an
   Audio_staff, hence the interest in
   Staff_performer::acknowledge_audio_element.)

   In the end (likely due to my still very poor understanding of the
   interaction of the various functions that get called in the translation
   process), I wasn't able to get this to work since I couldn't get
   Staff_performer to acknowledge audio elements that it had announced
   itself.

   For this reason, I created a new Midi_effect_performer class whose job
   is to announce the MIDI controller changes: just like note events,
   Staff_performer seems to have no problems acknowledging elements
   announced by this separate performer (after adding it to every Staff
   context defined in ly/performer-init.ly).  As a result, however, the
   implementation of handling the property changes is distributed among
   Midi_effect_performer and Staff_performer – I still wonder whether
   this could somehow be avoided.

   Furthermore, I am open to any suggestions about better default values
   to use for MIDI reverb and MIDI chorus levels (in ly/performer-init.ly)
   without altering previous behaviour too much (if this behaviour has
   been well-defined)  The patch will initialize both levels to their
   "50 %" values by default.

   
   Add support for setting MIDI pan position, reverb level, and chorus
   levels
   <http://koti.welho.com/htauriai/lilypond/handle-midi-effects.diff>
   


In summary, this series of patches appears to succeed in implementing the
new functionality (I've personally used it with success), but there might
still be room for many simplifications in the implementation.

Also, the changes made in the patches will alter the output of some of the
existing regression tests since the contents of generated MIDI files will
be different from before (the files will have additional controller events
to set default initial values for the new MIDI parameters, and possibly
also additional Program Change events to set the MIDI instrument to the
default one if this was not originally specified in the input file).  I've
run comparisons for the regression tests: besides these additions, the
only other changes I could see was some shuffling of MIDI events occurring
at the same moment in time, which I believe is harmless (as long as any
new "note on" events still appear last among these events).


Thank you for you attention,
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] Notes (and possible fixes) for several small problems with MIDI output (issue #1661 among others)

[Heikki Tauriainen]

David Kastrup wrote:


Heikki Tauriainen  writes:

> Since there appears to be only infrequent discussion on
> open issues related to MIDI output and their possible workarounds on
> the mailing lists -- I guess simply because the vast majority of
> people use LilyPond mainly for music typesetting --

It's more like "the code is undocumented, inaccessible from Scheme, and
the only one who knows how it works and what it does is Jan".


I see.


> I wouldn't be at all
> surprised if some of my patches to the C++ code could be implemented
> in a much more elegant way with just a few lines of Scheme in some
> appropriate place :-)

For the MIDI code?  Unlikely.


Well, since the first two issues seem to be essentially caused by the
variance in the ordering in which Audio_items occurring at the same time
are fed to various worker classes (Midi_walker and Staff_performer in this
case), I could imagine that -- if there is some higher-level layer of code
which handles this generic process in both cases (taking the events from
some common Audio_item stream) -- the prioritization of events occurring
at the same time would probably be better handled in this layer instead of
fixing the event ordering separately in every low-level layer whose
correctness depends on a sub-ordering of simultaneous events.

As I wrote, I didn't really have a good picture about the interaction of
the various parts of the code to have known where to look for the
implementation of this generic process (if there is such a layer), so
I focused on the low-level modules instead just to see if I could make
things work.  I fully understand that it wasn't probably the best
approach.


It would be nice to open MIDI more to user-level programming.
However, that would require looking more into the Guile
side of things and design useful interfaces harmonizing with the rest:
not exactly a task put at the feet of someone just starting to get
acquainted with the code.


I also suspect that this is more of a design issue (what kind of
interfaces to offer for user-level MIDI programming, whether the added
interfaces fit well with the old behavior, and if not, whether the
default behavior should be changed) than an implementation issue (as to
how much code is actually needed to implement support for these
interfaces).  Before starting to plan a new design, it is obviously
critical to first have a good understanding of the overall architecture.
I don't really consider myself knowledgeable enough at this point to be
able to contribute to such a design process in any useful way expect for
possibly sharing my experiences (and some misconceptions and surprises
I've had as a user) with the current behavior.


Usually, the order of looking at music events is established by the
order of performers (check ly/performer-init.ly) and by the particular
hooks they use for getting information (listening to events, waiting for
start/end of time step and so on).

It is quite conceivable that juggling with those areas can bring the
order of MIDI events into shape already.


Thanks for the information.  Maybe I'll have a look at this part of the
code to see whether I could learn more about these interactions.

--
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Notes (and possible fixes) for several small problems with MIDI output (issue #1661 among others)

[Heikki Tauriainen]

-- Example 3 --

\book {
  \score {
\new Staff \with {
  midiInstrument = #"oboe"
  midiMinimumVolume = #0.1
  midiMaximumVolume = #0.2
} \new Voice {
  % These notes will sound louder than should be allowed.
  c'4_\< c'4 c'4 r4\!
  % This note sounds at the maximum allowed volume (scm/midi.scm)
  c'2._\sf r4
}
\midi { }
  }
}

--


Analysis:

The Dynamic_performer (lily/dynamic-performer.cc) class uses its
last_volume_ member variable to keep track of the current volume (an
absolute value between 0.0 and 1.0).  All explicit dynamic markings change
this current volume within the permitted absolute volume range (as
documented in the Notation Reference).  However, since the example does not
begin with an explicit dynamic marking, the volume at the beginning of the
crescendo will end up being the unequalized default value of last_volume_
(0.5, which is greater than the maximum allowed volume in this example).


Proposed fix:

Ensure that last_volume_ is equalized even if the first dynamic event in a
Voice context is a (de)crescendo instead of an explicit dynamic marking.
Also display a warning since using even the equalized value 0.5 is not
necessarily what the user expects since Dynamic_performers "do not get
inherited" from their enclosing contexts, as might be incorrectly expected
by looking only at the generated notation, in an example such as

\book {
  \score {
\new Staff {
  \new Voice {
c'2\sf
<<
  \new Voice = "A" { \voiceOne g'^\sf g' g' }
  \new Voice = "B" { \voiceTwo c'_\> c' c'\p }
>>
  }
}
\layout { }
\midi { }
  }
}

(Here, the first c' in \voiceTwo will already sound quieter than the first
note of the outermost Voice.  With the patch, a warning will be shown in
this case.)


Link to patch:

<http://koti.welho.com/htauriai/lilypond-patches/initial-volume.diff>

Affected file(s): lily/dynamic-performer.cc



== PATCH: (de)crescendos terminated with \! ==

This is not really a defect, but just a minor update to the patch I sent to
the lilypond-user mailing list in last September
<http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00134.html>
concerning respecting MIDI volume ranges with (de)crescendos terminated with
\!.  On these (de)crescendos, LilyPond will try to decrease or increase the
current absolute volume by 0.25 (keeping the absolute volume always between
0.1 and 1.0, however); my previous fix just changed the the fixed limits 0.1
and 1.0 to the corresponding equalized volumes.

The patch below will change the attempted (fixed 0.25) change in the
absolute volume to 1/4 of the allowed volume range instead to reduce
the possibility of immediately hitting the minimum/maximum volume on
instruments given only a very narrow volume range.


Link to patch:

<http://koti.welho.com/htauriai/lilypond-patches/volume-range.diff>

Affected file(s): lily/audio-item.cc



== DISCLAIMER ==

I consider myself just a LilyPond user who occasionally lurks on the mailing
lists (but who also happens to a coder, and hardly at all a musician).
Since there appears to be only infrequent discussion on open issues related
to MIDI output and their possible workarounds on the mailing lists -- I
guess simply because the vast majority of people use LilyPond mainly for
music typesetting -- I thought that I'd have the best chance of getting
rid of some minor annoyances in LilyPond's MIDI output if I tried to analyze
the problems and fix them myself.  Unfortunately, I'm only learning and
guessing things about the inner workings of LilyPond mostly as I try to read
and understand the source code, and I'm sure this lack of familiarity with
the organization of the code is reflected (badly) in the quality of the
patches -- for example, I wouldn't be at all surprised if some of my
patches to the C++ code could be implemented in a much more elegant way
with just a few lines of Scheme in some appropriate place :-) )  Anyway,
I decided to share my observations and patches in case they might still be
of help to improve the behavior of this excellent application.


--
Heikki Tauriainen



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel