Re: triggering just play start / stop

From: Alexandre Ratchov <alex_at_caoua.org>
Date: Sat, 17 Sep 2022 12:41:55 +0200
Hi,

I don't know how works your hardware, but let me summarize how this is
handled by midish

There are 3 protocols:

- MIDI clock: there's a start/stop signals and clock ticks (1/24-th of
  quarter note). They are sent by the master clock source (sequencer)
  and allows slave sequencers to start synchronously and to stay
  synchronized. There's no tempo concept, the clock tick rate defines
  the tempo.

  midish may generate these (if "dclkrx" is nil, the default) or
  follow a master clock (if "dclkrx" is set). MIDI clock information
  is transmitted to all devices in the "dclktx" list.

  If all of your equipment supports MIDI clock, you could setup the
  keystep as "dclkrx" and put all other devices in the "dclktx" list.
  Then type "p" in midish. Playback won't start, midish will wait the
  keystep to send the start & clock signals. Tempo changes in the
  midish project will be ignored as well, midish will follow the
  keystep clock.

  So when you push the "start" button, everything starts and, most
  importantly, stays in sync.

- MIDI machine control (MMC). These messages correspond to bare
  buttons on MIDI control surfaces. A sequencer receiving a MMC start
  will act as if it's start button was pressed.

  As you want to control everything from the keystep interfacee, I
  recommend to disable transmission of MMC (run "dmmctx {}")

- MIDI time code (MTC). This similar to the MIDI clock, but uses
  seconds instead of musical time units (like 1/24-th of quarter
  notes). It's used to synchronize a MIDI sequencer to audio/video
  equipement.

  Basically, the sequencer receives MTC and uses it as time reference
  to generate the MIDI clock. It's controlled by dmtcrx and
  disabled by defaut.


On Fri, Sep 16, 2022 at 01:02:17AM -0500, Matthew Bockol wrote:
> Just another addendum...
> 
> I ran debug mididev 1 to see what was being sent/received:
> 
> without dclkrx 0 where the Uno and Volca start their internal sequences:
> 
> [0000:00]> debug mididev 1
> [0000:00]> p
> ... starts immediately ...
> mididev_flush: 0: dev 1: f8 fa <-- signal to the USB to MIDI device to start
> mididev_flush: 0: dev 1: f0 7f 7f 6 2 f7
> mididev_flush: 333997: dev 1: f8
> mididev_flush: 396997: dev 1: f8
> mididev_flush: 459995: dev 1: f8
> mididev_flush: 521994: dev 1: f8
> 
> I believe it's the f8 fa message being sent on dev 1 ( the usb to midi that the
> volca and uno are listening to ) that triggers them to start playback.
> 

seems correct, as "dclkrx" is not set, midish is the master clock source
and it starts immediately.

> 
> Verses with dclkrx 0
> 
> [0000:00]> debug mididev 1
> [0000:00]> p
> ... nothing happens till ...
> mididev_inputcb: 87842193: dev 0: f0 7f 7f 6 2 f7 <-- hit start on keystep
> mididev_inputcb: 87852194: dev 0: fa f8
> mididev_inputcb: 87922192: dev 0: f8
> ...
> mididev_inputcb: 89257164: dev 0: f8
> mididev_inputcb: 89342162: dev 0: f8
> mididev_inputcb: 89422160: dev 0: f8
> mididev_inputcb: 89507158: dev 0: f8
> mididev_inputcb: 89572156: dev 0: f0 7f 7f 6 1 f7 <-- hit stop on keystep
> mididev_inputcb: 89583156: dev 0: fc 
> 
> Where I see a fa f8 message coming from the Keystep ( dev 0 ) but it's not
> being passed out to dev 1 so they don't start.
>

seems correct, midish waits for the start signal and starts and sees
the clock ticks.

you need "dclktx {1}" for the clock information to be forwarded

> This is with dclktx { 1 } and various permutations of dmtcrx 0 / dmmctx { 1 }.
>

To summarize, AFAIU, you need these:

dmtcrx nil 	# disable MTC, just in case
dmmctx {}	# disable MMC to not disturb any device
dclkrx 0	# make device 0 the master: receive start/stop/spp/clock
dclktx {1}	# transmit start/stop/spp/clock to device 1
p

at this point pressing start on the keystep should make device 1
start. Make sure it's not already started.

If it doesn't work, could you send me the output with "debug mididev 1"
as you did?

Once this works, you could setup the "fmap" rules so that the voice
events flow between devices

Alexandre
Received on Sat Sep 17 2022 - 12:41:55 CEST

This archive was generated by hypermail 2.3.0 : Sun Sep 18 2022 - 01:30:01 CEST