But comes in the future, certainly slowly since the hen egg phenomenon also prevails here.
I would also find 14 bits useful.
With what actually runs ModAudio jackd, raw or jackmidi? Raw MIDI is the most stable/most direct.
However, well known is as well, that jack-midi never was done for interact with “hardware synthesizers”. For hardware midi handling you indeed better use raw alsa.
That changed, when interaction with software midi devices steps up in the game.
jack-midi is handled in the realtime-audio thread of jack. Developers needs to be aware that anything not real-time save shouldn’t be done in the jack_process_callback, regardless if it is midi or audio. You may imagine that a couple of VSTi plugs ain’t have a clue about this.
jack-midi does exactly what jeff proposed, no timestamp, plain messages handled as they comes in.
I must admit that I use midi only as a controlling interface, so jitter ain’t matter for me, but, for my use case, jack-midi is the best, and painless choice for me and the users.
I find the internal clock on the DuoX quite stable.I think tick_double was useful.
Now, for the rationale behind the transport tick_double API update:
When using JACK transport to sync between clients with precise timing requirements (such as MIDI sequencers) rounding errors would accumulate and eventually make the separate clients out of sync.
This was observed in Carla and mod-host, which use audio plugins as JACK clients. Some MIDI plugins could miss notes due to rounding errors. This change has been deployed in MOD Devices for a couple of releases already and it is known to work (that is, it corrects the situation).
There were discussions on IRC about this potentially be unnecessary, that clients can just use bar_start_tick to store the non-integer part of the tick.
While the idea could work in theory, supporting it turns out to be non-trivial and from all applications that I have tested none implemented this part correctly.
Some applications do not set bar_start_tick at all, even though they can be run as transport master.
The purpose of this thread is not to discuss mod device internal clock stability. It is about the ability of mod device software to slave to an external clock in a beat perfect way. This means whatever the external clock does: increase/decrease tempo, stop start etc… all midi sequencers, loopers and other devices requiring to stay musically in sync meaning on the beat and the right one, all stay perfectly in sync all the time.
Today with how mod audio has implemented it it is by far not the case. Try to sync your duox or dwarf to say a drumbox, have your mod device run a sequencer and change tempo or just stop start, and the sequencer will be hopelessly out of sync.
All my hardware synths, sequencers and drum boxes do it at least decently. All arturia devices do it perfectly, Behringer deepmind does it less well.
Please let’s try to stay on that very topic so that it does not get lost in overall midi topics.
Do you sync mod effects like delay and such or musical parts like sequencers, loopers etc? Current sync is more than ok for time based effects as they don’t need to be beat perfect in sync withe the host.
I can’t use Floaty by Remaincalm with external sync by an Elektron machine. Subtile tempo changes creates nasty cuts in audio.
All my paddleboards are externally tempo synced over DIN.
The LP3 Basic does a good job. Still transport changes should be impelmented.
A more stable and complete syncing would be in my interest.
The issue is with any of the mod audio sequencer, arpegiator whether either USB or din.
Are you from Mod audio? They know about the issue. Sync to host had not been implemented further than merely tempo matching. This works ok with delays and such but not with musical plugins like sequencers or arpegiators and loppers.
This thread is not meant to seek help from other users but rather to get mod audio to implement beat perfect midi clock sync to host
No I am not, but I am a developer and experienced with the platform. By now we all understand what your goal with this thread is so you don’t have to repeat it with every post. My goal is to figure out and pinpoint where the issues could be, hence asking specific questions on what problems people are having. More than just “clock sync is bad, needs to be good”, which is not very useful information. So lets figure it out by being explicit about our setups.
In my limited experience the most issues I had was specifically with DIN, but recently syncing over USB (and I mean usb-client on the B port to a computer, not the usb-host A port to a sequencer device) worked rather well.
Again, if we can figure out the specific conditions and results it can help debugging the problem. Maybe share some pedalboards that can clearly demonstrate the issue.
You need an example pedalboard to demonstrate the issue? Easy. Just start with a blank one, add a sequencer or more, slave it to an external clock and there you have it. In one single minute it will already be off tempo. Easily 2-3 cents per bar.
Anything you do inside of Duo X that requires external tempo fails terribly. Even USB by the way. Less bad than 5-pin midi but still bad. And no, the internal clock is not pretty stable, I had it analysed through an oscilloscope and it’s less precise than any other gear I operate. My interfaces are RME and my main clock is an E-RM that costs more than the Dwarf, so I know what good clock is.
There is an underlying quite tough technical challenge here - mapping what are basically pulses into steady, continuous ticks for audio plugins to use.
Typically on audio plugins the transport is given as either BBT (bar-beat-ticks) or pulses per quarter (notes), with extra information like BPM and time signature.
The issue is that there is simply no easy way to convert from simple pulses into a steady rolling timeline like what DAWs use.
The MIDI Clock provides pulses, as indicator for “tick next step”, which would be 1/4 of a beat on a 4/4 time signature.
Finding BPM of a signal of pulses is possible by measuring the distance between them, with some filtering for jitter in the signal.
Most plugins rely on more precise information than just this though, specially in regards to stable continuous timings (for example, readjusting delay lines when BPM changes).
The 2 things do not mix very well though.
That is not to say things can’t be improved, for sure there is room to spare on the MOD implementation for this, to at least get more stable or precise timings given to plugins. For one, the filtering for the BPM retrieved from MIDI Clock is too heavy, making it so that changes take longer than expected to be reflected in host tempo and thus plugins too. Also phase sync, a MIDI Clock pulse should trigger the start of the beat, which is not the case right now.
I disagree that this is something to be solved system-wide and not directly in the plugins. Because of the translation between MIDI Clock to LV2 position is not ideal, some plugins wont work as expected when MIDI sync (MOD receiving data) is enabled.
Take the step sequencer for example, it is driven by the host LV2 position which makes it perfectly sync when the tempo is stable, when the tempo fluctuates a bit (BPM unstable because of jitter between MIDI Clock pulses) the steps wont always be triggered as expected.
In my opinion if the target is to do MIDI sync then the plugin shouldnt care about tempo/position translated from the host, instead it should use the MIDI clock pulses directly as a way to trigger the next step. That would make it “perfectly sync” because it is being driven directly by the MIDI Clock.
We have ways for plugins to directly access the MIDI clock pulses, this is in use by looperlative.
The path forward should be to update plugins to (optionally) make use of MIDI Clock, with the step sequencer being a good first contender.
(and of course also try to make the MIDI sync better, but best to acknowledge host provided tempo/position can’t be perfect with MIDI)
I think one issue (for me) also seems to be that the transport doesn’t always accurately start with an MTC start signal. So this way the sequencer or arpeggiator can easily be misaligned with the source start.
This combined with the added jitter can really be quite impossible to use.
right, another thing to take into consideration too.
I was just talking with Robin @x42 regarding how Ardour does the MTC side, have some good pointers for things to look into once MOD can dedicate some time for this.
updating the step sequencer is still a good step, and allows to quickly test/check if the clock sync is working proper.
and I am thinking having such clock as CV pulse in Cardinal might be quite handy too, for driving things based on a hardware timing rather than the DAW/Host.