Tempo hack?

while we wait for implementation of global BPM and MIDI sync, i’m curious whether there might be some ideas out there to hack something somewhat functional in the meantime by just triggering multiple plugins that accept tap input…

for instance, are there any plugins currently available that can read MIDI tempo at all? then, can we get output from that to drive tap tempo in plugins which use that?

or, i guess if we came up with a way outside of the MOD to translate MIDI tempo into some MIDI-CC on/off toggle, then use that to drive MOD tap tempo plugins?

or maybe translation could be done pre-MOD in an Arduino device, which then drives tap tempo through the control chain?

any thoughts?
is something like this even feasible?
anyone experimented with it?

i’m gonna have some time in the next couple of months, and tempo sync with some other folks who are running MIDI tempo is a priority for me – so i’m looking for some ideas i might pursue. :slight_smile:

1 Like

The tempo sync is planned for the v1.5 release, so not sure if a temporary hack is a good way to spend time…
We actually already have the base code working, but had to put it aside for a moment and focus on the Control Chain part.
The v1.4 is coming very very soon. After that the work for tempo sync continues again.

2 Likes

thanks for that, @falkTX – great to know the roadmap…

it’s gonna be a fantastic rig, once i dig in with the control chain pedals and arduino shield, AND then we add tempo sync! :clap:

2 Likes

hey @x42… your MIDI Quantization plugin doesn’t read BBT coming in on the MIDI input, does it? seems, from the description, that it either freewheels or uses host BBT (not available yet on the MOD).

thanks… cheers!

Nope, none of the MIDI filters parse MIDI-clock or MIDI-Timecode. They all depend on host-provided musical time as mentioned in the plugin description. MIDI messages themselves have no concept of Bar/Beat/Tick to begin with. There’s no time-signature and no explicit BPM (only MIDI files can provide this information or a plugin host can).

Live event quantization. This filter aligns incoming MIDI events to a fixed time-grid. Since the effect operates on a live-stream it will introduce latency: Events will be delayed until the next ‘tick’. If the plugin-host provides BBT information, the events are aligned to the host’s clock otherwise the effect runs on its own time.

thanks, @x42!

so, a general question to the MOD devs: when global BPM is implemented, what will be the options for receiving/sending tempo information from/to external devices…

  • reading/writing MIDI Beat Clock?
  • something over Control Chain?
  • reading/writing analog clock/pulse on the audio inputs/outputs? (yes, i know that’s a can of worms because of lots of different formats)

To me that sounds like something a plugin could do well.

1 Like

ummmmm… any takers? :wink:

…although, then it would become a question of how to USE the output from such a plugin…

the 2 applications i’d like to see are:

  • setting tempo of delays
  • triggering looper record/playback at exact multiples of a pulse

…seems those things are currently only accessible as control ports (i.e. the Tap control in Bollie Delay, and the start/stop/whatever controls in various loopers), so it’s not immediately apparent to me how the output from a plugin could be useful.

however, i know full well that there’s a LOT about all this that i don’t understand! :smiley:

So, let me try to explain what tempo sync will bring.
(note this is all work in progress, things can change before v1.5 is officially out)

On the plugins side of things, the host will provide tempo information via atom ports (standard way for LV2 to pass time info).
Also, ‘speed’ (for play/paused) and ‘bpm’ designated control ports will automatically be mapped to the current host state.
On the web interface, BPM designated controls will be hidden, and automatically set to the global BPM value.
Plugins that support LV2 time will be in sync with each other.

For external sync, we currently have working MIDI Clock output (thanks to @x42) - either always-on or manually via plugin - and also (Ableton) Link.
Should be possible to add more types of sync of course. But only 1 method of input sync is possible at a time (for obvious reasons…)

Current focus is on displaying the information on the web interface in a proper way, and allow the playback/pause state and bpm values to be addressed to hardware.
This last one is a bit tricky… if we’re changing the tempo from an external source, then it will conflict with addressings.
The good news is that the backend stuff is pretty much complete, and tested to be working. We mostly just need to figure out the user interface and usability now…

2 Likes

thanks for all that, @falkTX… sounds really great! yes, having the MOD bpm controllable by external devices (and vice versa) is crucial for us to be able to “play nicely with others”… :slight_smile:

IMO either the DUO will be the master or it must be a slave. If its not the master, it doesn’t make sense for the user to address controls to tempo or transport, becuase those will be controlled by the master (whether midi or link or whatever). If it is the master then the user can control play/pause and tempo from mod directly. If you want to send data out from the MOD acting as master to another device, you could have plugins that generate midi clock based on global bpm and transport, or an audio sync signal or whatever.

Perhaps though I’m not close enough to the problem to understand though, but that’s what makes sense to me.

1 Like

perhaps a global setting as master or slave in the settings menu on the MOD? …and could there be options in there as well to select type(s) of incoming or outgoing clock? might be more efficient, CPU-wise, than sync I/O plugins?