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
Full Version: Super unstable MIDI clock output
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
Nice. I was messing around with some MIDI clock/utility VSTs yesterday, but I'm glad you sorted this out. How stable is the clock?
It was nice jamming with you yesterday, once I sorted out my echo
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.
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.
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
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
captaincancelThing 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
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
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
And there is conflicting schools here that say you have to follow the BPM/BPI of the room, because (I'm assuming) it affects how chord progressions are followed and if the BPI is not followed, guitar chords will fall on a different interval than bass.
Given your experience around here, have you successfully jammed an arbitrary BPI/BPM without following the room's settings?
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.
Does the room's clock derive from the Jammr server node, i.e. is it a master/slave relationship between client and server with respect to the MIDI Beat Clock?
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.
This is a chicken and egg thing. MIDI clock doesn't work, so the only people attempting this are freewheeling their drum machine.
Many of the jams I've been in use 12 bar blues, or similar standard progressions. That's because the delayed interval format lends itself well to these styles of music.
Most electronic music falls into this same category. Techno is an entire genre of repeating 8 or 16 bar phrases, and I know plenty of people who collaborate this way - usually in person, or by passing protools sessions back and forth with dropbox. No one is doing this on jammr because you can't do it without a functional MIDI clock. If you can fix it, you will open things up to a lot more users. I have a lot of techno friends not on jammr that I would absolutely ask to jam with me this way, if it was possible.
stefanha
The MIDI Beat Clock approach is prone to drift. How much variation you experience depends on your computer.
Based on what I've experienced, and your technical description of how jammr produces it's clock, I think the issue is more network latency and buffering. I've got a very beefy media production laptop, lots of cores/ram, and when I clock Ableton to Jammr what I see is a lot of stuttering. 85 bpm for a few seconds then a quick 90bpm that then dives down to 82 bpm, then settles back to 85 for a few seconds before jumping around again.
I'll take a look at the wahjam sourcecode and see if there's anything I can contribute. I like your idea of timestamps, have you considered alternately having a separate timing/interrupt process dedicated to a MIDI clock that is synced to the session metronome? In other words, have your locally derived MIDI clock sync itself to your session clock based on timestamps.
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.
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.