I'm not sure if this is relevant but following this thread triggered
something I'm thinking of since a while and was a little sceptical to
share anyway here goes...
I really think all those parts of the gui which have an impact on
performance (e.g. having lots of sliders or big arrays update and you
get clicks and glitches in the audio) should be redone.
Personally I don't care about "aesthetics" actually I always like the
way Pd looks. What I find frustrating is when I can't use or am limited
in using the gui because it has an impact on audio performance.
Does this make any sense? Is it agreeable?
Lorenzo.
On 25/10/12 23:13, Miller Puckette wrote:
The lines,
if (phase >= endphase)
{
tabwrite_tilde_redraw(x);
phase = 0x7fffffff;
}
fix it so that a tabwrite~ only redraws the array once it's completely
overwritten.
In my view, the updates should be split into chunks (not made into one long
message for the entire table) and they should "scan" across the table at
some controlled rate. I don't know how the rate should be chosen though
(and it might want to depend on what other graphical activity there is.)
It gets ugly because when the array is drawn as "points" they're not tagged
in the right way to allow partial redraws.
cheers
Miller
On Thu, Oct 25, 2012 at 05:04:22PM -0400, Hans-Christoph Steiner wrote:
My brain is already halfway in it, can you give me some pointers on where to
look? Do you know what code is stopping the updates?
.hc
On 10/25/2012 04:56 PM, Miller Puckette wrote:
THe whole edifice needs to be reworked I'm afraid... but it's a big project
which I haven't yet been able to get started on.
cheers
M
On Thu, Oct 25, 2012 at 04:37:53PM -0400, Hans-Christoph Steiner wrote:
I can see a reason to rate limit the updates, but totally stopping them seems
really bad to me. Anyone disagree?
.hc
On 10/25/2012 03:56 PM, Jonathan Wilkes wrote:
At arraysize = 4352 I get animation for the full range of the slider
At arraysize = 4353 I get frozen array for full range
Of course if I try to move the number box down with arraysize at 4352
I get freezes.
Changing to polygons or points doesn't change it.
In general there's nothing special about the98.5 rate. For arraysize=n
there's obviously an update rate x under which it no longer sends updates,
and I guess for the size you chose that's it.
How does other software like Supercllider deal with scope updates?
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner <h...@at.or.at>
To: pd-dev@iem.at
Cc:
Sent: Thursday, October 25, 2012 2:28 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into
visual array
OK, this is strange. Lorenzo's patch works fine on mine too, down to 2ms.
But my patch still has the same 98.5ms issue. Its attached again, if you could
try it.
.hc
On 10/25/2012 06:21 AM, Lorenzo Sutton wrote:
Same here, 0.43.4-extended-20121022 - Wheezy (guess it's the most
recent
extended autobuild?)
The attached patch works all the way down to 2 msec, of course with various
'artefacts'.
Lorenzo
On 25/10/12 04:28, Jonathan Wilkes wrote:
It updates fine with 0.43.1-extended-20120815 on Wheezy, even at [metro
2]
although I
start getting sluggishness with that setting.
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner <h...@at.or.at>
To: pd-dev List <pd-dev@iem.at>
Cc:
Sent: Wednesday, October 24, 2012 9:33 PM
Subject: Re: [PD-dev] strange behavior of [metro 98.5] for
[tabwrite~] into
visual array
No ideas on this one? It is a serious bug since it means that
arrays stop
being drawn at all when banged often than 100ms.
.hc
On 10/08/2012 12:26 PM, Hans-Christoph Steiner wrote:
I've noticed that if you bang a [tabwrite~ array1] more
often than
about 100ms, the array that its writing to will not send updates to
the
GUI. It
seems that its a kind of a fade out with [metro 100] seems to send
all
updates,
[metro 98.8] send some updates and [metro 95] sends basically none.
Any ideas what could be causing this? I didn't see
anything. This
happens on 0.42.5, 0.43.4 and pure-data.git master. Attached is
patch to
demonstrate this.
.hc
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
