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
Hi
Rough approach : you could compare your array with the reference array by playing once from time to time the two simultaneously, sum (the first) and (the second *-1) and check with env~ that you still get nothing at the output.
my 5*10^-7 cents.
On 07/03/2012 09:55, Roman Haefeli wrote:
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2012-03-07 at 14:37 +0100, batinste wrote:
Hi
Rough approach : you could compare your array with the reference array by playing once from time to time the two simultaneously, sum (the first) and (the second *-1) and check with env~ that you still get nothing at the output.
my 5*10^-7 cents.
Yeah, that's what I meant with comparing them in the audio domain. It'll probably be a bit more efficient than the message domain comparison. I'll have to find out. Thanks for your suggestion.
Roman
On 07/03/2012 09:55, Roman Haefeli wrote:
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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
How about using [tabreceive~] with properly set blocksize in a subpatch? Never tried it though.
Pierre.
2012/3/7 Roman Haefeli reduzent@gmail.com
On Wed, 2012-03-07 at 14:37 +0100, batinste wrote:
Hi
Rough approach : you could compare your array with the reference array by playing once from time to time the two simultaneously, sum (the first) and (the second *-1) and check with env~ that you still get nothing at the output.
my 5*10^-7 cents.
Yeah, that's what I meant with comparing them in the audio domain. It'll probably be a bit more efficient than the message domain comparison. I'll have to find out. Thanks for your suggestion.
Roman
On 07/03/2012 09:55, Roman Haefeli wrote:
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@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Wed, 2012-03-07 at 15:00 +0100, Pierre Massat wrote:
How about using [tabreceive~] with properly set blocksize in a subpatch? Never tried it though.
From what I know, re-blocking also costs something. And you can re-block
only in powers of two, if I am not mistaken. Actually, [tabplay~] should work just fine without re-blocking and unlike [tabreceive~ ] I can re-trigger it in arbitrary intervals.
Roman
On Wed, 2012-03-07 at 14:50 +0100, Roman Haefeli wrote:
On Wed, 2012-03-07 at 14:37 +0100, batinste wrote:
Hi
Rough approach : you could compare your array with the reference array by playing once from time to time the two simultaneously, sum (the first) and (the second *-1) and check with env~ that you still get nothing at the output.
my 5*10^-7 cents.
Yeah, that's what I meant with comparing them in the audio domain. It'll probably be a bit more efficient than the message domain comparison. I'll have to find out. Thanks for your suggestion.
It seems, that this is the only workable way. First, I tried to scan the array at regular rates with an [until] counter. This is problematic, because if the array is big enough (I limited the size to a maximum of 2048) and depending on the current audio buffer size, this likely causes drop-outs. I then tried to spread the CPU time consumed over time with some kind of a slow [until], which doesn't fire immediately, but with short intervals. It turns out, although it prevents drop-outs, it's even a bigger CPU hog. Doing the comparison in the audio domain seems to be the smartest choice for now.
Roman
On 07/03/12 09:55, Roman Haefeli wrote:
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.
If the arrays are changed by [tabwrite] and/or [tabwrite~] couldn't you 'intercept' these writes (i.e. changes)? E.g. for messages with one or more [change] for signals depending on the logic of the patch, maybe [thershold~]... Unless I totally misunderstood your scenario.
Lorenzo.
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@iem.at mailing list UNSUBSCRIBE and account-management ->
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@gmail.com To: pd-list pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@gmail.com To: pd-list pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
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.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Roman Haefeli reduzent@gmail.com; pd-list pd-list@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@gmail.com To: pd-list pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On Wed, 2012-03-07 at 09:15 -0800, 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.
That's nice feature of Pd-l2ork.
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.
Yeah, you're totally right. If I'd build a self-enclosed patch, this wouldn't be an issue. The goal here is to create an abstraction able to keep an instance of a table in sync over network. I would like to avoid to design it in a way, that forces the user of the abstraction to actively notify it about changes. And since I also want to track manual edits, I need some kind of a watchdog anyway. So I still go for the watchdog solution, until the Pd-l2ork features make into Pd.
Roman
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Thursday, March 8, 2012 8:30 AM Subject: Re: [PD] [table] update notification
On Wed, 2012-03-07 at 09:15 -0800, 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.
That's nice feature of Pd-l2ork.
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.
Yeah, you're totally right. If I'd build a self-enclosed patch, this wouldn't be an issue. The goal here is to create an abstraction able to keep an instance of a table in sync over network. I would like to avoid to design it in a way, that forces the user of the abstraction to actively notify it about changes. And since I also want to track manual edits, I need some kind of a watchdog anyway. So I still go for the watchdog solution, until the Pd-l2ork features make into Pd.
Can you guarantee that [tabsend~] will never be sending to that array?
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you're open to using externals, [tabletool] has a "change" method that scans the memory of a table and reports any changed values and their indices out the two outlets.
http://williambrent.conflations.com/pages/research.html#tabletool
On Thu, Mar 8, 2012 at 12:38 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Thursday, March 8, 2012 8:30 AM Subject: Re: [PD] [table] update notification
On Wed, 2012-03-07 at 09:15 -0800, 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.
That's nice feature of Pd-l2ork.
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.
Yeah, you're totally right. If I'd build a self-enclosed patch, this wouldn't be an issue. The goal here is to create an abstraction able to keep an instance of a table in sync over network. I would like to avoid to design it in a way, that forces the user of the abstraction to actively notify it about changes. And since I also want to track manual edits, I need some kind of a watchdog anyway. So I still go for the watchdog solution, until the Pd-l2ork features make into Pd.
Can you guarantee that [tabsend~] will never be sending to that array?
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2012-03-08 at 09:38 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Thursday, March 8, 2012 8:30 AM Subject: Re: [PD] [table] update notification
On Wed, 2012-03-07 at 09:15 -0800, 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.
That's nice feature of Pd-l2ork.
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.
Yeah, you're totally right. If I'd build a self-enclosed patch, this wouldn't be an issue. The goal here is to create an abstraction able to keep an instance of a table in sync over network. I would like to avoid to design it in a way, that forces the user of the abstraction to actively notify it about changes. And since I also want to track manual edits, I need some kind of a watchdog anyway. So I still go for the watchdog solution, until the Pd-l2ork features make into Pd.
Can you guarantee that [tabsend~] will never be sending to that array?
Good point. The abstraction is actually designed and optimized to cover sporadic changes in parts of an array. It cannot and should not be used to transmit full audio streams over network. I put some arbitrary limits: Detection for changes occurs only every 100ms, the maximum size of the table to be synchronized is 2048 elements.
Roman
make a javascript /html5 canvas that sends out through javaudp messages about the data being edited. or better yet skip the htmlhavascript and just do it with java.
On Mon, Mar 12, 2012 at 9:19 AM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2012-03-08 at 09:38 -0800, Jonathan Wilkes wrote:
----- Original Message -----
From: Roman Haefeli reduzent@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Thursday, March 8, 2012 8:30 AM Subject: Re: [PD] [table] update notification
On Wed, 2012-03-07 at 09:15 -0800, 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.
That's nice feature of Pd-l2ork.
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.
Yeah, you're totally right. If I'd build a self-enclosed patch, this wouldn't be an issue. The goal here is to create an abstraction able to keep an instance of a table in sync over network. I would like to avoid to design it in a way, that forces the user of the abstraction to actively notify it about changes. And since I also want to track manual edits, I need some kind of a watchdog anyway. So I still go for the watchdog solution, until the Pd-l2ork features make into Pd.
Can you guarantee that [tabsend~] will never be sending to that array?
Good point. The abstraction is actually designed and optimized to cover sporadic changes in parts of an array. It cannot and should not be used to transmit full audio streams over network. I put some arbitrary limits: Detection for changes occurs only every 100ms, the maximum size of the table to be synchronized is 2048 elements.
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
batinste -
Billy Stiltner -
Hans-Christoph Steiner -
Jonathan Wilkes -
Lorenzo Sutton -
Pierre Massat -
Roman Haefeli -
William Brent