[PD] DSP and Gem in the same instance of Pd

Lucas Cordiviola lucarda27 at hotmail.com
Fri Apr 1 04:22:17 CEST 2016


Further more if you have 300 calculations to do in a given time and you split somehow those calculations in 2 calculators you have more chances not to exceed 1 calculator limits. Even overheat 1 calculator.

Mensaje telepatico asistido por maquinas.

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




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 at yahoo.com
To: lucarda27 at hotmail.com; pd-list at 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 at 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 +0000To: brbrofsvl at gmail.com; reduzent at gmail.comCC: pd-list at lists.iem.atSubject: Re: [PD] DSP and Gem in the same instance of PdFrom: pd-list at lists.iem.atI'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 at 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 at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________Pd-list at lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list     _______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 		 	   		  

      		 	   		  

_______________________________________________
Pd-list at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160401/9cfe4a50/attachment-0001.html>


More information about the Pd-list mailing list