NRPN, scripting, connection issues???

[digitaleyes76]

Let me try to explain the best I can.

I'm sending, or was sending, NRPN messages to my Novation UltraNova. Here's the script that was driving the synth's LFO1 Rate (again at one point in time):
decl target=1;
decl chan=1;
decl lsb=76;
decl msb=6;
decl lsb_val=98;
decl msb_val=Fader.x*127;
ctlout(target,lsb,lsb_val,chan);
ctlout(target,msb,msb_val,chan);

UltraNova's MIDI implementation list the LFO1 feed rate under Start of NRPN MSB=0/ LFO1 Rate = 0:76

First I used Jay Dspace's premium NRPN Test Set, which also worked flawlessly at one point as well.

Now I cannot get my script to work anymore, period. I lucked out and was able to get the NRPN test set going again, but I was actually calling the NSRPN output at 75

aphotob.jpg (83.57KiB)Viewed 2994 times

I have no idea why, but this is now driving the UltraNova's LFO1 Rate

Now take a look at this picture. The red represents the NRPN test set running the value at 75 as I stated above. And the green represents the code the UltraNova spits out when manually turning the dial on the synth.

midioxa.jpg (109.03KiB)Viewed 2994 times

(the pix is from midi ox, I only modified the colors in photoshop to illustrate the two differences)




To me it doesn't seem that the NRPN test set is sending out a LSB of 76 to begin with. (I'm not exactly sure how to read all of these messages from MIDI so please bear with me)

If I throw a bunch of Faders down with normal CC messages (with no scripting) such as volume 1/ pan 10/ modwheel 1. Everything performs naturally.

Please does anyone have any ideas what went wrong? As I stated, everything was functioning perfect at one point, especially with the above script I kinda wrote. At this point I'm clueless where the bug exist. Whether it's lemur, the ultra synth, or the midi mobilizer II from line 6 that I am using.

TIA
Mike

[analog604]

Hi Mike,

from a quick read of the midi implementation it seems that the UltraNova wants the parameter and value
sent every time ("All 4 controller messages (nrpnMSB:nrpnLSB:dataMSB:dataLSB) must be received in that order, otherwise response is not guaranteed.")
and that is where the test set doesn't work every time because it sends the parameter address once per parameter change and
then only sends values (the 06 01, 26 1B for example in your screenshot) or a NRPN increment or decrement (and the increment decrement doesn't seem to be implemented at all according to a quick browse of the UltraNova doc).

This works with devicess that remember the last parameter, but some won't. Sorry I didn't have a synth to test on that needed all values every time.

SO it seems that I need to make an adjustment, maybe a button to select between modes or simply send out the values every time.

I'll update the test set code and let you know when it is done. Sorry I don't have time to debug your code at the moment holiday weekend keeping me away from the Lemur.

-J

[analog604]

ok update posted that hopefully should play nicely with the Novation (but please let me know!):
http://liine.net/en/community/user-library/view/192/

includes two sample knobs that you can set to parameter addresses.

cheeeers~
J

[digitaleyes76]

Hey J,

Thanks for your work man, seriously. If I'm understanding you correctly (that is to say not much at all) the UltraNova is very particular in how it is to receive it's NRPN messages. To me it seems as if it's only sending out only 2 controller messages while the LFO1 Rate knob it turned:

B0 62 4C - NRPN LSB
B0 06 (xx) - Data Entry MSB where xx is the variable that changes from 1-127
_________________________________________________________________
OK, OK wait a minute (since every post I've made on here, I'm constantly trying new things out, as I'm writing these posts) I think I may have figured it out.
Here's my new script:

decl chan=1, lsb=76, msb=6, target=0, lsb_val=98, msb_val=Fader.x*127;
ctlout(target,lsb_val,lsb,chan);
ctlout(target,msb,msb_val,chan);

In which should truly match:
ctlout(target,lsb_val,lsb,chan);
----------0--------98---76---01---- or in hex ->
----------0--------62---4C---01

My first ctlout was not in the correct order. The bug must have been with me, and my saving techniques in Lemur, as well as my labels aren't probably what they should be as far as lsb and lsb_val. I'm guessing in the long run, as far as the script is concerned these could be labeled as anything such as DATA1 and DATA2 and so forth. As long as the ctlout is properly written to match: ctlout(target,DATA1,DATA2,chan) is this correct in thinking like that? (in which I'm calling labels, maybe their expressions, IDK)

Your new code which I reloaded into my lemur app is still driving the UltraNova's LFO1 rate with a 75 (which should be a NRPN lsb of 76)

Thanks again for you help,
Mike

[analog604]

Mike it sounds like you are making good progress!

Yeah about only 2 controller messages, according to the UltraNova doc this is the way it usually works for the first 128 NRPN addresses.. then it can get by with 3.

4 are required when values greater than 7 bits (128+) that requires the MSB and that is 'Tweak Data' and Clock BPM
a little excerpt from the MIDI implementation doc:
"NOTES ABOUT NRPNs
It is not necessary to send nrpnMSB=0 as this is a default.
On power-up or after receiving data entry msb (CC6) in any NRPN sequence, nrpnMSB is internally set to 0.
This allows the first 128 NRPNs to be delivered with 2 controller messages instead of 3. Further, when NRPN 0:xxx parameters are edited on the control panel, nrpnMSB is not transmitted.
Interacting software should therefore assume that nrpnMSB=0 unless specifically set prior to the nrpnLSB or CC6 data message."

about the test set sending a 76 instead of a 75.. I suspect that the scale for the value display+knob may be different than that of your synth.
So you can try going into the editor in the cBallz.maxadx and set that to a different value..

Please feel free to adapt it as needed.

If it makes it easier you can name your variables just about anything other than a reserved word (Lemur built in function and control structure names ). Unfortunately I do not have a great variety of NRPN synths to check this stuff out on.
That is where you come in, Mike.

cheers
~J

Hey J,

Thanks for your work man, seriously. If I'm understanding you correctly (that is to say not much at all) the UltraNova is very particular in how it is to receive it's NRPN messages. To me it seems as if it's only sending out only 2 controller messages while the LFO1 Rate knob it turned:

B0 62 4C - NRPN LSB
B0 06 (xx) - Data Entry MSB where xx is the variable that changes from 1-127
_________________________________________________________________
OK, OK wait a minute (since every post I've made on here, I'm constantly trying new things out, as I'm writing these posts) I think I may have figured it out.
Here's my new script:

decl chan=1, lsb=76, msb=6, target=0, lsb_val=98, msb_val=Fader.x*127;
ctlout(target,lsb_val,lsb,chan);
ctlout(target,msb,msb_val,chan);

In which should truly match:
ctlout(target,lsb_val,lsb,chan);
----------0--------98---76---01---- or in hex ->
----------0--------62---4C---01

My first ctlout was not in the correct order. The bug must have been with me, and my saving techniques in Lemur, as well as my labels aren't probably what they should be as far as lsb and lsb_val. I'm guessing in the long run, as far as the script is concerned these could be labeled as anything such as DATA1 and DATA2 and so forth. As long as the ctlout is properly written to match: ctlout(target,DATA1,DATA2,chan) is this correct in thinking like that? (in which I'm calling labels, maybe their expressions, IDK)

Your new code which I reloaded into my lemur app is still driving the UltraNova's LFO1 rate with a 75 (which should be a NRPN lsb of 76)

Thanks again for you help,
Mike