hi Hans,
I am attaching the patch. changing env~ parameter solved the problem. I
did, however, test what happens if the vumeter is in the top patch (rather
then inside the subpatch) and that doesn't create the same problem (i.e.
doing [env~] without giving it a large buffer size). So
there
be it would be the same.
Let me know.
-Original Message-
From: Oded Ben-Tal [mailto:o...@ccrma.stanford.edu]
Sent: Monday, December 10, 2012 6:37 AM
To: Hans-Christoph Steiner
Cc: Ivica Ico Bukvic; pd-list@iem.at
Subject: Re: [PD] graph on parent problem?
hi Hans,
I am attaching
Hi, I looked at your patch and it actually has nothing to do with the array
being displayed via gop but rather the VU meter. Namely, your patch reads
from the input and uses [env~] object to capture input values. What you
didn't do, however, is given env~ object's buffer size, and I think it may
My latest fixes should help with the problem you describe. Basically, the GUIs
will only request a redraw when there is an actual change. Oded, can you try
it with a Pd-extended 0.43.4 beta build? Or post the patch so I can try it.
Another optimization I've been thinking of is sending GUI
If I understood your problem correctly, this might be because pd redraws array
contents very inefficiently, so if you are constantly changing array contents
that can
prove quite cpu intensive.
I don't think that is the problem - I'm not changing the array just load
it once the play from it.
On 12/08/2012 04:18 AM, Oded Ben-Tal wrote:
If I understood your problem correctly, this might be because pd
redraws array
contents very inefficiently, so if you are constantly changing array
contents that can
prove quite cpu intensive.
I don't think that is the problem - I'm not changing
I have an array in a subpatch, when I applied graph-on-parent property to
the subpatch (to view the array which holds sound so could be fairly
large) Pd didn't like that. With dsp off it worked fine but when I turn
dsp on Pd becames unusably slow to react (sliders, etc.). I was able to
solve
If I understood your problem correctly, this might be because pd redraws
array contents very inefficiently, so if you are constantly changing array
contents that can prove quite cpu intensive. Similarly, moving such gop
patch requires complete redraw of all its contents. Pd-l2ork fixes latter
wel... I've been reporting similar issues, and it's getting worse with 043
versions. Definetly something worth debugging.
cheers
I have an array in a subpatch, when I applied graph-on-parent property to
the subpatch (to view the array which holds sound so could be fairly
large) Pd didn't
Hey Porres,
Have you tried a recent build? I fixed some the issues from your patch, so
LPVoc-help.pd now works. I'm still looking at the Brane-e issue where the
array doesn't draw while recording in 0.43.
.hc
On Dec 7, 2012, at 5:20 PM, Alexandre Torres Porres wrote:
wel... I've been
well, I hadn't, but yeah!! Thanks :D
let me know when you nail the remaining issue please
2012/12/8 Hans-Christoph Steiner h...@at.or.at
Hey Porres,
Have you tried a recent build? I fixed some the issues from your patch, so
LPVoc-help.pd now works. I'm still looking at the Brane-e issue
11 matches
Mail list logo
