[PD] [table] update notification
Jonathan Wilkes
jancsika at yahoo.com
Wed Mar 7 21:38:55 CET 2012
If you're going to do that, please do it in a way that fixes the core of the
problem which is that a struct won't receive a notification when an array
element is moved with the mouse. (Then just have the [table] outlet hook
into that functionality to notify about changes.)
Otherwise you'll drive a further wedge between data structures and "Put"
menu arrays. (The biggest wedge is that one cannot read/write a data
structure array from [tabread~], etc.)
-Jonathan
----- Original Message -----
> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Roman Haefeli <reduzent at gmail.com>; pd-list <pd-list at iem.at>
> Sent: Wednesday, March 7, 2012 1:52 PM
> Subject: Re: [PD] [table] update notification
>
>
> That would be nice to have as an outlet from an array. Or perhaps the [table]
> object should have an outlet to get that info.
>
> .hc
>
> On Mar 7, 2012, at 12:15 PM, Jonathan Wilkes wrote:
>
>> Pd-l2ork has a feature where you can [r "arrayname_changed"]
>>
>> and you'll get a bang when the array is modified with the mouse.
>>
>> If you want a notification when using tabwrite/etc., well, when those
>>
>> objects receive a message to update the array, just manually send
>>
>> a bang to "arrayname_changed" when this happens.
>>
>> -Jonathan
>>
>>
>>
>> ----- Original Message -----
>>> From: Roman Haefeli <reduzent at gmail.com>
>>> To: pd-list <pd-list at iem.at>
>>> Cc:
>>> Sent: Wednesday, March 7, 2012 3:55 AM
>>> Subject: [PD] [table] update notification
>>>
>>> Hi all
>>>
>>> Is there a way to be reliably notified when a table/array changes? My
>>> hope is that I don't know of some hidden feature. Is there any?
>>>
>>> It's easy to catch messages sent to [s arrayname]. However,
> it's not so
>>> easy when data is written through [tabwrite arrayname] or [tabwrite~
>>> arrayname] or if the data is drawn manually.
>>>
>>> My current solution is quite a CPU hog: The whole table is scanned in
>>> periodic intervals and compared to a reference table, so that any
>>> difference will be caught. Of course, this solution comes with a
> latency
>>> (it's a trade-off between avoiding latency and saving CPU cycles).
>>> Probably, it could be a wee bit less CPU hungry to make the comparison
>>> in the audio domain instead of the message domain, but still it's
>>> work-around.
>>>
>>> Is there a real solution for this around?
>>>
>>> Roman
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ----------------------------------------------------------------------------
>
> http://at.or.at/hans/
>
More information about the Pd-list
mailing list