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

Also check out the Facebook Group.

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

MIDI Designer
Design your perfect MIDI controller for iPad, iPhone and iPod touch.
Weird problem with NPRNs in StreamByter - MIDI Designer Q&A

Weird problem with NPRNs in StreamByter

0 votes
asked Jul 12 in Defect (Confirmed, Not Fixed Yet) by the-elf (600 points)
edited Jul 12 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.
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.
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.
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.
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.
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).
        SND L0 63 00 L0 62 23 L0 06 M2B # Osc3 Wave NPRN
Ah, I see. OK, will try this. I have to break off for the moment, but get back with my results later.
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.

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

answered Jul 14 by jkhiser (11,050 points)
edited Jul 14 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!
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).
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.
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.
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.
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.
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
answered Jul 14 by jkhiser (11,050 points)
edited Jul 14 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.
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.
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
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: 50
SB Input rule test.mididesigner
Downloads: 50
answered Jul 18 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!
I just tested it with the latest beta and I believe it works now
Yup. me too. Seems we have  a fix.
...