Binding one Itable to another: weird results

Mar 2, 2012 at 5:46pm

Binding one Itable to another: weird results

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…

– Pasted Max Patch, click to expand. –
#62093
Mar 5, 2012 at 1:01am

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)

– Pasted Max Patch, click to expand. –
#224286
Mar 5, 2012 at 4:12am

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–

– Pasted Max Patch, click to expand. –
#224287
Mar 5, 2012 at 8:36am

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….

#224288
Mar 5, 2012 at 11:52am

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.

#224289
Mar 6, 2012 at 5:56am

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…

Cheers.

#224290
Mar 6, 2012 at 7:02am

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:

– Pasted Max Patch, click to expand. –

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:

– Pasted Max Patch, click to expand. –

Just some thoughts…

#224291
Mar 6, 2012 at 9:21am

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)…

In any case, thanks again.

S.

#224292

You must be logged in to reply to this topic.