On Sat, 17 Apr 2010, ydego...@gmail.com wrote:
s'lam,
However, if you want to do heavy processing using [pix_...] objects
(and/or GridFlow and PDP)
PDP has always been (optionally) threaded since its inception ( thanks to tom
shouten ).
ah yes, thanks for the correction.
_ _ __ ___ _
On Fri, Apr 16, 2010 at 7:03 PM, Mathieu Bouchard wrote:
> On Fri, 16 Apr 2010, Jaime Oliver wrote:
>
> What do you mean by "some threading". I am particularly interested in the
>> input modules (cameras),
>>
>
> pthread is used in [pix_film], [pix_image], [pix_movie], and also in the
> V4L, V4L2
s'lam,
However, if you want to do heavy processing using [pix_...] objects
(and/or GridFlow and PDP)
PDP has always been (optionally) threaded since its inception ( thanks
to tom shouten ).
saludos,
sevy
___
Pd-list@iem.at mailing list
UNSUBSCRI
thanks...
J
On Fri, Apr 16, 2010 at 4:03 PM, Mathieu Bouchard wrote:
> On Fri, 16 Apr 2010, Jaime Oliver wrote:
>
> What do you mean by "some threading". I am particularly interested in the
>> input modules (cameras),
>>
>
> pthread is used in [pix_film], [pix_image], [pix_movie], and also in th
On Fri, 16 Apr 2010, Jaime Oliver wrote:
What do you mean by "some threading". I am particularly interested in
the input modules (cameras),
pthread is used in [pix_film], [pix_image], [pix_movie], and also in the
V4L, V4L2 and DV4L modules of [pix_video]. Pthreads may also be used
implicitly
What do you mean by "some threading". I am particularly interested in the
input modules (cameras), but in general to know what threading is being
accomplished there. perhaps a general blurb of where and how is this being
accomplished in gem.
furthermore, and this is a general question.
If there we
On Fri, 16 Apr 2010, Jaime Oliver wrote:
On Fri, Apr 16, 2010 at 1:55 PM, Mathieu Bouchard wrote:
there is some threading in the input/output modules of GEM, such as
cameras.
Could someone say a little bit more about this?
yeah, but *which* little bit more do you want ?
_ _ __ ___
On Fri, Apr 16, 2010 at 1:55 PM, Mathieu Bouchard wrote:
> there is some threading in the input/output modules of GEM, such as
> cameras.
>
Could someone say a little bit more about this?
J
--
Jaime E Oliver LR
www.jaimeoliver.pe
858 750 0924 (cel)
858 202 1522 (home)
9168 Regents Rd. Apt.
can someone tell me if one instance of pd (with gem) can use more than
one core on multi-core processor?
Beyond the new stuff with [pd~], there is also threading in
new versions of [soundfiler], and there is some threading in the
input/output modules of GEM, such as cameras.
There is also
On Apr 9, 2010, at 8:29 AM, Martin Peach wrote:
Matteo Sisti Sette wrote:
> I wonder if it would make sense
> to do the same with 2 pd instances doing audio, and exchange audio
> between them. Maybe I could try that with Jack.
Why isn't there a [netsend~] and a [netreceive~] object?
They are
Matteo Sisti Sette wrote:
> I wonder if it would make sense
> to do the same with 2 pd instances doing audio, and exchange audio
> between them. Maybe I could try that with Jack.
Why isn't there a [netsend~] and a [netreceive~] object?
They are in svn but don't get compiled in the nightly
> I wonder if it would make sense
> to do the same with 2 pd instances doing audio, and exchange audio
> between them. Maybe I could try that with Jack.
Why isn't there a [netsend~] and a [netreceive~] object?
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
What I have tried in the past is run one pd for audio and another one
for GEM stuff, which worked rather well. I wonder if it would make sense
to do the same with 2 pd instances doing audio, and exchange audio
between them. Maybe I could try that with Jack. But I think the latency
will be dou
>> thanks for the tip. I have no idea how to do that though.
>> I admit not having searched for very long (it's late), but i couldn't
>> find an easy peasy how-to disable frequency scaling,
>
> on ubuntu usually:
> $ sudo cpufreq-selector -g performance
>
> I guess this is the same as overriding
On Wed, 2010-04-07 at 02:02 +0200, tim vets wrote:
>
>
> 2010/4/6 Tim Blechmann
> > With my patch open i get these values (average):
> > cpu1 60% cpu2 60% cpu3 11% cpu4 2%
> > Then, when I open a pd~ patch:
> > cpu1 80% cpu2 80% cpu3 40% cpu4 3%
>
>
>> the average cpu load won't tell you a lot, since the cpu speed is usually
>> not constant, but may be modulated (adding some latency hotspots). in
>> general, i'd recommend to disable frequency scaling, turbo mode (for
>> nehalem
>> cpus) and smt, since it may confuse numbers and can increase th
On 2010-04-07 01:41, tim vets wrote:
> Hi Jon,
> i think it comes with the latest pd extended, at least i didn't explicitly
it comes with pd-vanilla(!) >=0.42
fmgasdr
IOhannes
smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at m
2010/4/6 Tim Blechmann
> > With my patch open i get these values (average):
> > cpu1 60% cpu2 60% cpu3 11% cpu4 2%
> > Then, when I open a pd~ patch:
> > cpu1 80% cpu2 80% cpu3 40% cpu4 3%
>
> the average cpu load won't tell you a lot, since the cpu speed is usually
> not constant, but may be mod
2010/4/6 Jon
> sorry if i missed the announcement, but where can i find this [pd~]
> object and some documentation?
> cheers
>
Hi Jon,
i think it comes with the latest pd extended, at least i didn't explicitly
install it and i do have it, so...
gr,
Tim
>
> On Tue, Apr 6, 2010 at 9:36 PM, Tim B
sorry if i missed the announcement, but where can i find this [pd~]
object and some documentation?
cheers
On Tue, Apr 6, 2010 at 9:36 PM, Tim Blechmann wrote:
>> With my patch open i get these values (average):
>> cpu1 60% cpu2 60% cpu3 11% cpu4 2%
>> Then, when I open a pd~ patch:
>> cpu1 80% c
> With my patch open i get these values (average):
> cpu1 60% cpu2 60% cpu3 11% cpu4 2%
> Then, when I open a pd~ patch:
> cpu1 80% cpu2 80% cpu3 40% cpu4 3%
the average cpu load won't tell you a lot, since the cpu speed is usually
not constant, but may be modulated (adding some latency hotspots)
2010/4/6 tim vets
>
>
> 2010/4/5 cyrille henry
>
>
>>
>> tim vets a écrit :
>>
>>
>>>
>>>tim vets a écrit :
>>>
>>>has anyone been using pd~ successfully ?
>>>
>>>yes
>>>
>>>I am trying it out, but i get very poor results.
>>>It seems like a patch loaded with pd~
2010/4/5 cyrille henry
>
>
> tim vets a écrit :
>
>
>>
>>tim vets a écrit :
>>
>>has anyone been using pd~ successfully ?
>>
>>yes
>>
>>I am trying it out, but i get very poor results.
>>It seems like a patch loaded with pd~ is a lot heavier than the
>>same
Thanks for the extensive description of the solution. I'm currently working
with on win7 but I'm osx user and this is the main reason why I'd like
to switch to pd+gem. I'll work on visual output only, so I won't do any dsp
(there is a plan for future but lets not think about it). also use
(this is a little OT respect to the thread)
> nicely enough, pd's graphical interface and the actual process,
> are separate threads,
The communication between the engine of Pd ("Pd") and the graphical
interface ("GUI") is not as efficient as you may expect it to be - at
least not as much as I
tim vets a écrit :
tim vets a écrit :
has anyone been using pd~ successfully ?
yes
I am trying it out, but i get very poor results.
It seems like a patch loaded with pd~ is a lot heavier than the
same loaded as a regular abstraction (DIO errors, see
>
> tim vets a écrit :
>
> has anyone been using pd~ successfully ?
>>
> yes
>
> I am trying it out, but i get very poor results.
>> It seems like a patch loaded with pd~ is a lot heavier than the same
>> loaded as a regular abstraction (DIO errors, see also my message "pd~ and
>> DIO errors").
>
>> it is the job of the scheduler of the operating system to assign the
>> processes to different cores. both parent and child process should
>> probably be pinned to different physical cores. not sure, whether miller
>> took that into account, though ...
>>
>
> What I have tried in the past is ru
tim vets a écrit :
has anyone been using pd~ successfully ?
yes
I am trying it out, but i get very poor results.
It seems like a patch loaded with pd~ is a lot heavier than the same
loaded as a regular abstraction (DIO errors, see also my message "pd~
and DIO errors").
I assumed it would ru
2010/4/5 Tim Blechmann
> > has anyone been using pd~ successfully ?
> > I am trying it out, but i get very poor results.
> > It seems like a patch loaded with pd~ is a lot heavier than the same
> > loaded as a regular abstraction (DIO errors, see also my message "pd~ and
> > DIO errors").
> > I a
has anyone been using pd~ successfully ?
I am trying it out, but i get very poor results.
It seems like a patch loaded with pd~ is a lot heavier than the same loaded
as a regular abstraction (DIO errors, see also my message "pd~ and DIO
errors").
I assumed it would run on another processor core...b
hey vedran,
pd~ is a way of opening another instance of pd from within a patch.
ideally you want gem and sound on separate instances (connected via udp, pd~
or some other way). each of these processes will use one processor.
nicely enough, pd's graphical interface and the actual process, are sep
On Mon, Apr 05, 2010 at 11:59:37AM +0200, vedran wrote:
> can someone tell me if one instance of pd (with gem) can use more than one
> core on multi-core processor?
If you use the new [pd~] object, the stuff you do inside of this may
run on the second core. Without this, Pd will only use one, IIR.
Hi!
can someone tell me if one instance of pd (with gem) can use more than one
core on multi-core processor?
.
vedran kolac
.
gTalk - vedran.ko...@gmail.com
..
34 matches
Mail list logo
