garageCube

[AEK_98]

Hi,
We have long known that the internal MM module does not correctly detect BPM (from an audio signal). To work around this problem, we began to use the external Waveclock program. With its help, we plan to synchronize all the programs included in the creation of the show. BUT, and then a nuisance was discovered - MM does not detect the external MIDI clock signal correctly(especially, it is noticeable at values less than 100 bpm). Other programs used by us (for example, Resolume Arena) do this correctly. I described the problem now, I recorded in the form of a video. As the source of the audio signal, test files with the known BPM value (84 and 154) were used.

https://yadi.sk/i/QWKCaE37HbTkEw

Best regards,
Andrey.

[mad-matt]

I installed Waveclock (it does a good job) but I can't reproduce your issue, I have the same BPM than Arena. cf screen recordings:

https://www.dropbox.com/s/3kdc134toz2q3 ... 1.mov?dl=0
https://www.dropbox.com/s/kw7t98e80wy1n ... 2.mov?dl=0

Maybe there's an issue in loopMIDI. Could you try updating loopMIDI ?
I tested on macOS with IAC driver bus. The code for handling MIDI / BPM is exactly the same on both platforms. I will try with loopMIDI to see if it does transmit the MIDI data properly to both listeners. Does stopping Arena changes somethings in MM ?

[AEK_98]

Hi mad-matt,
You used the version for MAC OS. And we work under WIN 10.
Here is a demo version of Waveclock for Windows. Test her out.

https://yadi.sk/d/Ckjd_DFBLQrV-A

For the local machine, we use loopMIDI(http://www.tobias-erichsen.de/software/loopmidi.html ). For transmission over the local network rtpMIDI( http://www.tobias-erichsen.de/software/rtpmidi.html ). It seems to me that the problem is not related to the MIDI protocol driver, because in this case, Arena would also get the wrong BPM value. And it works correctly! Most likely, the problem should be sought in the implementation of working with the MIDI CLOCK Windows version of MadMapper.

Best regards,
Andrey.

[mad-matt]

I'll test on Windows tomorrow. I doubt there can be any difference between Windows & mac versions on MIDI side.

[AEK_98]

The problem is not not MIDI, but how the MIDI CLOCK signal picks up the Windows version of MM.
I conducted my tests on these reference files:

https://yadi.sk/d/bHqz4U740nsZDQ

Best regards,
Andrey.

[mad-matt]

At least there was a bug in Global BPM in Beta 11 (we added a "resync" option when using MIDI Clock, that's where the bug was introduced).
With official MadMapper 3.7.6 it looks good on Windows and macOS.

[mad-matt]

So to me it looks like the issue is specific to MM 4.0 Beta 11. Can you confirm ?
I'll send you a fix

[AEK_98]

Yes, in version 3.7.6 midi clock works correctly and bpm is true, but very nervous (there are short emissions).
Maybe it makes sense to use a filter for smoothing? (As an option, have an attack and release fader?)

[mad-matt]

This is because the computation of the bpm is done on the number of MIDI ticks received at points in time that is depending on your engine speed etc. But that's just a display issue. The time position will be adjusted correctly: you might see a BPM at 119.9 and then at 120.1, the engine frequency is not synced on MIDI Ticks, it depends on your screens frequencies etc., but the time from MIDI Clock will already be compensated.
The time used from MIDI clock will always be incremented by 1/24 on each MIDI ticks, so when MadMapper renders a frame, anything using time from Global BPM (generally Materials with BPM Sync), will have have the time from MIDI ticks, unrelated to the displayed BPM value. BPM value is computed based on "elapsed clock" / "elapsed time".
We could filter the BPM so that if its value computed for the last elapsed second (ie MIDI ticks / elapsed time, we do better than that but that's an exemple) is almost equal to the last computed BPM value, we use the tick count / time elapsed since the BPM is "stable", so it would end up being the exact BPM from MIDI clock if the source is stable.
But I'm wondering if there's any use for this algorithm... Let me know if you find an annoying thing in the use of current implementation.

[AEK_98]

The algorithm of work is now clear. It seems to me, let's leave it unchanged for now. When you fix the bug with the BPM definition, we will test this assembly of MM and understand whether it needs to be changed or not.
What can you say about my proposal described in the topic "Discrete corrections BPM value"?