[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