This might be too esoteric to be practical, but:
There's also the possibility of spreading spikey control operations over
a longer duration of time.
For example, let's say you analyze some input and want to see if it matches
anything in a list of 500 elements. If you have one second before you need
to act on the result of that test and your sample rate is 44100, you can
trigger each iteration of the loop with [bang~] and be guaranteed that the test
will
finish on time. That way each dsp tick only requires a single iteration
through
the loop, which probably gets rid of your spike.
Furthermore, you could just wrap this in an abstraction that takes two
floats-- one for the number of iterations, and the other for a duration in
which
the durations must finish. Then it queries the sample rate and figures
out how many iterations must happen each dsp tick without exceeding
the goal duration.
-Jonathan
On Friday, April 1, 2016 1:09 AM, Matt Barber <[email protected]> wrote:
Pd's constraints make the automatic allocation unlikely.
Read this:http://puredata.info/community/conventions/convention09/puckette.pdf
'Since at least 1990, users and critics of Max/FTS haveobserved that it would
be desirable for objects to be automaticallyallocated to processors in a way
that would minimizethe bandwidth of interconnections between the objects.
Thiswould free the user from the cumbersome task of understandingthe actual
flow of data between objects in the patch; thesoftware would automatically
assess that.This didn’t prove practical, for two reasons. First, as haslong
been well known, one can’t compute the quantity of datathat will flow between
any given pair of objects in a patch (atleast, not if the patching language is
able to solve arbitrarycomputing problems). Predicting how much data will
flowwhere is hopeless.The second problem is that nobody has been able to makean
expressive patching language that doesn’t depend on objectssharing data. In
Max/FTS (and in Pd as well) this takesthe form of “named” objects such as
arrays. Any automaticdistribution of patches that allows accessing arrays would
haveto place every object that accesses any particular array on thesame
processor, or else use some kind of locking mechanismthat would be unlikely to
work in real time. Also, any situationin which there is of recombination of
message fanoutwould require that both message paths be synchronized, i.e.,that
both message paths go through the same itinerary of processorsor be otherwise
delay-equalized. In combination, theseconstraints would require that, for
complete transparency, almostany interesting patch would have to reside on a
singleprocessor. It appears to be an inescapable fact that multiprocessinghas
non-hideable effects on the execution of “patches”and can’t effectively be
carried out without the user’s activeparticipation.'
It might be easier if Pd used a system of buses for routing rather than
arbitrarily drawn patch connections, or if a graphical patching environment had
a good way of implementing something like SuperCollider's Synth, which works
with a flexible node order but has relatively limited means of input and
output. Here's what I see as the bare minimum of what we'd need to address to
make your wish a reality:
1) Unit generators instantiated in Pd have to exist somewhere in a running
patch to output. This is in distinction to SC3 and csound, where instances of
Synths or instrument templates are instantiated and destroyed. In the latter
two, the order of creation and destruction of instruments (and in csound, the
order they're defined in the orchestra) matters a lot in the DSP graph, which
makes it more predictable. SC3 also has user methods for ordering nodes.
2) Connections in Pd are flexible and arbitrarily complex, which makes the DSP
graph a lot more ramified than a mixer model with buses, inserts, aux sends,
etc., and therefore much less predictable in the abstract.
3) Pd is deterministic, which means that (as noted in the quote above), any
memory sharing across threads would need to involve locks, which can be killer
in real-time, not to mention difficult to scale and guarantee thread safety.
[pd~] communicates via FIFO because it needs to be able to keep messages and
audio in sync by block.
I'm sure there's more.
On Thu, Mar 31, 2016 at 11:07 PM, William Huston <[email protected]>
wrote:
Slightly OT-- but related:
I'm going to throw out a wish-list item
which is probably impossible or very hard to implement,
Find a way for the DSP Graph compiler to naturally
break up the task into small chunks, which all use shared
memory in a thread-safe way, so that the PD job automagically
spreads itself out over available cores without any special
work by the programmer.
Now that I've got my big, fast, lots of ram, 6-core AMD
box running again, I notice that I can run MUCH larger
graphs there than on my Raspberry Pi.
But I think it's just a raw CPU speed, or Cache Speed, or
speed to RAM which matters, and not the number of cores.
I notice that on my Pi there seems to be two processes, one for
the GUI and one for the DSP. 2 cores are wasted unless I use
the [pd~] object, and I have to basically guess how to split up the job.
I know, I'm dreaming here....
On Thu, Mar 31, 2016 at 10:57 PM, Lucas Cordiviola <[email protected]>
wrote:
And more,
A single thread calculation divided between 2 cores in its 1 core time is more
stable.
1 00 11 00 1
transistors have more idle time.
Mensaje telepatico asistido por maquinas.
From: [email protected]
Date: Thu, 31 Mar 2016 22:45:57 -0400
Subject: Re: [PD] DSP and Gem in the same instance of Pd
To: [email protected]
CC: [email protected]; [email protected]
Right, so the point of [pd~] is that the OS can now throw whatever is going on
in the subprocess onto another core. The idea from what I've heard for Gem is
that you can leave the DSP off in the [pd~] instance, run Gem from there (on
another core, possibly). Then if together they would have maxed out one core
they could split the work among two and proceed in time.
But if the problem is that Gem has to wait for something to happen elsewhere
before it can proceed, it won't help. Kind of in the same way that running an
infinite [until] loop on the subprocess will halt the main process, too.
On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list
<[email protected]> wrote:
But [cpu_hungry_hippo~] needs input from [pd~] in order to
compute its output. So [pd~] must send output before [cpu_hungry_hippo~]
can execute its perform routine.
On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola
<[email protected]> wrote:
Isn`t
[pd~] <-- some dsp stuff going on in here
To take advantage of multi-core CPUs?
Mensaje telepatico asistido por maquinas.
Date: Fri, 1 Apr 2016 00:37:26 +0000
To: [email protected]; [email protected]
CC: [email protected]
Subject: Re: [PD] DSP and Gem in the same instance of Pd
From: [email protected]
I'm not sure I understand [pd~]. Consider:
[foo~]|[pd~] <-- some dsp stuff going on in here
|[cpu_hungy_hippo~]
How does [pd~] help me in this case, as opposed to just putting the
"dsp stuff" directly in the patch?
And in general, how is the super-process able to anything
other than block when waiting for output from [pd~]?
-Jonathan
On Thursday, March 31, 2016 5:17 PM, Matt Barber <[email protected]> wrote:
One other thing that's helped in an emergency is increasing Pd's audio buffer
in the preferences.
One thing I've heard of but never tried is running Gem from a slave instance in
[pd~]. I don't know enough about it to know whether this could work or why; it
might just be a rain dance.
On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli <[email protected]> wrote:
On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
>
> Le 31/03/2016 11:19, Roman Haefeli a écrit :
> >
> > BTW: Why does the graphics rendering|clock have precedence over the
> > audio rendering (at least, it seems to be like that in Pure Data/Gem)? I
> > guess most softwares do it the other way around, since clicks are much
> > more noticeable than a frame being a few milliseconds late.
>
> Gem have no precedence over audio : they both have the same priority.
> when having priorities on audio, the openGL rendering did not have
> fixed frame rate, and it's not possible any-more to have smooth hight
> speed movement.
>
> So, i like the way it is, even if it cause implementation problem.
Oh, now since I understand, I like the way it is, too ;-)
> one possible explanation of your problem is that you are rendering a
> 60 fps, and that openGL is sync on the 60fps screen.
> You can have jitter between the 2 different 60fps clock. If Gem is
> waiting for the screen, then everything (including audio) is on pause.
That is exactly what I was doing.
> if this is the cause of your problem, then reduce Gem fps to 59, or
> remove openGL syncro (sync to vblank).
This is exactly what helped (reducing fps to 59). Thanks for your sharp
thinking.
Roman
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________pd-l...@lists.iem.at mailing
listUNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
