New to C#

I havent been using C# that long. So naturally I am making all the noob mistakes that, well, comes from being naive. However, sometimes I "see the light", and suddenly things become a lot more easy.

Take for example my NRPN v objects.

I asked my chums at work ... how can I ensure that "this" button only has "that" NRPN.

They tell me I have to go all WPF ... but infact there is a poor mans way to do this.

Using a Dictionary, I can add a lookup of NPRN based on Object.
Specifically,

public Dictionary<Object, NRPNControllerId> AssociateFormToNRPN()
{
Dictionary<Object, NRPNControllerId> d = new Dictionary<Object, NRPNControllerId>();

d.Add(BankNUD, QuickPatch); // QuickPatch is a common NPRN ... should really be a CC
d.Add(PatchNUD, QuickPatch);
#region VOICE_OBJ_TO_NRPN
d.Add(UnisonType, unison);
d.Add(UnisonDetuneAmount, unisonDetune);
d.Add(PortamentoListBox, portamento);
d.Add(PortaType, portamentoType);
...

Now, for "generic" actions I can use a couple of polymorphic methods to "do the right thing".

Specifically,

// By using a dictionary to map between the Object and its associated NRPN,
// we can use mostly a SINGLE method to handle the click event.
// Specifically, anything that involves a label manipulation (EFX, Freq, Porta)
// will need a separate "virtual" method, as too will the track points
// since I dont know how to make -ve range trackbar (so instead I have
// to invert values for display purposes).
// It seems one needs to handle EventArgs separately to ScrollEvent args
// but via the wonders of polymorphism we should have one "interface",
// different signatures.

private void objectToNRPN_click(object sender, EventArgs e)
{
NRPNControllerId v;
if (objToNRPN.TryGetValue(sender, out v) == true)
{
FormHelper.handleThat(sender, e, ref v);
}
else { Console.WriteLine("Cannot find sender " + sender.ToString() + " in objToNRPN dictionary"); }
}
// this one is for scrollbars
private void objectToNRPN_click(object sender, ScrollEventArgs e)
{
NRPNControllerId v;
if (objToNRPN.TryGetValue(sender, out v) == true)
{
FormHelper.handleThat(sender, e, ref v);
}
else { Console.WriteLine("Cannot find sender " + sender.ToString() + " in objToNRPN dictionary"); }
}

And the program complexity/size drops by a massive factor :-)

I am sure there are better, more OO ways to achieve this. But it is a "RI" relational-integrity database method, and I kinda like DBs.

TO DO

I can read in Sysex from patches.
I decoded and applied values to buttons, but get occasional overflow.
Good news is adding a break to validated method is trivial.
Bad news is how many training sets to I need before I find all the issues.
Medium news is ... once I gone thru the PDF and added in the ranges, I have a few places to double check and this should reduce the issues down.

Finally, I added post
http://tech.groups.yahoo.com/group/alesis-ion/message/22996

If I read and decode properly the Sysex for filters say.
I find value 6, and set the NRPN to 6.
This however is wrong.

So whilst I know for filters NPRN is [0, 20]. It seems the Sysex is P(x) = {i ; (i in [0, 20])}
that is it is a permutation on the NRPN number.
It is not clear yet if this is because the patch is 0x22 (Ion/Micron).
Or whether in general, NPRN and Sysex are in the domain of [0, 20] but transfer function is required to take Sysex -> NPRN and vice versa.
It _could_ also be that as OS Updates happened, the Alesis engineers decided to add more capability on, by increasing the domain, but preserve existing values, and change the mapping.

That is if I take the Miniak manual, and throw NRPN values [0, 20] I indeed generate the values in the same menu order as the Miniak.
But one assumes the Sysex stores in some alternative permutation!

Things like that are simply tiresome, but hackable.

Will be releasing newer Editor soon once I have ironed out Patch sysex loading bugs.

Regards

Steve H