Exit Only

I'm encountering inconsistent behavior from pattrhub when trying to recall data from a poly~ patch. Sometimes when giving the scripting name of an object inside a poly~ voice, pattrhub will only return the value of the first poly~ voice.

for example, if I have an number box in the poly patch with the scripting name numBox, which stores the voice number from thispoly... and poly~ is named poly~, then sending the message

poly~.4::numBox should return 4, but instead returns 1.

Also, I've found that pattrhub will respond to a message like poly~.4::numBox in a large patch that im working on. However, in the smaller example patch I made pattrhub needs poly~.4 as its patcher argument and then it will respond to 'getnumBox'

I know this might be confusion but I think my example illustrates it.

I realize that patterstorage works the way I expect it to but I'd rather use pattrhub since I'm not looking for all the extra functionality of pattrstorage in my current project.

I attached the patch as a zip because I find copying, pasting, saving, etc a lot more troublesome when dealing with subpatches in a forum example.

I'm encountering inconsistent behavior from pattrhub when trying to recall data from a poly~ patch. Sometimes when giving the scripting name of an object inside a poly~ voice, pattrhub will only return the value of the first poly~ voice. 

poly~.4::numBox should return 4, but instead returns 1. 

I know this might be confusion but I think my example illustrates it. 

I realize that patterstorage works the way I expect it to but I'd rather use pattrhub since I'm not looking for all the extra functionality of pattrstorage in my current project. 

I attached the patch as a zip because I find copying, pasting, saving, etc a lot more troublesome when dealing with subpatches in a forum example. 

pattrhub-bug

also, note that while the 'getnumBox' part of the example shows an output of 'numBox 4' that result actually stemmed from when I reloaded the poly, and then saved the patch without clearing the message box. If you click on 'getnumBox' it will output 'numBox 1' which is incorrect.

also, i'm running Max 5 on OS10.5.4 1.83Ghz Intel Core duo MBP

also, note that while the 'getnumBox' part of the example shows an output of 'numBox 4' that result actually stemmed from when I reloaded the poly, and then saved the patch without clearing the message box. If you click on 'getnumBox' it will output 'numBox 1' which is incorrect. 

also, i'm running Max 5 on OS10.5.4 1.83Ghz Intel Core duo MBP


Just wanted to give this thread the Monday morning bump.

Thanks for the report. This bug has been fixed for the next release.

Thanks for the fix. However, there is still a problem in the example patch I posted.

The second pattrhub example where gettest.4::numBox is sent to the pattrhub, it is still not giving me the value and just passing the input out the left outlet. When the same message is sent to pattrstorage, it behaves correctly.

I can work around this by sending the message 'patcher test.4' first and then 'getnumBox' but I just wanted to point this out.

Anyway, the update looks great. I'm really excited about the whole rewire/transport thing!

Thanks for the fix. However, there is still a problem in the example patch I posted.  

The second pattrhub example where gettest.4::numBox is sent to the pattrhub, it is still not giving me the value and just passing the input out the left outlet. When the same message is sent to pattrstorage, it behaves correctly. 

I can work around this by sending the message 'patcher test.4' first and then 'getnumBox' but I just wanted to point this out. 

Anyway, the update looks great. I'm really excited about the whole rewire/transport thing!


one more thing, since the upgrade to 5.0.5, pattrhub no longer responds to the parent address, as in the 'more' subpatcher in the help file. The attribute 'patcher parent::pattrhub_example' doesn't work and the patcher attribute just reverts to 'this' 

one more thing, since the upgrade to 5.0.5, pattrhub no longer responds to the parent address, as in the 'more' subpatcher in the help file.  The attribute 'patcher parent::pattrhub_example' doesn't work and the patcher attribute just reverts to 'this' 


Thanks for the reports. Looks like my 'fix' broke some other stuff. Sorry about that. On the bright side, the damage appears to be limited to pattrhub, although the fix will be in the application itself, so I'm afraid you'll have to wait until the release of 5.0.6 for relief.

OK, the second 'bug' (where gettest.4::numBox doesn't work when sent to pattrhub) is not a bug -- pattrhub doesn't resolve patcher paths like that. The getNNN syntax is only useful for retrieving the data of objects 'tracked' by the pattrhub. This has been true since pattrhub was born -- if it ever worked, _that_ was a bug.

I've fixed the parent-resolution bug for the next release.

pattrhub bug