- if i’m using an Event Monitor block, it displays the B1 02 message immediately, though the event visualization flashes about 2 sec later, as expected. I’m just testing this remotely, only with MidiFire, creating code for use with my system later when I get home. So is it just a limitation/bug of the Event Monitor, that it does not show exactly what MidiFire will output?
or for this kind of thing are the timing variables better?
The way the delay flag +D works is that the delay applies only to when the event leaves the MidiFire app because event delays are handled by CoreMIDI rather than MidiFire itself for performance reasons.
Internally, the event is pushed immediately through to the next block (although, the flashing of the event is delayed as you note, because that is on a different thread), so delayed events will appear in an Event Monitor immediately even though they will be delayed by CoreMIDI.
If you want to delay an event internally, there are really two options I can think of:
1. Use the CoreMIDI network port configured in loopback mode (you'll need MidiBridge to do this, although MidiFire will be getting this feature on the next update). You would send the delayed event to the network output port where it would be delayed by CoreMIDI and then presented back into MidiFire on the network input. This is definitely a kludge and won't be of much use if you are using the network ports for other purposes.
2. I change MidiFire to manually abort/delay/resume routing of delayed events being sent to connected modules instead of using CoreMIDI.
If you think number 2 is something you're really going to need, then maybe add a post about this to the Suggestion Box and I will see what I can do.
For now, you can try the workaround (number 1) or just be aware that delayed events will appear in the Event Monitor immediately but are delayed when sent on to a destination.
Thanks for the thorough clarification nic, that really does make sense now.
As far as what I’m using this Event Monitor setup for, which is basically just figuring out how MidiFire works, it’s not really so important that the situation #2 you outlined above is necessary (though I was reflecting that situation #2 WOULD be a more intuitive UI for future learners of MidiFire). The workaround described in situation #1 will be adequate for my purposes, so I’ll wait for that (I’ve already upgraded to iOS 11.3, so MidiBridge is no longer an option)
While we’re on the issue though, I was wondering: are there any other tags or messages sent directly to CoreMIDI, and therefore not real-time on Event Monitors? I’m guessing from what you mentioned earlier, the +H(old) tag maybe, and maybe the Timer Variables, since they have to do with timing issues?
Ah I see... thanks for the clarification. So far... I haven't been using the +H in MidiBridge because my MIDI foot controller has this feature and I'd rather deal with it "at the source" ... but I do use this feature all the time (through the foot controller I mean).
Correct me if I'm wrong, but I think I've come across another potential CoreMIDI element. In my remote testing (I have the luxury, at times, to work on MidiFire "code" while I'm at work), I've been trying to use delayed IF LOAD > SND messages as sort of "mock up" triggers (i.e. to emulate my MIDI foot controller triggers at home)... and I've noticed that I can't +D the MIDI Clock PLAY (hex = FA) and STOP (hex = FC) type messages that control MidiFire's Dynamic Clock. So I'm assuming the Clock signal is dealt with via CoreMIDI and is not routed through MidiFire blocks in the same way as standard MIDI messages (CC, PC, and Note messages)?
Anyways, I'll keep testing... I realize if you have to respond too much to these forum posts, you won't have any time to update MidiFire!