[PD] MIDI input time resolution
IOhannes m zmölnig
zmoelnig at iem.at
Mon Jul 13 11:13:49 CEST 2015
On 07/13/2015 09:44 AM, Alexandre Torres Porres wrote:
>> so how do you generate you MIDI events to be
>> properly alligned with some sample clock?
> I'm not sure, I'm just using regular MIDI input keyboard gear
in that case, i wouldn't bother about the Pd side.
you are basically arguing that having the note-in messages to be alway
64 sample aligned "cannot be right" (which is conceptually true), but in
practice you have no way of controlling *when* the note-in messages
actually *should* appear (so quantizing them to 64 samples is as good as
there are plenty of simplifications of the real world in all software
you use. unless you hit a specific problem, there is little reason to
so to return to your original question:
On 07/13/2015 07:33 AM, Alexandre Torres Porres wrote:
> I'd like to know why is that anyway...
it's because Pd calculates all messages (and to be precise: DSP as well)
in bursts at the block boundaries.
this has practical reasons.
eg. no known operating system would allow you to process messages
(interrupts, callbacks,...) "on-time" with infinitely precise timestamps
in zero time. so you need to buffer anyhow.
now Pd maintains timestamps for internally generated messages, to
acchieve "infinitely precise timing".
but this only works if Pd knows when the events actually need to be
most MIDI apis do not give you precise timestamps. So whenever Pd asks
for any MIDI message in the queue (which Pd does at the block
boundaries), the system just delivers the messages that arrived, without
telling Pd when they actually arrived on the hardware.
btw, *some* MIDI APIs (e.g. jack) have timestamps, even though Pd does
not use them.
> And how about when you have several values coming from [ctlin] for
In real world, sending a MIDI-event takes time. and sending two events
takes (about) double time.
so if you manage to press to keys on your MIDI keyboard at *exactly the
same time*, the note-in messages will still be sent one after the other
and you get a slight arpeggio. (not very prominent with two keys; but a
known problem if you want to play e.g. clusters)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Pd-list