one CC for coarse and fine tune

[analog604]

to be sure, I checked, and Diva does indeed not output MIDI data. Therefore I have to use my old, trusted method to have feedback. And my efforts for those tuning knobs haven't been in vain.

Now this 14-bit thing is puzzling. When I send a NRPN encoder from the BCR, the Generic Remote Device (let's call this GRD) recognizes this input as NRPN. I just have to adjust the maximum value in the GRD. When I send from the Flexi14 template, the GRD recognizes this input as CC. The following image illustrates the difference:

There isn't bi-directional control in the Flexi controller yet.. if Cubase sends an update back to the controller it might be neat to add it in.
Thanks for your screen mark up it shows what I expected the generic MSB/LSB from 'Flexi14' as only CC.
That template makes no effort to send NRPN.. yet.. the start parameter index with MSB of the value followed by the parameter index + 32 and the LSB of the value is what it specializes in.

About the basic MSB/LSB non-NRPN method:
So say we have an index CC of 16 which is a generic MIDI controller number usually.
Flexi sends CC16 with the MSB of the value followed by (CC16+32) CC48 with the LSB.
The synth/daw/whatever receiving would see the CC16 shortly followed by a CC48 and if configured to do so (or in learn mode) would know to combine the two messages for a single parameter CC16 14-bit value .

On supported hardware/software only,
NRPN unlocks us from being restricted to 87 "double byte" parameters (I get 87 because 87+32=119 and CC numbers above that are controller/note reset and poly stuff and shouldn't be used for any parameter information).

With NRPN messages we specify a 14-bit target parameter number with two CC messages (CC98+CC99) = 16383 addressable parameters (and not all will be addressable, imagine a synth with that many controls?!).

After which send either another two byte CC message (CC6 and CC38) for the 14-bit value or if supported by the device, send a CC increment (CC96) or decrement (CC97) data message.

The parameter number (CC98+CC99) need only be sent when a we want to change to a different parameter.

None of this feeds back to the sending controller unless front panel knobs on a synth are set to send messages in the synth global setup pages. I have a few knobs on my DSI Mopho that can do this, and it seems possible from what I read in the MIDI spec of the Tetra and Prophet '08 but I don't own these.
Other than that I don't have any hardware (waldorf,jomox) that the manufacturer chose to implement the NRPN method for parameter targeting. They all use basic CCs for 0-127 control and system exclusive messages to get to the deep parameters high-resolution (and otherwise) which is kind of messy.

So the main use that I have of standard MSB/LSB controls are for softsynths and DAW controls in Logic and Ableton.

I'll make a few additions to update the knobs to be able to target NRPN parameters and maybe make it accept them too... I have the code to do all of this and only need to integrate it.
What you might try is my mopho dashboard template and see if Diva will learn any of the controls changed on it.. this is already bi-directional NRPN.

-J

[fader8]

So it appears that I actually need 4 messages, not two. I read somewhere (I think in this forum) that the first two are CC 98 and 99 to "establish the active parameter" (NRPN), and that regular CC's don't need them. However, it looks like I need NRPN's, not regular 14-bit CC's.

hey Phil,
We had this discussion here:
http://liine.net/forum/viewtopic.php?f=24&t=1119

Remember that with nrpn's the cc98/99 MSB/LSB pair only selects the parameters you want to adjust. If the synth dev didn't have more than 127 extra parameters, they may only need the MSB part of the message. If they use the 14 bit selection method, it means that they needed a lot more, (up to 16,383). That's a lot of parameters and not even a Kurzweil VAST synth needed that many.

The parameter selection is a hard switch. You only need to send that once.

So once you've selected the parameter either with just a 7 bit 0-127 cc 98 message, or a 14 bit 0-16,383 cc98/99 pair, you now must send the inc/dec cc6 to actually adjust the parameter value. Cc6 can be either 7 or 14 bit depending on the resolution needs of that parameter.

The bottom line is that nrpn's, just like regular cc's, can be either 7 or 14 bit. Just depends on what's needed.

In your case here, send an email to Urs Heckman and ask him what's required to control the coarse and fine tuning parameters. Start from there.

[Phil999]

thank you gentlemen. I apologise for still being confused.

But let me say that it is not my intention to control Diva directly; Diva isn't able to send data. It can only receive. This is the reason I have to use the Generic Remote Device. With the GRD I can send data back from Diva. That's the trick I've been using since many years.

I just need to be able to send an NRPN message that the GRD understands (four CC messages, that's what I've learned today). The receive part in Lemur is something I'm dealing with at a later time. I know from experience (BCR) that it does send feedback, be it 7- or 14-bit.

I managed to send 14-bit data to the GRD (detected as regular 7-bit). Resulting in crazy spinning knobs in Diva (fine tune knob spinning extremely fast, coarse tune knob spinning fast). What I need to find out are the first two CC messages that tells the GRD that it is an NRPN message. Like the BCR does. I tried many variations (sending four CC messages). Adding to the confusion, I might have had the correct setting, but with the wrong timing.

If I worked with Live or Logic, or had one of those hardware synths, it would be probably easier for me to advance with NRPN. Now the only result is that my head is fuming after reading all threads dealing with the topic. I'm sure the next day/week will shed more light. Now I'm in the state of an old saying we have: I can't see the forest because there are too many trees.

Later, when I have recovered from my exhaustion, I'll analyse the hex values from the BCR and bring them into Lemur. I guess that will solve the problem.

Thank you very much, you are a great help (also in those numerous other threads dealing with NRPN).

[analog604]

Fader8: good concise info!
Phil: I updated the template to selectively send NRPN style 14-bit messages... doesn't receive yet that's possibly next..

cheers~
-J

[Phil999]

at last! Today I was able to make your Flexi14-v12rel template work with Diva. The tricky thing for my environment was that I have to edit the GRD xml before I use MIDI learn, not after. Took me two days to find that out.

You must be a professional programmer. Looking at the template, I couldn't quite locate where the actual messages are being sent. It seems to me it is the sendhirez script, but it is not activated. You activate that script with another script in the swTeach Button object, is that right? And this sendhirez script, it includes mio.ntxwrap() and mio.txcc(). But I can't find anything with that name.

With the NRPN-testset-v1.2 it works also, and bi-directionally. Very good. But I'm also quite lost in the attempt to understand how messages are sent and received. Receive seems to take place in the invisible mio container, with dozens of expressions and scripts.

What I'd like to have is a simple template with one knob or fader. There is such an example here: http://liine.net/forum/viewtopic.php?f= ... t=10#p3826, but it outputs

CC: Bank MSB
CC: Bank LSB

while it should output (like in the Flexi14-v12rel template)

CC: NRPN MSB
CC: NRPN LSB
CC: Data Entry MSB
CC: Data Entry LSB

I tried to modify the script in the NRPN_Fader_2.0 template, but without success so far.

[analog604]

The sendhirez is the wrapper script that
sends a knob/fader via either the mio.ntxwrap(TARGET,CHANNEL,CC,VAL)
if NRPN is enabled or
mio.txcc(TARGET,CHANNEL,CC,VAL); //CC 32Param offset
if MSB/LSB 32-parameter offset (default) is called

the whole mio (MIDI I/O) container library is my pre-existing code used in projects to save template developement time.. basically all controller messages are sent or received through scripts in that object.

Basically the method that I try to use are wrapper functions common to all knobs/faders/other controls..
that way.. (how i see it).. if the MIDI transmit code needs to be altered I only have to do it in one place.

Also since the template is multi-page, I can just copy knob sets and pages and it will all work without any additional modification. When I want to add/remove features.. I edit knob module one.. delete the others then copy/paste it six times, repeat for all pages... done!

However..! The downside is that all this wrapping isn't the most efficient way to go about, it just makes the code easier to maintain and easily used in new projects. BUT..I've found that Lemur can take a great big heap of script code and run it amazingly well! : )

Here's the order of functions that are called when a knob or fader is moved in 1.2 in for example Page1 interface:
cPg1.cSet1.knob -> cPg1.cSet1.chg() -> cPg1.updAll(VALUE,CONTROLLER_TYPE) -> cPg1.sendhirez(PARAMETER_NUMBER_FROM_SLIDER,VALUE_SCALED_TO_EXTERNAL_MIDI,NRPN_MSB_SWITCH_STATE) -> cMio.ntxwrap(LEMUR_TARGET,VALUE,NRPN_MSB_SWITCH_STATE) -> ntx(PARAMETER,VALUE) (this sends MIDI OUT).
So as I said most of the complexity had been already built.. I just wanted to make a 14-bit controllers template quickly so I went through the abstraction using mio. methods.

It all comes down to :
1) having a control to select the target parameter
2) having another fader/knob to select value and tying this script to it and executing on expression x when that control is moved:

Code: Select all

decl chan=0 | 0xb0;//make channel 0 to 15 0xb0 is the CC MIDI message type dont change that
decl targetParam=floor(VALUE_FROM_SLIDER_OR_FADER_OR_WHATEVER*16383);//set to 14-bit resolution
x=floor(x*16383);//set 14-bit resolution for the knob's output value

midiout(0, {chan, 0x63, (targetParam >> 7) & 0x7f});//ADX MSB
midiout(0, {chan, 0x62,  targetParam & 0x7f});      //ADX LSB

midiout(0, {chan, 0x06,  (x >> 7) & 0x7f});	//VAL MSB
midiout(0, {chan, 0x26, x & 0x7f});		//VAL LSB

I'll work up a one knob one fader without all complexity..
[edit]: sorry forgot to put decl and scaling in the example code

[analog604]

Here we go.. one slider to select NRPN parameter target number
and a knob that midi sends what you dial in.

-J

[Phil999]

thank you again Jay, this is extremely helpful. Not only the Knob object which is working, but also the explanations. It's good for a beginner to have such examples and explanations. The way you code is very interesting, to say the least. And I like this modular approach.

I read in the LModIt page you are building a modular synthesiser. I really don't want to waste your time any longer, so the following questions are directed to the entire forum: to receive NRPN data one has to use scripts. And MIDI_ARGS. And ++ (increment) and -- (decrement). What else is needed? Is >> (right shift) and << (left shift) needed as well? I've never worked with any of these. I'll go through the forum posts tomorrow, but if someone has some quick tips ...

Jay, too bad you live so far away. I have a good hand with soldering, I'd love to help you to build a module or two. But I hope with my Diva template I can give something back to the community when it's finished.

[analog604]

Phil, you're welcome!

I made a MIDI listener for one knob and slider, see attached, but I haven't had the chance to test it with a synth.
It's based upon my other code to do this.. so hopefully it will work and provide a useful example for you.

The '>>' and '<<' are bitwise operators and permit conversion to/from 14-bit MIDI which uses the Most Significant Byte and Least Signification Byte coding.
We could use addition and subtraction, division and multiplication for this and there have been many fine examples of folks here on the forum doing that, but the bitwise operations are typically very efficient for a computer to use (especially the old computers/micro-controllers with limiting processing ability, such as MIDI capable synths from the 1980s)
not that using scripting is efficient! but we work with what we have.
The '|' binary OR operation and '&' binary AND operation allow us to combine bytes.

Checkout the wikipedia article for "bitwise operation" and logical shift.

cheers Phil about the soldering ! : )

thank you again Jay, this is extremely helpful. Not only the Knob object which is working, but also the explanations. It's good for a beginner to have such examples and explanations. The way you code is very interesting, to say the least. And I like this modular approach.

I read in the LModIt page you are building a modular synthesiser. I really don't want to waste your time any longer, so the following questions are directed to the entire forum: to receive NRPN data one has to use scripts. And MIDI_ARGS. And ++ (increment) and -- (decrement). What else is needed? Is >> (right shift) and << (left shift) needed as well? I've never worked with any of these. I'll go through the forum posts tomorrow, but if someone has some quick tips ...

Jay, too bad you live so far away. I have a good hand with soldering, I'd love to help you to build a module or two. But I hope with my Diva template I can give something back to the community when it's finished.

[Phil999]

this is very kind of you. I've only been able to make a quick test, and what I see is that the knob goes to zero when I move coarse or fine tune in the plugin. MonitorKnobVal reacts to both knob movements, but it shows seemingly erratic values below 127. Unfortunately I don't have more time now, I'll have a closer look at it tonight.