I take video from Panosonic GH4 HDMI to Ultrastudio mini recorder and in through Thunderbolt creating a 4 frame delay ie 0.16 seconds with audio from Zoom H4n coming in through USB. Adjusting this brings up a diolog saying, “The value 0.16 is too large. Please provide a valid value.”
I have tried entering various values and this dialog always comes up. Does the feature not work for USB, the mini recorder? or have I missed something.
@Dsal22 Thank you for reporting this issue. Could you please try to write decimal comma instead? “0,16”
What language/locale is your system set to?
Thanks for your reply Oliver. I do so love using MimoLive.
Decimal comma 0,16 returned the same result; the value “0,16” is invalid.
I am in Australia using English.
Oliver, when the audio is set to internal mic or Soundflower or Voila delay works fine. Aslo works fine with Plantronics headset with USB interface, but not Zoom H4n USB interface. I sit something specific to Zoom? Is there a fix?
@Dsal22 That is very strange as the delay is applied once the data is taken over by the OS, so the device type that sends it shouldn’t matter. In order to help us figure out the issue, could you please answer these questions:
Did you install any special software for the Zoom?
Could you please post a screenshot of the message?
Is there any additional message in the macOS Console app?
There’s no special software for the Zoom, just plug it in and select audio input rather than USB storage on the Zoom menu.
Nothing jumped out at me from the masOS Console app, mind you, I don’t know what I’m looking for and it’s all pretty foreign to me.
@Dsal22 Thank you for your cooperation! What happens if you use the slider instead of entering a value?
Slider is frozen. Doesn’t move. inputing a value doesn’t move it either.
Allow me to chime in.
@Dsal22 I am working on the audio engine in mimoLive and I tried to reproduce the issue you are having with no luck so far. Unfortunately I do not have the H4n available, only the much older H2 which does fine delay-wise. But let’s try and narrow the issue down a bit more.
Is there any value the number box let’s you set without complaining? My guess would be that “0” should get accepted, although that is not what you want, of course.
Does disabling and enabling the delay check box have any effect?
Have you tried setting up the source once again?
Could you set up a video source with the H4n as complementary audio device and check if the delay works in there?
As a side note, while digging into the issue I found that a bug crept into mimoLive that makes any delay setting for CoreAudio devices (such as the H4n) being ignored by the audio engine – in new documents only! The current workaround would be to save the document at least once, open it again and then set the delay value. The bug does not affect BMD or iOS devices and will be fixed in our next release. This bug has nothing to do with the user interface itself, meaning the bug is not directly related to your current issue.
Chime in by all means Beni. We have a conundrum on our hands.
You right in your conjecture that 0 is the only number that I can find that is accepted. Following the advice of the dialog and setting a very small value 0.0000000000000000001 is still “too large”.
The check box does have an the effect of enabling the feature. Checking the box act switches from greyed out to active and allows values to be entered, though 0 is the only value that is accepted.
The behaviour is persistent in new documents and saved ones and seems to be independent of the video source and other audio sources being used.
UPDATE:
I kept playing with setting up new documents with different combinations of sources, saved and reopened the document to see if the problem persisted. It did. I closed and reopened a second time and the problem had disappeared. I opened the old documents and found that the delay feature now works and I have now found that the problem that had persisted in many documents that have been opened changed and save many times no longer exists. In fact, I have not been able to reproduce the problem as of the last posting in this thread. Go figure! Rather than finding some exotic and mysterious bug I have found that MimoLive has “healed” itself. 
Wouldn’t it be something to patent that feature!
Well that mystery was short lived.
Update 2:
I turned off the recorder, reopened the document, restarted the H4n, i/o worked as normal, BUT the audio delay adjustment did not work. So the problem only appears if the document is open when the audio device is turned on. The delay cannot be adjusted even though the audio device is otherwise working.
@Dsal22 Terrific that you caught a glimpse of mimoLive’s self-healing feature, it’s still a work in progress, so we are not advertising it yet.
Back on topic, does that mean you were able fix the bug by having the device switched on before opening the document?
If not, is it possible at all that something else had changed while you were re-opening documents, for example the sample rate of the H4n or some other hardware setting? You should also be able to change the H4n’s audio processing format from the audio device settings pane within mimoLive. It is possible that the settings pane needs to be re-opened again to update the internal delay settings.
It seems to me that for the delay feature to work, the Zoom H4n needs to be connected and configured to audio i/o before opening the Mimolive document. Like the BM minirecorder, the device can be made to function after connection by toggling various panes. The audio delay slider and input, resists the toggle absolutely, to become active after a late startup. Starting the input devices before opening a Mimolive document will spare people a lot of angst, and it is as simple as that.
One more thing Beni, I wonder if you can repeat this behaviour for the H2. My money says you can. Let me know if you have time. And thanks for the goose chase, not a wild ride but a satisfactory conclusion. Much obliged.
@Dsal22 Thank you for answering all the questions and investigating along with us. With your help I was indeed able to reproduce the behavior with the H2, so you put your money on the right horse here. To me, the issue presented itself like this: At first, the delay works fine, no matter if the device was connected before mimoLive was started or after. As soon as the device gets disconnected and reconnected while mimoLive is running, delay for this particular device will stop working. To make it work again mimoLive needs to be restarted, so closing and re-opening the document on its own won’t help.
The fix for this bug will be part of our next release as well.
@Dsal22 The bug fixes are now live with the latest beta version of mimoLive (2.8.2b1). Let us know in case the beta does not fix your issue.
In a word, “fixed”!
Thanks Beni.