If you want to increase the gain of a single connection, using [mtx_*~], is
this more CPU friendly:
[0\
|
[element 1 1 $1(
|
|[osc~]
||
[mtx_*~]
than this:
[element 1 1 1(
|
|[osc~]
||
|[*~]
||
[mtx_*~]
I mean, does [mtx_*~] calculates the gain for a given connection
...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of i
go bananas
Sent: Sunday, July 14, 2013 4:01 AM
To: PD List
Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI objects in subpatches is optimal. but
what sort of effect do sliders. toggles, bangs, etc
--if it is not visible, its gui calls are ignored.
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf
Of i
go bananas
Sent: Sunday, July 14, 2013 4:01 AM
To: PD List
Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI objects in subpatches
On 07/15/2013 09:13 AM, Frank Barknecht wrote:
Hi,
I didn't test current Pd versions nor your fork, but up to 0.43 GUI
objects in subpatches or abstractions were a substantial and significant
CPU load when they are activated, even when invisible. So this is slow:
[r data]
|
[hsl ...]
|
I tried this with four versions of a subpatch, one with nothing (just an
inlet connected through to an outlet), one with a float, one with hslider, and
one with a number box (not number2, just control-3 number). Subtracting
out the control case, I sent 100 random numbers through and asked the
On 07/15/2013 05:40 PM, Miller Puckette wrote:
I tried this with four versions of a subpatch, one with nothing (just an
inlet connected through to an outlet), one with a float, one with hslider, and
one with a number box (not number2, just control-3 number). Subtracting
out the control case, I
On 07/15/2013 08:16 PM, Jonathan Wilkes wrote:
On 07/15/2013 05:40 PM, Miller Puckette wrote:
I tried this with four versions of a subpatch, one with nothing
(just an
inlet connected through to an outlet), one with a float, one with
hslider, and
one with a number box (not number2, just
I'm assuming of course that no GUI objects in subpatches is optimal. but
what sort of effect do sliders. toggles, bangs, etc have on CPU usage when
hidden in unopened subpatches?
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
AFAIK none--if it is not visible, its gui calls are ignored.
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of i
go bananas
Sent: Sunday, July 14, 2013 4:01 AM
To: PD List
Subject: [PD] CPU usage of GUI objects in subpatches
I'm assuming of course that no GUI
Hi all!
I'm developing an installation which currently uses six webcams
(Logitech Vision Pro, but tried also lots of other cameras). I'm using
Gem patches on Linux and OS X and realized that OS-X's CPU consumption
is much less than on linux. I made tests with a single webcam on Linux
and
ahh. yes, that's familiar. I've had that problem before, about 2
years ago, using an RME Fireface 400 with a Powerbook G4 on OSX 10.4
for multichannel performance. quite nasty.
I think I recall that it came down to Portaudio, so I think I fixed
the problem by using the Jack interface.
But
Hi list.
Im using a pd patch to play .ogg files all day long on a windows computer.
The files are played one after another reading them from a folder in the
computer.
At some point (let's say once or twice every 12 hours) the CPU usage of
pd.exe goes to the top and the file that is being played
hi list
im currently working on a patch that should be simple 4 channel mixer with 2
return channels for FX
the problem - pd cpu usage is roling around 10-15% but my gnome (and e-16)
system monitor shows 60-70 % and it is from my patch.
why there is this difference?
does pd load meter and dsp
13 matches
Mail list logo
