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: [email protected] To: [email protected]; [email protected] 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 <[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 +0000To: [email protected]; [email protected]: [email protected]: Re: [PD] DSP and Gem in the same instance of PdFrom: [email protected]'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 _______________________________________________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
