[PD] So [bang~] can't "bang" in less than 64 blocksize, huh?
simonzwise at gmail.com
Sun Mar 15 05:50:37 CET 2015
On 15/03/15 01:52, Alexandre Torres Porres wrote:
> but it doesn't work for blocks lesser than 64... can't bang at each 32, 16,
> 8, 4, 2, 1 block samples... this was unexpected to me and what made me
> wonder about similar/parallel behaviours from other objects, which I also
> found to exist.
this thread is a bit confusing .... what timing are we considering:
1/ real world time of various kinds of events as sent out of hardware, say to a
gpio or to a midi port or the networking hardware
2/ real world time of events sent by pd to another process within the local machine
3/ time-stamping of events of either of those kinds
4/ the nature and relationship between the interlocking scheduling,
time-stamping and event loops within pd, and what the several different ways of
interacting with these each mean in terms of each of the above cases
5/ how any of this is related to any communications protocol which might carry
this timing information accurately, and at what latency
6/ how this all relates to the kernel, cpu and hardware scheduling, buffering
and latencies (especially at some of the ridiculously small time intervals being
considered in this thread which are completely irrelevant within pd, given this
These issues are complex and no general answers, out of context of an actual
use-case, can make much sense ... at least not at the level of a email thread.
The obvious external communications protocol available for pd that integrates
audio and control time-stamping in a readily usable way is jack with jack-midi
so how pd time-stamping works in this particular case is interesting in detail,
but I have not looked into this myself.
How each of the different ways of using timestamps and adjusting pd scheduling
in relation to computing a dsp signal work is very important, and for answers in
an email thread a use-case is needed ... there are a great number of options,
all useful in the right context.
How very tight timing of hardware inputs and outputs might be achieved is also
very interesting ... and once you want accurate timing much tighter than the
audio latency you are using you are going to need to either create a separate
external thread outside the pd loops, or for even tighter timing you are going
to need to have a hardware loop happening outside the cpu pipeline .... modern
general purpose computers are inherently awful in this respect, it is not what
they are designed to do. Using a modern desktop in this context is madness, but
if you have unlimited time and energy then a completely independent GUI program
running via carefully controlled communications on a separate modern machine
with a modern desktop is possible. Then comes the issue of how to get a single
clock pulse to run all these devices so your time-stamps make sense.
Pd is very useful as the glue in all of this, and if you are interested in the
kind of hardware which can handle this kind of work then an Udoo is not a bad
place to start looking. It has 2 chips on the board, linked via their GPIOs, one
is an arduino to run the tight loops required and the other is a quad core with
lots of GPIO that can run a suitably adjusted linux kernel that can do the
control needed and even have a core spare to run a desktop environment.
More information about the Pd-list