Extension of keyboard mapping - disabling sections of the keyboard.

[GoogleCodeExporter]

When using multiple instances of amsynth concurrently I often find myself 
wanting to map different voices to different segments of the keyboard - for 
example, assigning a bass or pad voice to the lower half of the keyboard and a 
lead to the upper half.  Scala keyboard maps don't provide this functionality, 
so I decided to implement it myself - is this something that people would be 
interested in having added to the project?

To make use of it within a scala keyboard map one would add lines at any point 
in the file with the layout '<range> X Y' where X is the lower limit of the 
active range and Y is the upper limit, inclusive at both boundaries.  An 
arbitrary number of these ranges can be specified.  If none are included then 
the entire keyboard is considered active, as prior to my change.

The implementation is extremely simple - a few extra lines in the keyboard map 
parser and an extra Boolean array in TuningMap keeping track of the 'active' 
MIDI notes.  This array is checked at the index of the current note at the 
beginning of the MIDI event on/off handlers in VoiceAllocationUnit.

Another not-quite-related little feature I implemented is a wee text-entry 
beside the audition button, allowing users to specify the MIDI note they want 
auditioned.  I think that it's a worthwhile and related addition because it 
makes it a lot easier for users to determine which MIDI note numbers correspond 
to each on their keyboards.

I've attached a diff - let me know what you think.

Original issue reported on code.google.com by joshua.t...@gmail.com on 12 Aug 2013 at 11:27

Attachments:

• ActiveRangePatch.diff

[GoogleCodeExporter]

I was hoping I'd be able to change this issue to an enhancement after the fact, 
but that doesn't seem to be the case.  That was my intention in posting it.

Original comment by joshua.t...@gmail.com on 12 Aug 2013 at 11:31

[GoogleCodeExporter]

Hi, thanks for the patch.

Keyboard zones
--------------

Cool feature.

I'm a bit uneasy with the idea of extending the scala file format in this way, 
so am still considering this change.

How does it work in practice - you make a scala file for each instance and load 
them in the instances?

It would be nicer if amsynth was multi-timbral, and could do this without 
running multiple instances, wouldn't it.

Changeable audition note
------------------------

Good feature. Wouldn't a GtkSpinButton be more suitable for this, though? It 
would prevent invalid values being entered by mistake.

Original comment by nickdowell on 18 Aug 2013 at 6:06

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

You've got the means of using the scala files exactly right - one per instance, 
for as many instances as need be.  The way that I'm using it right now is with 
three instances - one instance is mapped to the lower three octaves of my 
keyboard, while the other two are mapped to the upper two octaves.  I've 
attached one of the extended scala files that I'm using as an example - look 
for the <range> tag.

You're also definitely right about using a GtKSpinButton, I guess I'm revealing 
my inexperience with GTK here.  I'll make that change shortly.  (in the 
original patch that I posted the result of entering invalid input is the 
auditioning of whatever integer between 0 and 128 the input happens to get 
converted into - usually 0.  If it doesn't end up in that range it gets forced 
to 60)  

Original comment by joshua.t...@gmail.com on 18 Aug 2013 at 11:51

Attachments:

• One-LowerHalf.kbm

[GoogleCodeExporter]

Would it be more or less convenient to use a command-line option to set the 
MIDI note range instead of a custom scala file? (and how important is the 
ability to specify multiple ranges for one instance?)

Original comment by nickdowell on 19 Aug 2013 at 5:22

[GoogleCodeExporter]

For people comfortable with writing shell scripts the command line would 
probably be more convenient, and it would solve the issue of range preference 
storage at the same time: users could write a shell script calling as many 
instances of amsynth as needed, each with its own range.  I guess there 
probably wouldn't be too many people comfortable with creating their own .kbm 
files who couldn't also write a shell script.

About the ability to specify multiple ranges: I can't see it getting used 
particularly regularly, but I also wouldn't rule it out.  A lot of voices are 
only tastefully usable within a confined range, so I wouldn't consider a 
scenario in which the lower and higher registers of the keyboard are used for 
one voice while the middle is used for another to be impossible.  That being 
said, if it made the implementation troublesome I also wouldn't worry too much 
about removing it.

Original comment by joshua.t...@gmail.com on 20 Aug 2013 at 12:36

[GoogleCodeExporter]

        While I was implementing the changeable audition note feature as a spin button, I noticed a slight issue with the PresetControllerView part of the UI: there's no limitation on bank or preset name lengths.  Because combo boxes expand to accomodate the length of their longest element, using banks that have long names or contain presets with long names can cause the PresetControllerView bar to become wider than the main UI window allows.  To test this, open up a user editable bank and lengthen the name of one of the presets within.
        The ConstrainComboWidth.diff patch is intended to address this.  It does this by limiting the number of characters displayed in either of the combo boxes to 25 characters.  If they're longer than that, it adds an ellipsis and truncates the rest of the name.  To conserve space in the bank combo box, I also changed the "[user]"/"[factory]" tagging to ""/"[read]" (which I think is a little more clear anyway, because user-defined banks put in the shared directory would also be marked as [factory] using the old criteria).

         The ChangeableAuditionNote.diff patch is intended to be applied on top of the other patch, and implements the feature using a GTK spin button instead of a text entry, as suggested.

Original comment by joshua.t...@gmail.com on 29 Aug 2013 at 4:33

Attachments:

• ConstrainComboWidth.diff
• ChangeableAuditionNote.diff

[GoogleCodeExporter]

Thanks for the patches, I'm away on holiday for a while so won't be able to 
integrate them until I get back...

Original comment by nickdowell on 1 Sep 2013 at 11:32

[GoogleCodeExporter]

Sorry for the delay, I have incorporated your changes into the main repository 
(actually, did this a while ago but forgot to push!)

I did make a few changes, so let me know if it works for you =]

Original comment by nickdowell on 22 Nov 2013 at 8:11

[GoogleCodeExporter]

Looks great to me!  I hope other people have as much fun with it as I do.

Original comment by joshua.t...@gmail.com on 5 Dec 2013 at 1:10

[GoogleCodeExporter]

Original comment by nickdowell on 21 Apr 2014 at 12:25

• Changed state: Fixed