Questions regarding nrpn format | Mountain Utilities

By tedsorvino , 24 December, 2023

Forums

Hi all. Merry christmas.I have this fomat of nrpn messages for a synth (marion systems prosynth - oberheim matrix family)

70 B6 63 0C B6 62 00 B6 06 00 B6 26 DT (DT=val)

Why that 70?

Can i use standard output nrpn or should i treat it as custom output (sysex)?

what the correct value would be to make the encoder move from min to max (-99 - +99)?

I don’t know if replacing the DT with valand setting val1 to zero and val.2 to 127 would be good enough.

Thanks in advance

Just to answer part of my

Just to answer part of my questions,

yes the synth works with standard nrpn.

i just place the decimal value after converting the 2 hex numbers on the midi calculator and then i just add min and max values. Like 0 - 29 or 0-99.

I don’t know if my values are optimal since after a certain amount or a quick movement of the encoder the synth chokes (quite well known sysex issue that should have been resolved with nrpn use) .

i may have to experiment with speed settings on the general tab.

And i still can’t figure out what that 70 is all about in the message template.

best wishes to everyone

i still can’t figure out what

i still can’t figure out what that 70 is all about in the message template.

I don't know either.

In principle any MIDI message has to start with a status byte (80-FF).
However, via the "running status" protocol a status byte can be left out if it is identical to the status byte of the previous message. So for instance in your NRPN template the last three "B6" can be left out: B6 63 0C 62 00 06 00 26 DT.
But there is no status byte in front of the "70" at the start of the template, so how the receiving device interprets the "70" is determined by whichever status byte it received last before the "70".

Could the "70" simply be a typo?

Thanks for the reply Mark.

doubt that it’s a typo (since it comes from the source -oberheim prople- and it’s repeated quite some times in the notes i’m passed) but i don’tthink that it’s crucial in anyway (since standard output nrpn works in exactly the same way.

Could you please answer to me the value settings question?

Couldi do something like 0 -200 value settings and maybe slowing down the midi data transmission speed ?

cheers

After serious testing I have

After serious testing I have to admit that the standard nrpn doesn't work (it changes the same parameter to any controller but not the one specified). So i followed your format for custom output and it works well.

Still looking for your input if you have any suggestion on the value front.

Thank you

Still looking for your input

Still looking for your input if you have any suggestion on the value front.

I'm not sure what your question is exactly at this point, but here are some thoughts:

The setup you suggested in your original post is a good starting point: in the custom output definition of the encoder you replace "DT" with "val", and since the range of a single MIDI data byte is 0-127 ($00-$7F), for a start you could set Value 1 to 0 and Value 2 to 127; if desired, you can raise Value 1 and/or lower Value 2.

Concerning Resolutions on the General tab: a BCR encoder has 96 "hardware positions", so as long as the resolution is 96 or lower (but of course higher than 0), the encoder never skips any value (as the BCR display shows if "Show value" is on).
E.g. for a single-byte value parameter (e.g. simply "val") spanning the full MIDI byte range from 0 to 127 (defined by Value 1=0 and Value 2=127), the standard resolution of 96 usually gives satisfactory results: by rotating the encoder you traverse the full range in about 1 1/3 cycle. But of course it is up to the receiving synth how it reacts: if it only responds to a subrange, you can limit Value 1 and Value 2 to this subrange and perhaps lower the resolution.
See section 17.3 of "BC MIDI Implementation.pdf" for further discussion of the Resolution parameters.

Hope this helps,
Mark.

Thanks a lot Mark. It does

Thanks a lot Mark. It does help indeed.

I know that val works quite

I know that val works quite well for most things on my nrpn messages, but just for experimentations sake and to see if there is any improvemnt on parameter behavior

I would like to ask you Mark (or any other Bc control power user) is there a simple or quite understandable way to enter values from negative to positive (-99 - +99 in a way similar to pitchbend values pitchbend values) on bcr encoders?

For any future reference,

For any future reference, after a bit of research and help from the midi.org forum (there are more details there) i found out that by adding the string :

$EF val7.13 $10 $EF cks-2 1 $sum filler $B0 $63 $num hi $B0 $62 $num lo $B0 $06 cks-3 4 $B0 $26 val0.6

and finding the correct filler with the formula :

filler = 37 xor num_hi xor num_lo

we can have something like what i’m asking

Negative parameter values

If you still need further info:
Negative parameter values have also been discussed in quite a few topics in the Mountain Utilities B-Control forum:
If you simply search for "negative" in the Search facility of the website (accessible from the top right "bar"), you get a list of posts containing "negative", and most of these hits are indeed about negative parameter values concerning the BCF/R2000.

Thanks Mark for the reply and

Thanks Mark for the reply and the info.

I will surely check them out. I guess i will learn some interesting things.

Actually i tried to make a variable "switch" out of a button with multiple values using only 3-4 "if p" arguments in 3 different lines but the button was only "reading" the first one.

After reading the implementation manual i realized that it's something nirmal for BCR.

Is there any workaround for such a thing?

i tried to make a variable

i tried to make a variable "switch" out of a button with multiple values using only 3-4 "if p" arguments in 3 different lines but the button was only "reading" the first one.

"Only reading the first one"? Really?
I last studied ifp and ifn about 13 years ago, so I can't remember all the details of what I found, but in "BC MIDI Implementation.pdf" section 14.6.4 I wrote

It is possible to have any number of Direction identifiers in the same custom output statement. Normally you have only one ifp and one ifn, but multiple occurrences are accepted too. E.g. .tx ifp $C0 $01 ifn $C0 $02 ifp $C0 $03 ifn $C0 $04 leads to C0 01 C0 03 for positive changes and to C0 02 C0 04 for negative changes.

So could there be a difference in behavior between ifp and ifn in a single ".tx" line and in multiple ".tx" lines?
But I don't quite understand what you are trying to achieve here, so I can't definitively say whether it's possible in some way.

Thanks for the reply Mark .

Thanks for the reply Mark . Happy New Year.

I read what it's written in midi implementation.

No "ifn" involved in my case

Just a custom output string with a series of "ifps" in order to jump from value 01 to value 07 to value 09 to value 09 like in your example:

ifp $C0 $01 ifp $C0 $07 ifp $C0 $09 ifp $C0 $0C

but actually tried it with sysex in order to jump from 01 00 to 03 00 to 07 00 to 0c 00

$F0 $43 $10 $4B $60 $00 $30 $01 $00 $F7 ifp $60 $00 $30 $03 $00 $F7 ifp $60 $00 $30 $07 $00 $F7 ifp $60 $00 $30 $0c $00 $F7

etc etc

either in one string all together or seperated in different strings

Just a custom output string

Happy New Year to you too!

Just a custom output string with a series of "ifps" in order to jump from value 01 to value 07 to value 09 to value 09 like in your example:

ifp $C0 $01 ifp $C0 $07 ifp $C0 $09 ifp $C0 $0C

You can't use multiple ifp clauses to make a BCR element jump from one value to the next.
Upon a positive change, the BCR always outputs the bytes in all the ifp clauses.
So upon a positive change the output of your example is always "C0 01 C0 07 C0 09 C0 0C".

but actually tried it with sysex in order to jump from 01 00 to 03 00 to 07 00 to 0c 00

$F0 $43 $10 $4B $60 $00 $30 $01 $00 $F7 ifp $60 $00 $30 $03 $00 $F7 ifp $60 $00 $30 $07 $00 $F7 ifp $60 $00 $30 $0c $00 $F7

This always produces the following output upon a positive change:
F0 43 10 4B 60 00 30 01 00 F7
60 00 30 03 00 F7
60 00 30 07 00 F7
60 00 30 0C 00 F7
Only the first line constitutes a valid SysEx message.
The other three lines contain invalid data, which a receiving MIDI device should ignore.
To correct this, you could include the start of the SysEx message in all the ifp clauses. But as explained above, this would still not make the BCR element jump from one value to the next.

You ‘re absolutely right Mark

You ‘re absolutely right Mark.

Tried it with complete sysex strings but i had no luck. I used the diminished strings because think i read about leaving out the start of the sysex either on the forum or the midi implementtion manual. Can’t remember exactly. Doesn’t really matter. With “ifp” or without it just doesn’t work.

If you could think of a workaround (involving just one button) please let me know.

If you could think of a

If you could think of a workaround (involving just one button) please let me know.

Well, there is "incval" (for custom output) and "increment" (for standard output), as described in "BC MIDI Implementation.pdf" sections 15.9 and 15.10.
But neither allows you to define "irregular" jumps, if that's what you're after.

Sure. Increment is excellent

Sure. Increment is excellent and for 1-4 values just on button works just fine. For more, more buttons must be involved.

Irregular jumps would be fantastic but we have to live with the device’s limitations.

Thanks anyways for the input Mark.