On 03/15/2015 12:50 AM, Simon Wise wrote:
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:
[...]
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.
You're now adding midi to the mix, which is (or at least should) be outside the scope of how and why [bang~] behaves as it does.
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.
The relevant chapter that Miller cited for his book explains the ways in which this can be handled. Ideally that's all one needs.
The problem is at the edge case where someone wants to synchronize control events with the signal graph below the constraint that the system block size of 64 imposes. For block size below 64, couldn't [bang~] have a conditional where it schedules more clock callbacks with the relevant timestamps?
I don't think a use-case is needed to understand the issue, though
several are probably needed to assess the efficacy of hacking [bang~].
My quick hypothesis is that in a language like ChucK where these
constraints don't exist, the user is free to implement a prohibitively
expensive algorithm before changing it to something more sensible.
(Whereas in Pd, we have a high-latency asynchronous discussion about it.)
-Jonathan
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list