Qjackctl:

   Readable/Output:

jack-keyboard:midi out --------------> K        seq64 output port  A
seq64:jack-keyboard midi_in ---------> J
seq64:yoshimi midi in ---------------> Y

   Writeable/Input:

jack-keyboard:midi in <--------------- J        seq64 input port
seq64:jack-keyboard midi_out <-------- K
yoshimi:midi in <--------------------- Y        seq64 input port

Options:

   MIDI Clock:

jack_keyboard:midi_out

   MIDI Input:

yoshimi:midi in          Cannot activate/connect I/O
jack_keyboard:midi_in

   seqedit bus dropdown:

jack_keyboard:midi_out   A

Why is yoshimi:midi in not an output????

   Commenting out the perform's swap() call changed nothing!!!!!

midi_jack_info::get_all_port_info():

out:  jack-keyboard:midi_out

in:   yoshimi:midi in
in:   jack-keyboard:midi in

Connect issues with JACK, jack-keyboard, yoshimi, and seq64:

   midibus jack-keyboard:midi_in (is input port):

midibus::api_connect() has null m_rt_midi pointer.  Fixed as a
configuration-related issue.

Clicking on jack-keyboard:midi_out in the MIDI Input tab is meant to
connect the output of the jack-keyboard application to seq64's
selected MIDI input port.

mmbus::set_input(0, true)

m_inbus_array[0].m_bus is  jack-keyboard:midi_out

   Back to the beginning:

At startup, we register "jack-keyboard midi_out".
When we click ...., we try to register it again!  Why
does it get registered at startup???  It is set to off
in the "rc" configuration!

jack-keyboard:midi_out is a Readable Client/Output port
jack-keyboard:midi_in is a Writable Client/Input port

Latest run:

rtmidi % ./Seq64rtmidi/seq64 -J
[Reading rc configuration /home/ahlstrom/.config/sequencer64/sequencer64.rc]
[Reading user configuration /home/ahlstrom/.config/sequencer64/sequencer64.usr]
= jack_client_open(seq64)
[JACK server already started]
= jack_set_process_callback(info)
= jack_client_open(seq64-transport)
[JACK server already started]
= jack_get_client_name(sync)
= jack_get_uuid_for_client_name(sync)
[JACK client:uuid is seq64-transport:4]
= jack_on_shutdown(sync)
= jack_set_process_callback(sync)
= jack_set_session_callback(sync)
= jack_set_timebase_callback(sync)
[JACK sync master]
5 rtmidi ports created:
Input ports (3):
  [0] 0:0 system:midi_playback_1
  [1] 1:1 jack-keyboard:midi_in
  [2] 2:2 yoshimi:midi in
Output ports (2):
  [0] 0:0 system:midi_capture_1
  [1] 1:1 jack-keyboard:midi_out

midibus '[0] 0:0 system:midi_playback_1' created
midibus '[1] 1:1 jack-keyboard:midi_in' created
midibus '[2] 2:2 yoshimi:midi in' created
midibus '[0] 0:0 system:midi_capture_1' created
midibus '[1] 1:1 jack-keyboard:midi_out' created
= jack_port_register(system midi_capture_1)
= jack_port_register(jack-keyboard midi_out)
= jack_activate(info)
= jack_connect(jack)
= jack_connect(jack)
= jack_activate(sync)

MIDI Options:

   Clocks:

0 system:midi_playback_1
1 jack-keyboard:midi_in
2 yoshimi:midi in

   Inputs:

0 system:midi_capture_1
1 jack-keyboard:midi_out

sequencer64.rc:

   [midi-clock]

   3    # number of MIDI clocks/busses

   # Output buss name: [0] 0:0 system:midi_playback_1
   0 0  # buss number, clock status
   # Output buss name: [1] 1:1 jack-keyboard:midi_in
   1 0  # buss number, clock status
   # Output buss name: [2] 2:2 yoshimi:midi in
   2 0  # buss number, clock status

[midi-input]

   2   # number of input MIDI busses

   # [0] 0:0 system:midi_capture_1
   0 0
   # [1] 1:1 jack-keyboard:midi_out
   1 0

Qjackctl:

	Readable/Output =

	 	jack-keyboard:midi_out <-------------------
		system:midi_capture_1 (nanoKey) <--------- | ------
|       |
	Writable/Input =|       |
jack-keyboard:midi_in                      |       |
seq64:jack-keyboard midi_out <-------------        |
seq64:system midi_capture_1  <---------------------
system:midi_playback_1 (nanoKey)
yoshimi:midi in

If we click on MIDI Input jack-keyboard:midi_out, we get:

   = jack_port_register(jack-keyboard midi_out)
   register_port: JACK error registering port jack-keyboard midi_out

Similarly for the virtual keyboard:

   = jack_port_register(system midi_capture_1)
   register_port: JACK error registering port system midi_capture_1

Seq64 shows an output for yoshimi:midi in, but there is no
"seq64:yoshimi midi in" shown in the Readable/Output tab.

BEEF UP THE OUTPUT.

Date: Tue, 25 Apr 2017 04:16:58 -0700
From: Animtim <notifications@github.com>
Subject: Re: [ahlstromcj/sequencer64] Jack midi less precise than alsa midi (#73) 

Oh, I just noticed this timing issue is highly depending on jack buffer size.
I initially had it set to 1024 (and 3 periods). Issue is subtle but can be
heard.  Then I tested with 256, and couldn't really hear the issue (but then I
have occasional xruns, very few but still).  Then I tested with 2048, and the
issue gets really worse, really easy to hear it.

Date: Fri, 19 May 2017 02:30:07 -0700
From: Animtim <notifications@github.com>
Subject: Re: [ahlstromcj/sequencer64] Any mechanism for live tempo control? (#86) 

I see what he means: for now, when using jack transport, the bpm seems to be
locked in seq64 while playing. That is both true as master and as slave.For now
my workaround is to use "old school" sync with midi clock, and not use jack
transport.
																	 
Note that in my case, as I want to sync seq64 with ardour5 and the latter
doesn't seem to support getting external tempo, so I define/change the tempo in
ardour and send its midi clock to seq64.. but that is more an issue from the
ardour side.

Date: Wed, 24 May 2017 06:16:53 -0700
From: Animtim <notifications@github.com>
To: ahlstromcj/sequencer64 <sequencer64@noreply.github.com>
Subject: Re: [ahlstromcj/sequencer64] Any mechanism for live tempo control? (#86) 

I started quickly testing the wip branch, changing bpm seems to work now with
jack transport, at least correctly as slave.  When using seq64 as jack
transport master, changing bpm does some weird time-position shift, both when
using numeric input or the tap bpm button.  And also, when using it like this
with ardour, ardour does some weird stop/play at every bpm change from seq64.

. . .

after testing again launching only seq64 as transport master and carla as
plugin host, changing bpm in seq64 doesn't make weird time-position shift, so
it was probably a kind of transport-position conflict from launching ardour
before.
 

ate: Mon, 22 May 2017 06:12:17 -0700
From: jean-emmanuel <notifications@github.com>
Subject: [ahlstromcj/sequencer64] [Jack Transport] Seq64 doesn't reposition jack
        transport (#88)

Jack transport repositioning function is only called when seq64 is set as
transport master, this doesn't conform to common usage : clients can
relocate, the transport master's only privilegied controls are related to 
bpm and cycles lengths. Hydrogen's handling of jack transport is a good
example we could follow, what do you think ?

. . .

     I still thinking that "JACK slaves" should not change tempo;

I agree, it's the transport's position that's supposed to be changeable by
slaves.


http://www.jackaudio.org/files/docs/html/transport-design.html

     Transport Control
     The JACK engine itself manages stopping and starting of the transport.
     Any client can make transport control requests at any time.

     Repositioning
     These request a new transport position. They can be called at any time
     by any client. Even the timebase master must use them

. . .

Also, when testing seq64's jack related things, note that there is a bug
that currently prevents any jack-related change to actually work when done
from the gui, you have to relaunch the app...

Yoshimi:

>Curious:  What JACK settings (frame size, etc.) do you use on your setup?        
>I find that if I see JACK to use a fairly large latency (10 ms) qjackctrl        
>and yoshimi bitch a lot about xruns; and I have a pretty decent i7 laptop.       

That's very strange.

I usually work at 48k, 64 frames/period, 2 periods/buffer which gives 2.67mS.
Sometimes I go down to 32 frames - cos I can :)

I almost always use ALSA MIDI and Jack audio.

I just double checked with both 48k and 96k with 256/512 periods respectively
giving 10.7mS and ran a reasonably complex tune (uses 10 tracks) and had no
problems, so I'm wondering eactly what setup you have that's causing problems.
In the Qjack messages window is it fingering Yoshimi as the problem or just a
generic one?

Also, you generally need to have Yoshimi set to the same period size as the
jack one (for ALSA, Yoshimi *sets* the overall period/buffer size).

There is no benefit at all in having Yoshimi's buffer larger, and you waste
time handling larger (mostly empty) buffer space.

Having it smaller can improve MIDI timing if you have an ALSA MIDI source, with
Jack Audio, however it will be at a higher processer load. It's only worth doing
if you have a lot of other stuff talking through Jack - otherwise you'd be
better of just reducing the Jack buffer.

