hi all
how can i use 2 cpus with pd? i know i can open 2 instances of pd, but how can i assign each one for a different cpu? one running a gem patch and other with a pd audio patch?
and the best way to communicate between these 2 instances is OSC?
if i record all OSC messages that i send to gem patch i imagine that i can render everything non-realtime later also - with better resolution/size... does anyone works this way? some guidelines would be very helpful...
i am on slackware 12 RC1 Linux igorpc 2.6.21.5-smp #1 SMP PREEMPT
thx in advance igor
Igor Medeiros wrote:
hi all
how can i use 2 cpus with pd?
More than one instance of Pd.
i know i can open 2 instances of pd, but how can i assign each one for a different cpu?
If you have an SMP kernel, the kernel will do it for you.
one running a gem patch and other with a pd audio patch?
and the best way to communicate between these 2 instances is OSC?
Either OSC or FUDI (with netsend/netrecieve)
if i record all OSC messages that i send to gem patch i imagine that i can render everything non-realtime later also - with better resolution/size... does anyone works this way? some guidelines would be very helpful...
I do something similar: I print all the messages I send to the terminal, with time stamps. "pd -stderr >>performance.log 2>&1" then some 'sed' magic to remove the print: prefixes and load it into qlist with "read performance.qlist cr", then play it back to render in DVD resolution. The advantage of going via the terminal, is that if Pd crashes I still have the log up to that point - hasn't happened yet, though.
i am on slackware 12 RC1 Linux igorpc 2.6.21.5-smp #1 SMP PREEMPT
thx in advance igor
Claude
hello,
Igor Medeiros a écrit :
hi all
how can i use 2 cpus with pd? i know i can open 2 instances of pd, but how can i assign each one for a different cpu?
the OS should do it for you.
one running a gem patch and other with a pd audio patch?
this is a good solution if you gem patch is really CPU intensive. by exemple, loading images will not stop audio rendering. but usually (depending on your patch in fact), gem is GPU intensive, a gem patch should not use lot's of CPU.
and the best way to communicate between these 2 instances is OSC?
netsend / netreceive work great, without any externals.
if i record all OSC messages that i send to gem patch i imagine that i can render everything non-realtime later also - with better resolution/size... does anyone works this way? some guidelines would be very helpful...
i do use this trick for recording all frame on the HD, in order to create some good quality movies of the gem windows. I record everything in a qlist and play this qlist slower. I slow down gemwin frequency on the same proportion. if your gem patch use line, delay or pipe object, you also need to slow them down also.
when creating this qlist, you nead to take care : delay 0 is not the same as no delay.
cyrille
i am on slackware 12 RC1 Linux igorpc 2.6.21.5-smp #1 SMP PREEMPT
thx in advance igor
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
cyrille henry wrote:
I record everything in a qlist and play this qlist slower. I slow down gemwin frequency on the same proportion. if your gem patch use line, delay or pipe object, you also need to slow them down also.
I didn't bother doing this, I just let Pd do the slowing down itself, seemed to work ok. The machine at full load for 6 hours to render a 30min video did get quite warm....
when creating this qlist, you nead to take care : delay 0 is not the same as no delay.
Ah, I neglected to take this into account. I'll change my patch to fix this for the next gig. Thanks for the reminder.
cyrille
-
Claude Heiland-Allen -
cyrille henry -
Igor Medeiros