ahlstromcj/sequencer64

note lengths recorded are fixed to grid when in MIDI sync instead of lengths played

gresade opened this issue · 11 comments

I am using Alsa for MIDI. When I record with seq64 as clock master, the note lenghts are recorded as played. But when I switch to seq64 being the clock slave, the note length that is played is ignored, and the note length is fixed to the grid quantisation (not note lenght) setting.
The keyboard used for recording is a separate midi device and is not the clock master when seq64 is the clock slave.
I changed no settings in seq64 when going from clock slave to master and vice versa.

Also, when going back from clock slave to master again, there seems to be a lot of notes in the MIDI buffer that get played rapidly until the buffer is empty. I have to start/stop several times to get a clean start.

When you say you use Seq64 as an ALSA "clock master", how do you set that up? In Seq64, "master" is a JACK concept. Can you upload a screen shot of the setting? Thanks! Also, is the the Gtkmm interface or the Qt interface? Thanks!

I started Seq64 without launching Jack on Lubuntu (I did not start the Jack UI and server, but I can check if this is maybe launched in the background), with the -p --alsa options.
I switched from Jack to Alsa because the seq64 clock in external sync has way less jitter using Alsa.
In internal clocking also Alsa is quite jittery (this is a separate topic).
I compiled the newest sources using the Gtkmm interface with all the standard settings, no changes were made after the git clone. The Midi channel recorded is on a seperate Midi input port using a midi-keyboard. I can send a screensot of the settings later on, as this is on a separate PC. Basically all the Jack flags in the settings are switched off (--alsa command line option).
Also with these settings I can start seq24 up as a sync master with the play button.
I am in "Live" mode and set the "fruity" interaction method.
I hope this helps! Thank you for looking into this issue!

I'm still not clear how, when running in ALSA mode, how you set up ALSA clock master versus ALSA clock slave. This is probably something of which I am ignorant. Let me know how you set up or determine which ALSA clock mode. Thanks! (I like digging into this stuff... learn more that way).

Actually I did not "set up" the Alsa clock. I just ran the seq64 program with the --alsa option and got a clock running if I press play in seq64 (even if nothing is connected externally).
And my external hardware midi sequencer (Akai MPC) can also start seq64 automatically when I press play on that external midi sequencer and seq64 syncs to the external sequencer speed very nicely. I only had to connect the external midi Sequencer Midi Input in seq64 in the settings.
I thougt this should be the normal behaviour?
If you need more special infos (e.g. command line output and config files), I can send you that.

Apart from seq64 all parts are external hardware devices, so I am using an Akai MPC hardware sequencer as a clock source, an Akai Sampler that is triggered by the Midi notes of seq64 and a Yamaha hardware midi keyboard to play and record notes into seq64. So it is all external midi equipment, no software instruments and no other midi software is running on the computer.

I am starting the sequencer like this:

`seq64 -p --alsa --verbose --no-jack-midi
Forcing all-ALSA mode.
[Deactivating JACK MIDI]
[Reading rc configuration /home/none/.config/sequencer64/sequencer64.rc]
[Filter-by-channel off]
[Reading user configuration /home/none/.config/sequencer64/sequencer64.usr]
Forcing all-ALSA mode.
[Deactivating JACK MIDI]
Found port system:announce of type non-virtual input system
Found port Midi Through:Midi Through Port-0 of type non-virtual input device
Found port Midi Through:Midi Through Port-0 of type non-virtual output device
Found port USB Device 0x86a:0x01:USB Device 0x86a:0x01 MIDI 1 of type non-virtual input device
Found port USB Device 0x86a:0x01:USB Device 0x86a:0x01 MIDI 1 of type non-virtual output device
[a lot more midi I/Os...]
[Initialized, running without JACK sync]
37 rtmidi ports created:
Input ports (19):
[0] 0:1 system:announce (system)
[1] 14:0 Midi Through:Midi Through Port-0
[2] 20:0 USB Device 0x86a:0x01:USB Device 0x86a:0x01 MIDI 1
...
Output ports (18):
[0] 14:0 Midi Through:Midi Through Port-0
[1] 20:0 USB Device 0x86a:0x01:USB Device 0x86a:0x01 MIDI 1
...

[Input priority set to 1]
[Output priority set to 1]`

The settings look like this:
grafik

When I record synced to external Midi clock and record notes, they are all recorded with the snap to grid value for the length, no matter how long I hold the notes (I played some random stuff just for illustration):
grafik

Apart from this issue, the timing in this sync mode is very good.

If I do not sync externally but just hit play in seq64, the notes are recorded correctly, but unfortunately the clock and playback of seq64 is a lot more jittery.
grafik

  1. I am using the default 192, I didn`t change the setting.
  2. I run a test at 300bpm and 32th notes. My MPC can trigger them easily without chokes and sounds like a "machine gun on" but way quicker triggering a short click sample.
    When I set up the notes in seq64 and run it as a slave to the MPC clock, the seq64 notes are similar in precision, especially I get not a single choked note when dialing from 100bpm up to 300bpm with the 32th notes.
    When I switch to seq64 creating its own clock (hit play in seq64 after hitting stop a few times to clear the buffer or whatever), I get chokes (lost or clearly delayed notes) where roughly above 130bpm is not really "usable" when playing 32th notes.
    This is quite an easy test to hear galloping, chokes and buffer issues in the midi chain, basically using very high MIDI traffic, but very deterministic note distance. So it is easy to hear, as the note distance starts to be perceived more as a pitch where deviations are quite easy to hear in contrast to timing perception without lots of training.
    But I could also record this as audio for analysis to measure the jitter.
    I guess something around 5ms or more to cause noticable hickups at around 130bpm already.