lid55
MidiFire Beta
Posts: 68
|
Post by lid55 on Jul 12, 2018 3:52:06 GMT
Hi Nic, I was wondering if you could help with this also... not sure if it's a bug or not, but +I messages currently, seem to work non-intuitively when being used with +B at the input For example, sending a standard CC message such as B0 01 7F using +I in moduleB will get blocked if using a StreamByter filter ruleset in moduleA such as B0 = XX +C XX = XX +B I would have thought that since the +I is a Ch1 CC, that it would get the pass here, but it doesn't seem to. I hope this makes sense, if not, pleasecheck out attached ruleset Scene-bugOrComplicationWithI.mfr (1.91 KB) |
|
nic
Soapbox Supremo 
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 12, 2018 9:50:10 GMT
Hi lid55 , I just tried a version of your code and it worked fine for me: IF M0 == B0 3F 7F
SND B1 01 01 +D2000 +I
END
B1 = XX +C
XX = XX +BMy controller is on channel 1 and I am issuing the injected CC on channel 2. In my event monitor I see only the injected event. In the scene you sent me, are you sure that the incoming CC is being matched correctly and actually issuing the injected event? Or, in your scene you have commented out: #B0 = XX +C
Are you sure that wasn't uncommented? Regards, Nic. |
|
lid55
MidiFire Beta
Posts: 68
|
Post by lid55 on Jul 12, 2018 16:16:11 GMT
Thanks Nic, well it might be more of a conceptual understanding thing... I just don't understand why the block (+B) module (that is in series before the +I module) is blocking the +I. I've attached a new scene for clarity. The scene by itself doesn't make that much sense functionally, because it's out of context... but... it illustrates the point. Again I'll state that I do have a practical workaround for this, but I was just trying to make sense of this behaviour, for future rulesets. Scene-bugOrComplicationWithI-vrsn2.mfr (2.33 KB) |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 13, 2018 9:46:44 GMT
Hi lid55 , Thanks for your second scene. I was able to use this to reproduce what is going on. Oh, it's very subtle... When you do this: B7 = XX +CYou are cloning the event and in the process of doing this, the event 'loses' its attachment to the external interface - it is now an internally generated event. So when it comes to injecting the event in the other Stream Byter with the SND +I, the event source falls back to the 'MidiFire' virtual port which of course is not on your canvas. You can either: 1. Drop the 'MidiFire' input onto the canvas with the knowledge that your injected event will be delivered from that. 2. Modify your rules that limit the messages going through so that you are no longer cloning and only blocking: This: B7 = XX +C
B0 = XX +C
XX = XX +Bbecomes: # only allow CCs on channels 1 and 8
8-AX = XX +B # block all notes-aftertouch
C-FX = XX +B # block all PCs-system
B1-6 = XX +B # block CCs on chans 2-7
B8-F = XX +B # block CCs on chans 9-16Regards, Nic. |
|
lid55
MidiFire Beta
Posts: 68
|
Post by lid55 on Jul 13, 2018 22:57:31 GMT
Thanks for all this Nic, I tested some of this out and it works excellent thus far. In the process of trying to figure this all out... I may have discovered a bug... not sure if this is the place to post it or if you'd rather I use some other means, but... better make sure it is a bug first anyway.... So if I trigger an IF statement with a MIDI foot controller, where the clock messages are controlling the Dynamic Clock: SND FA SND FC +D2000 +I SND B0 7F 7F +D1000 SND B1 7F 7F +D3000 then it seems to me that the B0 message will send, but the B1 message will not... that this due to the FC message +D time... if it is shorter than the other +D times, they won't be sent, if it is longer, then they will be sent. Note that in the Event Monitor, it LOOKS like the messages are sent correctly, but if testing with an external app or hardware, the messages never get there Scene-InjectAndDelayBugMaybe.mfr (4.1 KB) |
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Jul 20, 2018 13:50:25 GMT
Hi lid55 , So I loaded up your scene and changed the ruleset to use a CC from my controller, which I put in place of your U-44 input. I then replaced your U44 output with MidiFire virtual port and ran a separate monitor looking for events from the MidiFire virtual port. 1892836.291 From MidiFire Control 3 $2A $7F
1892839.791 From MidiFire Control 3 $2A $7F
1892839.991 From MidiFire Control 3 $20 $7F
1892840.291 From MidiFire Program 16 $03
1892840.791 From MidiFire Program 16 $01
As you can see from the above, I received all the CCs and program changes as specified in the ruleset and the timestamps correlate also. So, I cannot reproduce this I'm afraid. Now, I did find a bug in the Event Monitor (fixed for next release) where events with delays > 4500 or so were not displaying timestamps correctly but that would not have affected the events output to the interfaces/apps. Could you try dropping the network in/out pair of ports onto the canvas. Connect the output of the net in to another event monitor. Connect the two filtering Stream Byters to the net out. Use the 'Setup' panel and make a CoreMIDI network connection to localhost. Now check that new event monitor and see if it does/does not have all the events it should. I just tried this and I did indeed receive all events correctly via the network loopback also. Regards, Nic. |
|
