[PD] So [bang~] can't "bang" in less than 64 blocksize, huh?

[Simon Wise]

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 
context)



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.


Simon