[PD-dev] strange behavior of [metro 98.5] for [tabwrite~] into visual array
Jonathan Wilkes
jancsika at yahoo.com
Sat Oct 27 02:18:41 CEST 2012
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Lorenzo Sutton <lorenzofsutton at gmail.com>
> Cc: pd-dev at 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 at.or.at>
>>>>>>>> To: pd-dev at 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 at.or.at>
>>>>>>>>>>> To: pd-dev List <pd-dev at 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 at iem.at
>>>>>>>>>>>
> http://lists.puredata.info/listinfo/pd-dev
>>>>>>>>>>>
>>>>>>>>>>
> _______________________________________________
>>>>>>>>>> Pd-dev mailing list
>>>>>>>>>> Pd-dev at iem.at
>>>>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
> _______________________________________________
>>>>>>>>> Pd-dev mailing list
>>>>>>>>> Pd-dev at iem.at
>>>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pd-dev mailing list
>>>>>>>> Pd-dev at iem.at
>>>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pd-dev mailing list
>>>>>> Pd-dev at iem.at
>>>>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>> _______________________________________________
>>> Pd-dev mailing list
>>> Pd-dev at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
More information about the Pd-dev
mailing list