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