MIDI DESIGNER
The only MIDI controller for iPad, iPhone, and Mac


Talk to other MIDI Designer users about MIDI Designer, iOS MIDI and related topics. Or share layouts, pages, and ideas.

Check out our Facebook Group.

Of course, if you want to send us an email, feel free.

☞ Open problem reports

☞ Summary of user requests

Categories

Weird problem with NPRNs in StreamByter - MIDI Designer Q&A

Weird problem with NPRNs in StreamByter

0 votes

I have a layout that controls a synth using a combination of simple CC#s and NPRNs. Outgoing everything works perfectly.

I'm parsing an incoming Sys-Ex patch dump from the synth (176 bytes, so not too onerous). Up to this point I have only been picking out the parameters that require a simple CC# conversion, and everything was working fine, but now I'm trying to include the parameters that require an NPRN.

In the log I'm seeing all of the simple CC# conversions arriving, but most of the NPRNs are not arriving at all. When I comment out certain of the NPRN conversions others begin to arrive, and when I un-comment them they stop arriving again. It's consistent, but I can't see a pattern to what is going on in order to fix it.

Can anyone offer any advice?

Here's a small example of the type of code I'm creating, together with its associated log output. You will see that the log only shows the NPRN messages corresponding to oscillator 3 - nothing for oscillators 1 or 2:

IF M00 == F0 00
  IF M02 == 21 22
    IF M04 == 4D 02
      IF M06 == 03 07
 

        MAT L0 = B0 + 00 # Set MIDI Ch 1

# OSCILLATORS

        SND L0 63 00 # Osc1 Wave NPRN
        SND L0 62 1B
        SND L0 06 M23

        SND L0 27 M24 # Osc1 Shape cc39

        SND L0 28 M25 # Osc1 Tune cc40

        SND L0 29 M26 # Osc1 Fine Tune cc41

        SND L0 63 00 # Osc2 Wave NPRN
        SND L0 62 1F
        SND L0 06 M27

        SND L0 2A M28 # Osc2 Shape cc42

        SND L0 2B M29 # Osc2 Tune cc43

        SND L0 2C M2A # Osc2 Fine Tune cc44

        SND L0 63 00 # Osc3 Wave NPRN
        SND L0 62 23
        SND L0 06 M2B

        SND L0 2D M2C # Osc3 Shape cc45

        SND L0 2E M2D # Osc3 Tune cc46

        SND L0 2F M2E # Osc3 Fine Tune cc47
      END
    END
  END
END

==

Log:

Message In: Cmd=176|Ch=01|Data1=042|Data2=000 | Length=3: B0 2A 00

Message In: Cmd=176|Ch=01|Data1=041|Data2=062 | Length=3: B0 29 3E

Message In: Cmd=176|Ch=01|Data1=040|Data2=052 | Length=3: B0 28 34

Message In: Cmd=176|Ch=01|Data1=039|Data2=038 | Length=3: B0 27 26

Message In: Length=9: B0 63 00 B0 62 23 B0 06 12

Message In: Cmd=176|Ch=01|Data1=044|Data2=060 | Length=3: B0 2C 3C

Message In: Cmd=176|Ch=01|Data1=047|Data2=064 | Length=3: B0 2F 40

Message In: Cmd=176|Ch=01|Data1=043|Data2=052 | Length=3: B0 2B 34

Message In: Cmd=176|Ch=01|Data1=045|Data2=000 | Length=3: B0 2D 00

Message In: Cmd=176|Ch=01|Data1=046|Data2=052 | Length=3: B0 2E 34

Message In: Length=176: F0 00 21 22 4D 02 03 07 58 50 6E 64 72 50 61 64 0D 00 00 00 00 00 00 00 28 00 50 18 18 14 00 3E 02 00 00 07 26 34 3E 0F 00 34 3C 12 00 34 40 7F 78 00 00 00 00 00 01 1B 64 00 00 00 00 7F 50 15 4B 4B 50 2A 40 20 20 02 00 24 01 0D 00 2A 02 09 00 30 01 03 02 01 00 18 03 01 01 00 00 01 00 04 0C 01 32 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 21 00 00 00 00 00 01 00 00 54 30 00 2A 2A 00 00 40 07 00 00 00 00 00 00 00 00 05 00 01 03 00 00 00 00 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F7

in Defect (Fixed) by the-elf (1.4k points)
edited by the-elf
Something definitely is going on here.  I have duplicated your results.  When I change the NRPNs to regular CCs, they behave, but I then only get 10 of the 12 messages output.  Will look at it some more tomorrow.
by jkhiser (22.5k points)
Many thanks for helping out, my friend. To have it independently confirmed is such a relief. Each NPRN line is nothing more than another controller message, so I can only assume there's something in those values (maybe the higher controller numbers?) that is upsetting the code translator.
by the-elf (1.4k points)
Dumb question first: if memory serves, NRPN is either 9 or 12 bytes. Why not send them all on one SND line (and would it help)?

Thanks JK and the-elf, looking forward to finding out more about this problem.
by MIDI Designer Team (Dan)
re: combining NRPNs - tried that, also tried adding commands to cancel the NRPN selection, didn't help.
The MDP2 log does show the NRPN in as a single message - don't know if that combining is happening in SB or MDP2.
I am not 100% convinced the is NRPN based.  If I change them to regular CCs, some still do not get through.  Seems like it is choking after 10 CC SND commands.  Need to do some more testing.   I really want to look at Ibo Kai’s recent update and see how he did it.
The other “weird” thing is that the messages do not come out in the order they are in the code.  Linear code - you expect to see the first SND in code first in the output, but they seem random.
Got more ideas to check.
by jkhiser (22.5k points)
Yes, I also noted the complete random scatter of the messages, but put this down to the vagaries of OO.

I also looked with curiosity at my three CC messages being referred to as a single 9-byte message, but since I get one of the message trios working I though that might just be the logger getting itself in a twist.

It's all very strange.
by the-elf (1.4k points)
edited by the-elf
Hi Dan. How would I construct that? Surely I would need to send the Status byte  for each CC#/value, or it would corrupt the message? Can you show me an example based on the above of what you mean?

NPRN, as far as I know it, is a trio of separate (3 byte) CC messages, CC99, CC98 (this pair designate the NPRN identifier) and CC06 (containing the value).
by the-elf (1.4k points)
edited by the-elf
        SND L0 63 00 L0 62 23 L0 06 M2B # Osc3 Wave NPRN
by jkhiser (22.5k points)
Ah, I see. OK, will try this. I have to break off for the moment, but get back with my results later.
by the-elf (1.4k points)
Nope - it's made no difference.

It seems to be only ever the very last NPRN batch coded in the Input Rules that is being received (as a 9-byte message?) according to the log.
by the-elf (1.4k points)
edited by the-elf

3 Answers

0 votes

EDIT - Ignore this workaround - see answer on using stand alone SB.  Did not want to delete to keep the conversation.

Got a workaround.  RPNs / NRPNs are order dependent, so there must be some undocumented guardrails in SB to keep them from causing chaos.

Combine the MSB, LSB, into one composite message, and delay each subsequent output by 1 sec, as follows:

        SND L0 63 00 L0 62 1B L0 06 M23 # Osc1 Wave NPRN

        SND L0 63 00 L0 62 1F  L0 06 M27 +D1000 # Osc2 Wave NPRN

        SND L0 63 00 L0 62 23  L0 06 M2B +D2000 # Osc3 Wave NPRN

Generates this output:

Message In: Cmd=176|Ch=01|Data1=045|Data2=000 | Length=3: B0 2D 00
Message In: Cmd=176|Ch=01|Data1=044|Data2=060 | Length=3: B0 2C 3C
Message In: Cmd=176|Ch=01|Data1=043|Data2=052 | Length=3: B0 2B 34
Message In: Cmd=176|Ch=01|Data1=040|Data2=052 | Length=3: B0 28 34
Message In: Cmd=176|Ch=01|Data1=046|Data2=052 | Length=3: B0 2E 34
Message In: Length=9: B0 63 00 B0 62 1B B0 06 07
Message In: Cmd=176|Ch=01|Data1=041|Data2=062 | Length=3: B0 29 3E
Message In: Cmd=176|Ch=01|Data1=039|Data2=038 | Length=3: B0 27 26
Message In: Cmd=176|Ch=01|Data1=042|Data2=000 | Length=3: B0 2A 00
Message In: Cmd=176|Ch=01|Data1=047|Data2=064 | Length=3: B0 2F 40
Message In: Length=9: B0 63 00 B0 62 1F B0 06 0F
Message In: Length=9: B0 63 00 B0 62 23 B0 06 12

by jkhiser (22.5k points)
edited by jkhiser
I have 90 of these NPRN parameters, so that's going to create one huge overall delay for a 176-byte patch dump. That said I'll give it a try and see if it works, then experiment with reducing the delay to see if I can find a compromise.

So grateful for the help, guys!
by the-elf (1.4k points)
Edited: (deleted reference to SB forums, since this appears unique to MDP2)
-----
As for shorter delays, I had tried 10, 100, 500, and 750.  1000 was where I finally got all messages (although I stopped at four messages).
by jkhiser (22.5k points)
edited by jkhiser
EDIT - see answer 2 for easier solution.
-----
One more thought - I you are using the NRPNs in this case only to synchronize the layout settings with the synth sysex dump, there is a workaround.
For each NRPN control, make a super control with a synthetic sysex, such as 01 v; 02, v, etc.  Then use the synthetic sysex for parsing.  All these super controls are hidden in play mode, maybe gather on a hidden page at the end of the layout.  The NRPN subcontrols will still work for controlling the synth.  One downside of this as when each super control receives the decode, the sub control will send the same value back to the synth.  I use similar decode super controls in many of my layouts without an issue.
by jkhiser (22.5k points)
edited by jkhiser
I'm still a bit disoriented here (and not reading too carefully yet) but any workaround is welcome!

Then... I'm wondering how the behavior changes or doesn't if we use external Midi Fire instead of SB-inside-MD. Not sure if that question even makes sense.
by MIDI Designer Team (Dan)
Unfortunately I can't say it's a tenable workaround. I've found (as above) that any delay value of less than 1 second increment between NPRN trios produces unreliable results. This is making a 176-byte patch dump take nearly two minutes to complete its transfer. Even at 1 second I'm still getting missing data. Most users aren't going to wait this long.

I'll keep upping the delay and see if I can nail it down.

Just tried 2 seconds between each NPRN trio and still some are not being received, according to the log (and reflected by the controls not updating on screen).

As it stands I'm pretty much dead in the water with this one, at least with regard to letting it go out into the world.
by the-elf (1.4k points)
edited by the-elf
Just noticed your last suggestion regarding supercontrols, JK - sorry I missed it earlier. Thank you for this. How do I create a hidden page?

I'll give this a try. It seems a bit of a fudge, but I'll see if it will work. I've yet to complete my decoding of the entire sys-ex file, so I'll do that first.
by the-elf (1.4k points)
0 votes
So I tried the stand alone version of StreamByter with your code.  Gives the expected output, with messages in order, matching the input sequence.

The stand alone version is currently free on the App Store.

I still recommend combining the NRPN MSB, LSB, and DATA messages into a single line regardless - helps ensure they don't get out of order.

This would be your setup:

Synth output -> SB stand alone -> MDP2 input

MDP2 output -> synth input

And remember to save your rules in SB.

Image below shows output with the combined MSB/LSB/Data approach.
Images
Stand alone SB rules output
Stand alone SB rules output
by jkhiser (22.5k points)
edited by jkhiser
I'm trying to get this working to to let it loose in the community. I could get it working with SB standalone, but that's not going to meet with approval out in the wild.

Also I tried the Supercontrol method, and while it does seem to work, it's far too complex and time-consuming to set it up.

I'm going to draw a sad veil on this one and leave it as a one-way editor. At least then I can let it loose and it will be of use to the folks out there.

I'm very grateful for the advice and assistance. I wouldn't have been able to get this far without it - and I've learned a few tricks along the way, which makes me a better MDP creator!

So thank you once again and see you around another time.

Oh, all of this was for the Audiothingies MicroMonsta 2 synth, BTW. I'll be posting the Layout on Facebook after I've Beta tested it for a while.
by the-elf (1.4k points)
The standalone version produces perfect results... in MD?

My understanding is that we're having a problem processing multiple NRPNs coming out of SB inside MD. Are you saying this doesn't happen with the standalone version, or that the standalone version is fine and we can isolate to MD? If it's the second, we can fix.
by MIDI Designer Team (Dan)
Here's my layout in its entirety, in case it helps with your investigation:
https://www.dropbox.com/s/gqqpux79p7d3wb9/MicroMonsta%202.mididesigner?dl=0
by the-elf (1.4k points)
0 votes

Confirmed error - Inbound multiple NRPN/RPN allows only single to pass


The problem requires the following conditions to occur:

1. Inbound Streambyter rules with multiple RPN / NRPN / Data messages

2. Triggered by inbound message, not If Load.

The problem does not occur for:

1. Inbound IF LOAD rules

2. Any outbound rules

The sample layout attached has one sysex control and both inbound / outbound rules.  Piggyback two layouts, and you will see the correct output in the outbound log, only one of the three NRPN messages in the inbound log.
Downloads: 425
SB Input rule test.mididesigner
Downloads: 425
by MIDI Designer Team (jkhiser)
Awesome! By piggyback we mean "load the layout on MD on one instance of MD and one layout on another instance of MD." Ways to get two instances of MD include: 1) two devices 2) beta and production versions of MD.

Thanks!
by MIDI Designer Team (Dan)
I just tested it with the latest beta and I believe it works now
by MIDI Designer Team (Dan)
Yup. me too. Seems we have  a fix.
by the-elf (1.4k points)
Powered by Question2Answer
...