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 <[email protected]> > To: Jonathan Wilkes <[email protected]> > Cc: Roman Haefeli <[email protected]>; pd-list <[email protected]> > 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 <[email protected]> >>> To: pd-list <[email protected]> >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > ---------------------------------------------------------------------------- > > http://at.or.at/hans/ > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
