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
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
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 hans@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
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.
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
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@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
Really? You see the array getting updated constantly? I've tried two computers and both where the same.
.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 hans@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
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 hans@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
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 hans@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 hans@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
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 hans@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 hans@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
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 hans@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 hans@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
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 hans@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 hans@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
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 hans@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 hans@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
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 hans@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 hans@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
I think everyone agrees with that, but its a big job and someone needs to do that work. You can help with that. Take on a piece that most interests you and try to make it better. Or try profiling various parts to figure out what is causing the slowness.
I've had good luck with sticking print statements with single letters to represent different stages of something. You can do that by adding this to the C code:
fprintf(stderr, "B");
Then run Pd like: pd -stderr. With this you then set a log of what's happening and you can narrow down the problem. For example, with the array redrawing stopping, I was able to see that its not in the GUI at all, since pd stops sending GUI commands.
.hc
On Oct 26, 2012, at 2:36 PM, Lorenzo Sutton wrote:
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 hans@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 hans@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
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Lorenzo Sutton lorenzofsutton@gmail.com Cc: pd-dev@iem.at Sent: Friday, October 26, 2012 4:42 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
I think everyone agrees with that, but its a big job and someone needs to do that work.
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that "just make the gui get out of the way for the sound" is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
You can help with that. Take on a piece that most interests you and try to make it better. Or try profiling various parts to figure out what is causing the slowness.
I've had good luck with sticking print statements with single letters to represent different stages of something. You can do that by adding this to the C code:
fprintf(stderr, "B");
Then run Pd like: pd -stderr. With this you then set a log of what's happening and you can narrow down the problem. For example, with the array redrawing stopping, I was able to see that its not in the GUI at all, since pd stops sending GUI commands.
.hc
On Oct 26, 2012, at 2:36 PM, Lorenzo Sutton wrote:
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 hans@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
>>>>> 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
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that "just make the gui get out of the way for the sound" is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1]Â Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and you're got it.
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
cheers M
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; Lorenzo Sutton lorenzofsutton@gmail.com; "pd-dev@iem.at" pd-dev@iem.at Sent: Sunday, October 28, 2012 4:10 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you
certainly
won't get a consensus that "just make the gui get out of the way
for the sound"
is the right approach. In fact for anything that is handling user input
through
the GUI you'd better make sure the GUI responds when it's supposed
to,
otherwise it _will_ appear to be broken from the standpoint of the user.
Just
look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from
becoming
sluggish. You might say this is just the visual bias in our culture, but
the more
significant factor is that a light switch that reacts to the force from
your finger
one second after you flip it is no longer a switch-- it's a physical
anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and you're got it.
And how do I set the right size for the array?
-Jonathan
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
cheers M
I don't know any good way to do that. But in general memory alocation also should be done in advance if you want robust real-time behavior, so in practice I'd make a list of the lengths of each readable soundfile in advance.
cheers Miller
[1]Â Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and you're got it.
And how do I set the right size for the array?
-Jonathan
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
cheers M
On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote:
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that "just make the gui get out of the way for the sound" is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and you're got it.
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority.
.hc
On Oct 28, 2012, at 11:34 PM, Hans-Christoph Steiner wrote:
On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote:
Why not use the same throttling mechanism Miller put for data structures for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you certainly won't get a consensus that "just make the gui get out of the way for the sound" is the right approach. In fact for anything that is handling user input through the GUI you'd better make sure the GUI responds when it's supposed to, otherwise it _will_ appear to be broken from the standpoint of the user. Just look at the history of video games-- game developers are willing to remove entire voices at will in the audio in order to keep the interface from becoming sluggish. You might say this is just the visual bias in our culture, but the more significant factor is that a light switch that reacts to the force from your finger one second after you flip it is no longer a switch-- it's a physical anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1] Hm... rather than threaded... what if you could set a flag that tells [soundfiler] the maximum amount of the soundfile to process every block? Or maybe have an object called [soundfiler~], where you can give it an arg to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and you're got it.
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority.
This is a potential way to do it: http://tcl-mmap.sourceforge.net/
.hc
But the question of how to smoothly update table graphics without messing up real-time behavior is still wode open.
Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority.
.hc
The difficulty with that is that you'd have to obtain a lock on the table in order to safely read its contents from the GUI layer - and then, the real-time layer could block on the lock and you'd get occasional hiccups in performance.
By the time you've made the interface lock-free, as far as I can see, you're retty much stuck with a fifo of some type. Admittedly, the way Pd and Tk handle the fifos is currently laughably inefficint - but that's incrementally fixable, whereas getting table updates to work well with a FIFO at all is more fundamental I think.
cheers M
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Miller Puckette msp@ucsd.edu Cc: Jonathan Wilkes jancsika@yahoo.com; Lorenzo Sutton lorenzofsutton@gmail.com; "pd-dev@iem.at" pd-dev@iem.at Sent: Sunday, October 28, 2012 11:34 PM Subject: Re: [PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
On Oct 28, 2012, at 4:10 PM, Miller Puckette wrote:
Why not use the same throttling mechanism Miller put for data
structures
for iemguis and see if it's suitable?
I think what you'll find is that this is a complex problem, and you
certainly
won't get a consensus that "just make the gui get out of the
way for the sound"
is the right approach. In fact for anything that is handling user
input through
the GUI you'd better make sure the GUI responds when it's
supposed to,
otherwise it _will_ appear to be broken from the standpoint of the
user. Just
look at the history of video games-- game developers are willing to
remove
entire voices at will in the audio in order to keep the interface from
becoming
sluggish. You might say this is just the visual bias in our culture,
but the more
significant factor is that a light switch that reacts to the force from
your finger
one second after you flip it is no longer a switch-- it's a
physical anomaly.
Anyway, I think the problem is often on the c side instead of the tk side. If you load a 20sec sample into an array while dsp is on and soundfiler isn't threaded, what do you really expect to happen?[1]
-Jonathan
[1] Hm... rather than threaded... what if you could set a flag that
tells
[soundfiler] the maximum amount of the soundfile to process every
block?
Or maybe have an object called [soundfiler~], where you can give it an
arg
to set the number of samples to be loaded every block?
That's what readsf~ does... just dump the output into a tabwrite~ and
you're
got it.
But the question of how to smoothly update table graphics without messing
up
real-time behavior is still wode open.
Ideally there would be some way of sharing the table memory with the GUI process. Then the GUI process would just read that table using the clock of the screen refresh, at something like 60Hz, and handling the drawing itself. Then the DSP code could be totally ignorant of the drawing. That would also make it easy to set the DSP processing priority higher than the redrawing priority.
.hc
I'm about to add a ttk::progressbar to my search plugin and maybe this kludge relates somehow to the array not updating in the GUI:
Looks like the hack here is that you build your own recursive event loop so that you can set the clock as needed for the GUI animation junk. For the progress bar, I'm just thinking about dividing the total number of files to be searched by 8, search the files in each chunk asap, and throttle in between each chunk enough to draw the next section of the progress bar. That way I'm only adding 8 * throttle period to the total search time which should be insignificant. (It only takes 3-4 seconds to do a single-word search through all the pd-extended docs/libs.)
The part that might relate to array-redrawing is that if I didn't use this kludge and instead had a foreach loop, I'd be guaranteed that the progress bar would only redraw _after_ the entire search process was finished. I'm guessing that's exactly what's happening with the array-- you're hitting a wall where you're sending so many damn drawing instructions to tk that it no longer has any idle time to draw anything.
For example-- notice that when you turn off the metro tk finally decides it's time to draw something.
I have a hard time believing modern gui toolkits would end up forcing workarounds like that, even in light of how terribly inefficient Pd is about sending loads of data back and forth. Does Qt give the dev tools to refresh the screen then spend a page and a half in the wiki guiding users never to use it because it's buggy (like [update] )?
-Jonathan
-
Hans-Christoph Steiner -
Jonathan Wilkes -
Lorenzo Sutton -
Miller Puckette