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

Jonathan Wilkes jancsika at yahoo.com
Fri Apr 1 03:24:55 CEST 2016


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:
 

 #yiv7276929600 #yiv7276929600 --.yiv7276929600hmmessage P{margin:0px;padding:0px;}#yiv7276929600 body.yiv7276929600hmmessage{font-size:12pt;font-family:Calibri;}#yiv7276929600 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 at gmail.com; reduzent at gmail.com
CC: pd-list at lists.iem.at
Subject: Re: [PD] DSP and Gem in the same instance of Pd
From: pd-list at 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 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 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 

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160401/d8d0a0a2/attachment-0001.html>


More information about the Pd-list mailing list