spectro

Seems like trying to bind one itable to another doesn't work as one might expect. Is there something I am missing or is this actually a bug? Thanks...

binding-one-itable-to-another-weird-results

No takers? Despite the flawed logic, I'll take it as a sign that this is a Bug!

(Method works as expected with multislider too)

No takers? Despite the flawed logic, I'll take it as a sign that this is a Bug! 

(Method works as expected with multislider too)


This is probably not the answer you're looking for-- I don't think it's a bug as such (maybe an oversight), but to work around it you could interleave the output of pattr with the indices itable expects-- 

Thanks for the input Terry. With that said, your clever workaround doesn't resolve the issue of modifying the 'primary' (left) table - which in my actual case exists in one of a number of identical bpatchers - via the second (right) table which is connected to the bound pattr. In essence, the primary table to needs to inform the editor table of it's state and the editor in turn needs to be able to modify/update the primary tables data.

This arrangement works well enough for multislider as illustrated in my (2nd) example patch.

It also seems highly counter-intuitive - to me at least - that pattrstorage data needs to be massaged before passing it on to the client object....

Thanks for the input Terry. With that said,  your clever workaround doesn't resolve the issue of modifying the 'primary' (left) table - which in my actual case exists in one of a number of identical bpatchers - via the second (right) table  which is connected to the bound pattr. In essence, the primary table to needs to inform the editor table of it's state and the editor in turn needs to be able to modify/update the primary tables data. 

This arrangement works well enough for multislider as illustrated in my (2nd) example patch. 

It also seems highly counter-intuitive - to me at least - that pattrstorage data needs to be massaged before passing it on to the client object....


Steve, I only just bothered to look the patch in your second post... agreed it's a counterintuitive 'inconsistency' with the way pattr works, and my workaround doesn't address your requirements.

Maybe a more useful workaround is to dump your 'edit' itable data into a coll which can be pointed to one of the other 'target' colls in your bpatchers using the refer message (coll acting as a buffer)-- sort of poor man's pattr system. You'd also need to alter the bpatcher's itable->coll reference when dumping that into the 'edit' itable, so you'd need two sets of coll buffers. it would be clumsy and tricky to manage, but should work.

Steve, I only just bothered to look the patch in your second post... agreed it's a counterintuitive 'inconsistency' with the way pattr works, and my workaround doesn't address your requirements. 

Maybe a more useful workaround is to dump your 'edit' itable data into a coll which can be pointed to one of the other 'target' colls in your bpatchers using the refer message  (coll acting as a buffer)-- sort of  poor man's pattr system.  You'd also need to alter the bpatcher's itable->coll reference when dumping that into the 'edit' itable, so you'd need two sets of coll buffers. it would be clumsy and tricky to manage, but should work.


Thanks again for the input Terry. As far as it goes, I will not bother with workarounds (for now) as the project to which this problem is related is not at the top of my to-do list. I will let this lie for the time being while intermittently conceiving of alternative strategies as a background task - but will most probably further hassle C74 about it anyhow...

Not sure if it is helpful in your case, but you might want to check out the 'refer' message to itable, and use a table object with an itable referring to the contents of an independent table:

Alternately, you might be able to do something like the following. One disadvantage (of possibly many) of this method is that when mousing in the second itable, the "master" itable only updates on mouse-up:

Alternately, you might be able to do something like the following.  One disadvantage (of possibly many) of this method is that when mousing in the second itable, the "master" itable only updates on mouse-up:

Thanks Ben, they're both useful and elegant workarounds (or methods - if they aren't technically workarounds ; )

Although the second method would be a bit easier for me to implement given a lot of the patching is in place, the 'refer' method in the first example - which I wasn't aware of! - seems more robust and the immediate updating on change would be better than update at mouse up.

Interesting aside: it appears that the table object also behaves similarly to itable when attempting to share its data. Is there some underlying reason for this behaviour in the table objects when attempting to share data via pattr? I still don't really get why this should be so (but yes, sometimes I miss the obvious)...

Although the second method would be a bit easier for me to implement given a lot of the patching is in place, the 'refer' method in the first example - which I wasn't aware of! - seems more robust and the immediate updating on change would be better than update at mouse up. 

Interesting aside: it appears that the table object also behaves similarly to itable when attempting to share its data.  Is there some underlying reason for this behaviour in the table objects when attempting to share data via pattr? I still don't really get why this should be so (but yes, sometimes I miss the obvious)...

Binding one Itable to another: weird results