@falkTX; @gianfranco
Starting a new topic on Tempo Sync because it was a bit hidden into other topics. Trying to reach more people to comment.
I know it might seem not of a high priority right now while you guys are consolidating after reboot and investing in AI amp modeling and such, but having a strong midi sync would appeal to a lot of pro studio guys in need of rock solid beat perfect sync even with tempo variations. All my midi pedals from Roland, my arturia keystep and drumbrute and even bitwig can do it. Without this beat perfect sync, all the midi stuff you guys have implemented are just a gymmick. To any serious musician into midi studio work, not having this feature is a simple NO GO. It should be seen by you guys as a foundation feature and not as something that can be left to plugins developpers; to ensure all midi devices can take benefit of the beat perfect core tempo sync without issues with different flavours that do not interoperate well or at all.
I’ve backed your reboot project because I do believe in the concept, but big holes in the implementation like these are preventing you guys to venture into maintream. Investing too much in cool features that are higher in the pyramid of needs without consolidating the foundation will not pay off in the longer term.
Please make this a priority or at least someting important to work on and provide a roadmap for a strong beat perfect midi sync at the core of Mod devices. Txs
Hmmmm 
Not going to help when none of your gear supports MIDI-2.0 though …
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.
Source: RT MIDI - Page 2 - LinuxMusicians
I find the internal clock on the DuoX quite stable.I think tick_double was useful.
Now, for the rationale behind the transport
tick_doubleAPI 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 usebar_start_tickto 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 setbar_start_tickat all, even though they can be run as transport master.
Source: JACK2 v1.9.19 release | JACK Audio Connection Kit
How it behaves in sync mode I have not checked. Random MIDI jitter is not really musical. IMHO
Internal clock is indeed pretty good. It’s syncing to external source that seems to be flaky at times.
Right now I’m syncing to an external software over usb-midi and it seems pretty good.
However receiving clock on midi-DIN seems a bit less stable and/or more jittery.
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.
Thanks all.
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.
Are there particular plugins you have issues with, like the grid sequencers or arpeggiator?
And are you syncing on DIN or over USB?
An experience I had with the arpeggiator over DIN was particularly “flaky”, but it would be good to know which specific problems are occurring when so that we can find out what the cause could be.
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.
@dreamer
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
Thanks
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.
With what actually runs ModAudio jackd, raw or jackmidi?
I refer again to @brummer (= tramp) statement that under Linux, so also with the mod, raw MIDI is currently the only reliable. Jack-midi is see:
Though midi 2.0 devices will detect are talking to 1.0 and fallback.
Exactly @Steve_Lee. And there are people here like myself who use Midi 2.0 controllers, so better ask before assuming “none of your gear” supports that.
Exactly this! I’m using USB midi here to sync, clock coming from Boss RC505 being hosted by the Mod. Same with the Arpeggiator.
Please fix this! The arps and sequencers are basically useless in this state!
So you mean from the USB-A/host port (another device), not the USB-B/client port (a computer).
There could be a difference here, so I think it’s good to mention the specific USB implementation.
Yes from another device that is being hosted by mod
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)
Yes please! We would all be so happy about this 