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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
