14 Feb
2003
14 Feb
'03
10:10 a.m.
Hi all,
I'm trying to hack up a quick app that sends MIDI clock pulses in sync
with a ringbuffer playback.
I've got it reading MIDI (thanks to Matthias' great exmaple code), but I
cant figure out how to send MIDI clock pulses explicitly. The ALSA seq
interface lets me set it up to go automatically, but I want to send a
clock pulse every 1/24th of the buffer, so the sync is correct.
I dont think I can use raw MIDI because I need the ALSA seq for other
apps, on the same MIDI port.
- Steve
PS I know there are several apps that can, or will be able to do this, but
I need it to work by saturday. Its disposable code.
14 Feb
14 Feb
10:36 a.m.
don't bet on it.
i've been thinking about this quite a lot recently. your best bet will
be to set the sequencer to use the RTC as the clock source. i don't
know how to do this. i'm not sure that even this will work, because
the RTC doesn't run in sync with the audio, so it may drift over time.
you don't have too many other choices, because there is no other timer
source capable of providing sub-audio-period interrupts.
medium-to-long term, i'm going to start recommending that people run
kernels with the high-res timer patch. like the lowlat patch, linus
has rejected this, but it seems the the folks using it are intent on
maintaining it. it provides the same sort of thing as the old KURT
patches - one shot reprogramming of the system timer to provide usec
resolution timer-based scheduling. this will allow
ardour/muse/rosegarden and others to get sub-audio-period MIDI
scheduling, much like things such as the Unitor and other "external
scheduling MIDI interfaces" provide.
there will still be the question of whether the app should do the
timing, and use the sequencer/rawmidi to do immediate delivery, or if
the kernel-side of the sequencer will be hacked to support this.
--p
11:25 a.m.
On Fri, Feb 14, 2003 at 09:28:42 -0500, Paul Davis wrote:
>I'm trying to hack up a quick app that sends
MIDI clock pulses in sync
>with a ringbuffer playback.
...
don't bet on it.
D'oh
I'm not too worried about jitter (the device I want to sync is not
fussy), just that it tracks the ringbuffer with exactly 24 pulses per cycle.
What I can't figure out how to do is contrust the MIDI byte, I've got:
snd_midi_event_t *midi_parser;
snd_seq_event_t seq_pulse;
snd_midi_event_new(128, &midi_parser);
snd_seq_ev_set_subs(&seq_pulse);
snd_seq_ev_set_direct(&seq_pulse);
snd_midi_event_encode_byte(midi_parser, 0xF8, &seq_pulse);
snd_seq_ev_set_source(&seq_pulse, portid_out);
snd_seq_event_output_direct(seq_handle, &seq_pulse);
But it doesn't appear to do anything.
Well in this case I care about syncronisation far more than timing.
- Steve
12:11 p.m.
On Friday 14 February 2003 16:18, Steve Harris wrote:
Run with 24 frames and a frame size of (needed buffer / 24).
Run this with sched fifo, etc...
Output 24 frames of silence.
Write some more silent frames (it wont be accepted before one is free), send
MIDI event for each. [Gives the MIDI device time to sync]
Write a frame of real data. Send MIDI event. Repeat.
This would give you some jitter but the MIDI device should filter that.
/RogerL
--
Roger Larsson
Skellefteå
Sweden
3:07 p.m.
At Fri, 14 Feb 2003 14:02:45 +0000,
Steve Harris wrote:
in theory, it will run like below.
but anyway you need a precise timer source to generate midi clocks
accurately, either the higher kernel HZ or an RTC timer (both need
patches to kernel) in general...
- allocate and set up the queue.
snd_seq_t *seq;
// allocation of seq handler
...
// allocation of queue
int queue = snd_seq_alloc_queue(seq);
snd_seq_queue_tempo_t *tempo;
snd_seq_queue_tempo_alloca(&tempo);
snd_seq_queue_tempo_set_tempo(tempo, MY_TEMPO_IN_USEC);
snd_seq_queue_tempo_set_ppq(tempo, MY_PPQ);
snd_seq_set_queue_tempo(seq, queue, tempo);
- put the event
tick_interval = MY_PPQ / 24;
tick = tick_interval;
snd_seq_event_t ev;
snd_seq_ev_clear(&ev);
ev.dest.client = DESTINATION_CLIENT;
ev.dest.port = DESTINATION_PORT;
ev.source.port = MY_PORT;
ev.type = SND_SEQ_EVENT_TICK;
snd_seq_ev_schedule_tick(&ev, queue, 0, tick);
snd_seq_event_output(seq, &ev);
tick += tick_interval; // next schedule
- start the queue
snd_seq_start_queue(seq, queue, NULL);
- put the next events in loop
Takashi
9:08 a.m.
Not being a coder so you can all shout me down in flames if you like if
my response is misguided ..
Isn't the pulse of MIDI clock defined by the BPM, that's how all
instruments synced to MIDI clock work... I'm a little confused as to how
they would otherwise as BPM is the defining feature of MIDI clock....
SMPTE/MTC is another thing though, it is timed in frames and maybe that
is what you need here???
You should be able to alter the tempo in real time and MIDI clock send
those changes through the system so that all machines can see that
change.... i.e. my delay unit with MIDI controlled delay times only
looks at the BPM, nothing else. Also think of 2 drum machines synced
together... when one slows down the other must do exactly the same.
I hope this is useful... but it probably isn't
cheers
Allan
- Steve
9:51 a.m.
On Mon, Feb 17, 2003 at 11:52:56 +1100, Allan Klinbail wrote:
Not AFAIK. MIDI clock is just synced to bars and the receiving unit has to
lock onto the pulses.
I have a delay box that I wanted to sync to the software, its expecting 24
MIDI clock pulses per bar and will sync to that. I dont know if midi clock
explictly states the BPM, but I know this particular box will track
variably timed clock pulses in any case.
As it happens I just fudged it by programming the tempo manually and
sticking to one tempo. It worked ok :) but it isn't really what I wanted.
Yes, but I wanted to be able to track dynamic tempos, and I dont what to
have to build a new queue for every bar. Also I wanted the beggining of
the bar to line up with the beggining of the sample loop, which requires
the pulse timing to be controlled by the player.
It could be that I just misunderstood the code Takashi sent out though.
- Steve
8082
days inactive
8085
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
6 participants
participants (6)
-
Allan Klinbail -
Martijn Sipkema -
Paul Davis -
Roger Larsson -
Steve Harris -
Takashi Iwai