Anyway, isn't it that a way to use other cores?

I`m not an expert but “send output before “ couldn`t be really "before" but “now” or parallel "now".

Btw, I never used [pd~]

Mensaje telepatico asistido por maquinas.

Date: Fri, 1 Apr 2016 01:24:55 +0000
From: jancsika@yahoo.com
To: lucarda27@hotmail.com; pd-list@lists.iem.at
Subject: Re: [PD] DSP and Gem in the same instance of Pd

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 <lucarda27@hotmail.com> 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: brbrofsvl@gmail.com; reduzent@gmail.com
CC: pd-list@lists.iem.at
Subject: Re: [PD] DSP and Gem in the same instance of Pd
From: pd-list@lists.iem.at

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 <brbrofsvl@gmail.com> 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 <reduzent@gmail.com> 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


_______________________________________________
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



_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list