|
|
Post by crony on Jul 26, 2018 23:19:54 GMT
Hello !
I'd like to make sure a sysex MMC start/stop controls are always the same, and also block all other events from other midi channels.
For an unknown reason sometimes :
F07F7F0602F7
and
F07F7F0601F7
are "changed" to
0602F7F07F7F
and
0601F7F07F7F
So I'd like a rule that would this:
if 0602F7F07F7F is received, change it to F07F7F0602F7
and
if 0601F7F07F7F is received, change it to F07F7F0601F7
I also would like to block any other midi messages from all channels.
So here, I guess it would be :
XX = XX +B
But I think it blocks really everything, MMC included...
Is it possible to do this ? Could you help me out doing so ?
Thanks a lot
|
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 6:40:07 GMT
Hi crony , A MIDI message beginning with 06 would not be valid. What is 'changing' these messages? This might work: # repair crony's 'bad' MMC messages
IF M0 == 06
IF M2 == F7 F0 7F 7F
SND F0 7F 7F 06 M1 F7
END
END
# pass valid MMC messages
IF M0 == F0 7F 7F 06
IF ML == 6
SND M0 M1 M2 M3 M4 M5
END
END
# block everything else
XX = XX +BThis will 'fix' those bad messages and pass them; all other events will be blocked. EDIT : OK, so the 'bad' messages still get through as XX = XX +B ignores them as they are not valid. This means that the fixed message still gets sent but after the bad message. Regards, Nic. |
|
|
|
Post by crony on Jul 27, 2018 19:16:19 GMT
Hello Nic, Wow, fast  Ok, I tried to install this rule but got an error: IF M0 == 06 #ERR IF M2 == F7 F0 7F 7F #ERR SND F0 7F 7F 06 M1 F7 #ERR END END XX = XX +B Does this rule will work for start and stop messages ? These messages are coming from midi interfaces ! It's very weird, the proper message is sent by my controller, then passing by the lidi interface, then it's "reversed". But this happens randomly ! I've tested 3 midi interfaces, doing the same thing. The weirdest part is that BM3 keep working and start/stop, but AUM does not... Thanks a lot ! |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 19:24:10 GMT
Hi crony , Those rules work for me. I just copied and pasted from Chrome iOS into StreamByter and no errors. Maybe there are funny invisible characters being pasted. Try typing in manually. Yes, it should work for both stop and start MMC commands. Regards, Nic. |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 19:36:35 GMT
Also realised you want to pass the valid incoming MMC messages too, so I have updated my rules above to do this also.
Regards, Nic.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 19:59:06 GMT
How can you tell (what tool are you using) it is being reversed in the MIDI interface? This sounds like a software bug to me!
|
|
|
|
Post by crony on Jul 27, 2018 20:12:41 GMT
Hey ! Almost there ! Now the message sends only : F07F7F I need to have: F07F7F060 2F7 or F07F7F060 1F7 Going out !And actually, I have this bug, and it's coming from my midi interfaces I guess...But 3 different midi interfaces are doing the same thing... I used MidiFlow to track what's going in/out, did loop in/out in midi also to test each midi interface. The ArturaiBeatStep is sending in the "correct" order the full sysex, then, it's being reversed passing from a midi interface to an other. Using bluetooth connection without having a problem...But I'm going to retest to make sure... That's why I think it's hardware related... |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 20:20:33 GMT
If you are only seeing part of the message, something is stripping it. I tested my rules in midifire and I get all 6 bytes correctly.
I'm not sure that Apple's AU handles sysex properly. This might actually be the issue?
I also do not believe 3 hardware midi interfaces all break standard MMC commands!
Regards, Nic.
|
|
|
|
Post by crony on Jul 27, 2018 20:25:33 GMT
Ok with bluetooth it received : F7F07F7F0602 and F7F07F7F0601 !!!! BeatMaker 3 on the iPad connected with Bluetooth answers to it, but not AUM... So I guess I'd like an other 2 rules for bluetooth, with the full message, then I'll have everything consolidated... Huge thanks |
|
|
|
Post by crony on Jul 27, 2018 20:32:21 GMT
More infos :
To be very accurate, the message is indeed cut in two parts with my midi interfaces.
They appear like that :
0602F7
F07F7F
0601F7
F07F7F
With Bluetooth, messages appearing like that :
F7
F07F7F0602
and
F7
F07F7F0602
So here they are the same messages, but, indeed, seems "hashed" in two different strings, but are the proper messages...At least for BM3 as he catch these variations without any problems...
I know it sounds crazy, but this is what's happening here...And I did lots of tests to reach here...
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 27, 2018 20:49:00 GMT
I need to check this but I think AUv3 has 3 byte message limit. Have you tried checking the messages outside of aum, say with midi wrench or midifire?
|
|
|
|
Post by crony on Jul 27, 2018 21:34:26 GMT
I think the 3 bytes limitation is something to dig...Here are more infos : I tried first to redirect the clean/check MMC with AUM with this routing : ArturiaBeatStep > StreamByte out > StreamByte In > Midi out But there where nothing getting out of the Midi out ( was looking on an other iPad the midi in of this midi out...but nothing) So if there's a 3 byte limitation, that would explain the "nothing out" at all... ? Then, I used MidiFlow to check live, and redirect. From iPad 1, no problem, the sysex is the same. But on the other one, it appears hashed like this: 0602F7 F07F7F 0601F7 F07F7F I apply the 2 simple remap rules within MF, then, it works ! The out gives that : F07F7F0602F7 F07F7F Note that there's a "lonely" F07F7F (I rebooted the iPad , the soundcard, it still there, don't know why...) But AUM receive the MMC, and start, no problem... I tried the option "filter out sysex" and then F07F7F disappear, but the MMC is still passing, and everything works... On bluetooth: BM3 keep working perfectly fine. Not AUM, because the signal is now: F7 F07F7F0602 and F7 F07F7F0602 The last F7 is coming first here, and then, on the outside of MF, it is cut, and it just becomes: F07F7F0602 or F07F7F0602 Then trying to add rules here have been too difficult, I've got 7F / F7 all around, I'm not far, but couldn't achieve the rules... Need to try with your script... Thanks |
|
|
|
Post by crony on Jul 29, 2018 8:09:11 GMT
Hi Nic,
Ok after digging a bit, I found out that AUM just does not accept MMC not "in order" so you can't fix it while is entered (because he's not passing at all...)
The only solution is to fix it before sending it into AUM...That's what I do with MidiFlow (or MidiFire) and then it works...
So it's a restriction of AUM...
The interesting thing to notice is that using midi interface, there is a variation sent of the MMC's...
There's also a different variation if you send it MMC using bluetooth.
Sorry for making you work for nothing, but thanks a lot for helping me figuring this out !
I'll email the dev of AUM now...
|
|
|
|
Post by crony on Jul 30, 2018 12:32:01 GMT
Ok bug confirmed with AUM's developer...Fixed in next version...
|
|
|
|
Post by crony on Jul 30, 2018 13:22:22 GMT
Ok, also confirmed by Jonathan (AUM's dev) Sysex are passed from StreamByter to AUv3 synths, BUT they're not passing to AUM's midi outputs !
It's just Sysex, midi notes and cc's are fine...
Seems a bug from StreamByter (?)
|
|
