Home of the jammr Community
Heres My Solution to getting you Equipment to sync with jammr or other apps that only support sending midi sync and not reciveing sync signal
Download and install Loopmidi https://www.tobias-erichsen.de/software/loopmidi.html
Add a Virtual midi device
Download and install midipatchbay http://en.soundigy.com/midipatchbay.php
Run midipatch bay and link loopmidi to your midi device(s)
Start jammer and set your midi device to loopmidi you should now revieve sync mmidi data from jammrs metronome via loopmidi
Offline
HighAction
Heres My Solution to getting you Equipment to sync with jammr or other apps that only support sending midi sync and not reciveing sync signalDownload and install Loopmidi https://www.tobias-erichsen.de/software/loopmidi.htmlAdd a Virtual midi deviceDownload and install midipatchbay http://en.soundigy.com/midipatchbay.php Run midipatch bay and link loopmidi to your midi device(s) Start jammer and set your midi device to loopmidi you should now revieve sync mmidi data from jammrs metronome via loopmidi
Offline
Hi everyone,
The MIDI Beat Clock approach is prone to drift. How much variation you experience depends on your computer.
If it does not work well it may be necessary to manually set the BPM for external apps or devices.
Here is more detail:
Although jammr's metronome is sample-accurate and does not drift with respect to the audio stream, the MIDI messages sent to external apps or devices are delivered by the computer's MIDI drivers without timestamps. External apps or devices receive the MIDI Beat Clock messages whenever they receive them and then try to determine the tempo by measuring the timing between messages.
This mechanism is imprecise because small timing variations between receiving MIDI messages cause the inter-message time measurement to drift.
It's possible that jammr's code can be improved to tighten the timing on the sending side, but this won't eliminate drift completely.
Maybe there are MIDI protocol features that can be used to improve the situation. This requires some study and maybe someone here knows?
Adding a different tempo synchronization mechanism to jammr is probably the long-term solution. There are newer mechanisms like Ableton Link that might to tempo sync in a more reliable way.
The MIDI Beat Clock drift issue is on the todo list but it's only used by a small fraction of users. Therefore the priority isn't high. If anyone with coding skills wants to work on this I'm happy to discuss the code, latency profiling techniques, etc.
Offline
More technical details in case anyone wants to improve the MIDI Beat Clock before I have time…
The metronome is updated in the real-time audio thread. It is implemented using an audio stream sample counter. Each time a MIDI Beat Clock message needs to be emitted a message is placed onto the MIDI output queue. This queue is used to pass MIDI messages to the MIDI processing thread that actually writes them to the output device.
Note that timing is already a little suspect here because real-time audio processing is only done periodically, not one sample at a time. An entire buffer of samples is processed in a single operation. For example, with a buffer size of 256 samples at 44100 Hz sample rate the latency is 5.8 milliseconds. So the processing function is only called every 5.8 milliseconds. This means the MIDI Beat Clock would only updated at 5.8 millisecond granularity.
Next, there is a dedicated MIDI processing thread that tries to send/receive MIDI messages every millisecond. All it does is read messages from the MIDI input device and write queued messages to the output MIDI device.
If your computer has sufficient cores then the audio processing and MIDI processing threads run on separate cores with good timing. However, on computers with lower numbers of cores and more applications running (plus other system-level effects related to thread scheduling, interrupts, and timers) it's possible that jammr experiences “jitter” (timing variations).
All this means that the actual timing of emitted MIDI Beat Clock messages will vary.
I suggest looking into the PortMidi (the cross-platform MIDI library that jammr uses) output latency/timestamp features. jammr currently does not use them, but they could solve the problem: the audio thread can assign absolute timestamps to MIDI Beat Clock messages and hopefully PortMidi will emit the messages at the desired time. This should make inter-message time measurement work better in external apps and devices.
The relevant code is NJClient::process_samples() and qtclient/PortMidiStreamer.cpp. Details on getting the code are available here:
https://jammr.net/opensource.html
Offline
captaincancelThing is i use a diiferent setup to the one i suggested to you because i host drums a lot i let my
Offline
stefanhaAwesome info! Thanks for the overview… I may learn more than I bargained for coming here. Look forward to taking a deep dive at the first opportunity.
l
Offline
HighAction
Thing is i use a diiferent setup to the one i suggested to you because i host drums a lot i let my
accompnement application handle the timing of the midi messages which i set manuly.
this way it dont seem to suffer from same problems you are experienceing
However i do use the same method of connecting my mixer to my applications as mixer has Echos, Reverb and such Fx
Edited captaincancel (April 19, 2020 13:30:23)
Offline
stefanha
Hi everyone,The MIDI Beat Clock approach is prone to drift. How much variation you experience depends on your computer.If it does not work well it may be necessary to manually set the BPM for external apps or devices.Here is more detail:Although jammr's metronome is sample-accurate and does not drift with respect to the audio stream, the MIDI messages sent to external apps or devices are delivered by the computer's MIDI drivers without timestamps. External apps or devices receive the MIDI Beat Clock messages whenever they receive them and then try to determine the tempo by measuring the timing between messages.This mechanism is imprecise because small timing variations between receiving MIDI messages cause the inter-message time measurement to drift.It's possible that jammr's code can be improved to tighten the timing on the sending side, but this won't eliminate drift completely.Maybe there are MIDI protocol features that can be used to improve the situation. This requires some study and maybe someone here knows?Adding a different tempo synchronization mechanism to jammr is probably the long-term solution. There are newer mechanisms like Ableton Link that might to tempo sync in a more reliable way.The MIDI Beat Clock drift issue is on the todo list but it's only used by a small fraction of users. Therefore the priority isn't high. If anyone with coding skills wants to work on this I'm happy to discuss the code, latency profiling techniques, etc.
Edited captaincancel (April 19, 2020 13:34:51)
Offline
stefanha
The MIDI Beat Clock drift issue is on the todo list but it's only used by a small fraction of users. Therefore the priority isn't high. If anyone with coding skills wants to work on this I'm happy to discuss the code, latency profiling techniques, etc.
stefanha
The MIDI Beat Clock approach is prone to drift. How much variation you experience depends on your computer.
Edited eb_liveDrums (April 19, 2020 17:21:38)
Offline
The MIDI Beat Clock is not related to network latency. MIDI is only local to your computer. jammr does not transfer MIDI over the network.
Another way of explaining the current clock drift behavior is that jammr knows the right time at which to emit a MIDI Beat Clock message, but the MIDI message is sent at an arbitrary point in time afterwards. The precise timing currently depends on your computer or you could say it's left up to chance. Adding a timestamp will ensure that the receiver knows exactly when the MIDI Beat Clock message is supposed to happen, regardless of when it was actually sent and received. This should significantly reduce drift.
Don't worry, I will get to this if no one else does before me. At the moment it's looking like 3 weeks.
Offline