|
Post by drkeys on Aug 12, 2018 15:54:35 GMT
Hi Nic,
I'm just starting to convert from MidiBridge to MidiFire. Yesterday I used MF at a gig (with a limited number of simple scenes) for the first time. It worked perfectly.
I'm trying to integrate MidiMetro into the setup. (I sent some questions about this back in the days of MidiBridge)
In MF I have a MIDI Designer Lite source connected (via an Event monitor) to the Dynamic Clock module, which I've tried connecting to a Midi Metro destination in three different ways: 1. Directly from Dynamic Clock to MidiMetro 2. Through an Event Monitor 3. Directly from Dynamic Clock, but with the Dynamic clock output also connected to an Event monitor.
MD is set up to send clock start and stop, and tempo. I can see these messages in the event monitors.
Sometimes this setup works perfectly, and then fails to respond the next time I try to start the metronome, either from MD or on the module in MF. In the past I noticed this problem, and was able to get the metronome click back by giving a direct start and stop on the MidiMetro screen.
In the MF setup that solution has sometimes worked. Some other times a tap tempo in MidiMetro followed by a start and stop has worked, but not consistently. At other times, changing the MF connections between the three configurations listed above seems to get things going. (I've seen all three connection configurations work correctly at different times.)
Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 12, 2018 17:29:02 GMT
Hi drkeys , Maybe we discussed this before, but MidiMetro has a background activity check where it will suspend itself in the background if it has not had any MIDI events for 15 minutes. This is to prevent it from draining your battery unexpectedly if it isn't used for a while. Could this be happening to you? When it suspends, it sends a notification, but you must have permitted notifications from MidiMetro to see these. To check if this is what is causing you grief, can you please verify the settings for MidiMetro in iOS' 'Notification Center' and ensure MidiMetro is permitted to send you alerts. Definitely look at that first and if we're sure it's not MidiMetro's idle background timeout kicking in then I will see what we can do next to find out what is going on. Regards, Nic.
|
|
|
Post by drkeys on Aug 13, 2018 12:50:28 GMT
Hi Nic,
I didn't have notifications enabled for MidiMetro until now.
Today I enabled notifications and made some tests:
First I ran tests with an iRig MIDI connected. I believe this interface charges the iPad, although the iPad was reporting "Not charging". Under these conditions I didn't see any notifications, and MidiMetro never failed to respond to start/stop and tempo change messages from MidiDesigner, via MidiFire.
I then pulled the iRig Midi from the lightning connector, so the iPad was definitely on battery power. In that condition I got notifications after the expected 15 minutes and I couldn't get clicks from MidiMetro. On the basis of two tests it seems that just bringing up the MidiMetro screen and then going back to other screens is sufficient to get things working again.
Am I right in thinking that MidiMetro will only suspend when the iPad is on battery? If that's the case then I think that a lot of my problems arise when I'm using my AudioBox iTwo. Presonus claim that this interface can maintain the iPad's charge but this is not the case.
So far all my tests have been done in one scene and not doing anything other than using the metronome. Next, I'll power the iPad via the iRig Midi and try a few things like scene changes and actually playing instruments.
Regards, Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 13, 2018 13:02:13 GMT
Hi drkeys, Yeah, the idle timeout will only trigger if the device is on battery power. Regards, Nic.
|
|
|
Post by drkeys on Aug 13, 2018 13:31:26 GMT
OK. Do you have any suggestions for ways to keep MidiMetro alive while on battery or on a dodgy power source?
Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 13, 2018 13:45:20 GMT
Hi drkeys , It just needs to fed some sort of MIDI event to prevent it from sleeping. You could create a 'keepalive' scene in MidiFire that you load when you want to prevent it from suspending. Create a scene as follows: MidiFire -> Stream Byter -> MidiMetro In the Stream Byter use these rules: # keepalive IF LOAD SND FE +I END IF M0 == FE SND FE +I +D10000 ENDSave that into a scene. Now, when you reload the scene it should push an active sense message into MidiMetro every 10 seconds. Regards, Nic.
|
|
|
Post by drkeys on Aug 14, 2018 15:28:01 GMT
Hi Nic,
Thanks for the advice. I've got this working and I've confirmed that it's keeping the MidiMetro alive when the iPad is on battery. I'll try this under various conditions next.
One thing I have noticed is that at one point I could see in an event monitor that Dynamic Clock was sending out Clock Tick messages when the metronome was running. I'm not seeing those messages now, although I can see the active sense messages from the Keep Alive stream byter. Is this something to worry about?
I also have a few questions about how this fix is working. I can understand how the active sense messages keep MidiMetro alive but:
1. What does the +I flag in the IF LOAD do? I am using IF LOAD to send program changes to various sound apps so I'm wondering if I should use +I there too. (From the manual I can understand why the +I in the next IF .. is there.)
2. How do the MidiFire source and the KeepAlive streambyter interact? I can see MF sending active sense messages which are exactly synchronised with the messages coming from the streambyter at approximately 10 second intervals. How is the downstream SB affecting timing of messages from the MF source?
3. As an experiment, I changed the delay to +D20000. The active sense messages were still synchronised but came at alternate 3 sec and 15 sec intervals. Is there something special about the 10 sec delay?
Thanks as always for your support. Regards, Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 14, 2018 16:25:01 GMT
Hi drkeys, I presume you are driving Metro from MidiFire, right? In this case you would expect to see the ticks coming from the DC module if you've hooked up a monitor to it. Or, maybe I am missing something? 1. The +I means 'inject' the event, so the event is not issued from the Stream Byter block but routed into MidiFire as if it was received on the MidiFire virtual port directly (in this case, it actually is, but that's by the by). You probably do not want to add +I to your program changes. Here, the first +I is used to bootstrap the Stream Byter's active sense loop. I'm basically using the +I to feed the event back into the Stream Byter. 2. this is explained also by the answer above, I hope. If not, poke me again. 3. When you changed the delay and pressed 'Install Rules' that would kick off another loop in parallel, since the old one is running too. One loop should be running at 10s and the other at 20s Regards, Nic.
|
|
|
Post by drkeys on Aug 15, 2018 8:31:38 GMT
Hi Nick,
Actually I'm using MIDI Designer to send start/stop and tempo messages to Dynamic Clock. I have a MIDI Designer source on the canvas which also routes some controls to my iOS instrument destinations. Now I have the MidiFire source on the canvas I can see that it's duplicating all these messages. The optimum way to use MIDI designer with MidiFire is something else I've been wondering about. I'll start a new thread on that.
I'm pretty certain that there have been times when MidiMetro was clicking and I didn't see Clock Ticks coming from the Dynamic Clock. Right now I am seeing the Clock tick messages, but I can't point to anything specific that made the difference.
1. 2. I understand this now. Many thanks.
3. Ok, I see now that just reloading the scene doesn't change the interval correctly. By loading a different scene first I see the expected 20 sec interval.
Many thanks, Dave.
|
|
|
Post by drkeys on Aug 17, 2018 15:00:11 GMT
Hi Nic,
I've been integrating MidiMetro into a few scenes, and noticed an additional problem: Each time I open a scene using the "Keep Alive" setup, I start another parallel loop, as you describe above, so moving from scene to scene as I intend to do (at a gig or in a rehearsal) will result in an increasing frequency of active sense messages. Is there any way to prevent this?
Keeping MidiMetro alive is actually adding quite a few complications. In addition to the above problem, I'm having to block unwanted active sense messages in various places. Is there any chance of an update to MidiMetro with an option to run indefinitely in the background on battery?
Regards, Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 17, 2018 16:15:02 GMT
Hi drkeys , No plans to spend any time on Metro at the moment; it hasn't exactly set the world on fire ;-) Here's a version of the keepalive script that won't exhibit the problem: # better keepalive IF LOAD ASS I0 = R7F R7F SND F0 7D I0 I1 F7 +I SND FE END IF M0 == F0 7D IF M2 == I0 I1 SND F0 7D I0 I1 F7 +I +D10000 SND FE END XX = XX +B ENDJust typed that in - you'll need to actually see if it compiles and works! Regards, Nic
|
|
|
Post by drkeys on Aug 18, 2018 15:59:33 GMT
Hi Nic,
The new script is sending active sense as expected, and I've confirmed this through several scene changes.
Unfortunately, somewhere along the line I stopped getting the clicks from MidiMetro. I'm sure that this happened before updating to the new Keep Alive. When I don't get clicks I also don't see Clock Tick messages from Dynamic clock.
I have a lot of saved scenes at different stages of modification so I might be able to find where this changed. I'll look into that.
Regards, Dave.
|
|
|
Post by drkeys on Aug 18, 2018 16:12:25 GMT
Hi Nic,
As far as I know MidiMetro is unique in offering control by MIDI commands, but with just about every music app including a metronome I can kind of understand why it's only people like me who appreciate the potential of MidiMetro.
In the context of MidiFire I think it's really just functioning as a sound generator (with a pitchless sound that I really like). I understand why you don't want to put time into the MidiMetro app, but is there any chance of a MidiFire module that would fulfill that function?
Regards, Dave.
|
|
nic
Soapbox Supremo
Troublemaker
Press any key to continue
Posts: 2,011
|
Post by nic on Aug 21, 2018 7:49:13 GMT
Hi drkeys , If Metro is not sounding and you're not seeing clock ticks in the monitor then it does sound like the clock is not being started. Try starting the clock manually via MidiFire UI to figure out whether it's an issue with the clock output or an issue with the remote MIDI commands? In terms of adding a metronome module to MidiFire - MidiFire does not produce audible audio; to add a MIDI controllable metronome module this would need to change. In order to become an audio producer MidiFire would need to more or less become an audio host app which would be quite a bit of effort, and it's not really a space I wish to explore (right now). Regards, Nic.
|
|
|
Post by drkeys on Aug 22, 2018 15:33:05 GMT
Hi Nic,
I understand about the MidiFire metro.
On the current situation, I can say that I tried starting the metronome from within MidiFire (using the Start/Stop button on the Dynamic Clock block), but didn't see clock tick messages or hear ticks from Metro.
I will do some more tests to try to understand what actions cause this to stop working. This will probably be in a few days time, because I have other work that needs attention.
Regards, Dave.
|
|