here's an example of the problem i am facing, please download the zip files for main patch and sub-patcher.

essentially, my question is: how do you update the client list in pattrstorage if your patch uses scripting to create new sub-patchers with pattrs? is this even possible?

one thing i have noticed is that if i recreate the pattrstorage after dynamically creating subpatches then the clientlist updates... but that seems like it could throw up other problems

thanks

j

I think you forgot the [autopattr] in your pattrclone abstraction

hope this helps

léo

thanks léo,

i didnt think autopattr would be necessary, if i'm using a [named] pattr... but that doesnt seem to work anyway. i just tried it and i get error msg in max window:

object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj

I can reproduce it. The strange thing is that it works with named ui object, that's maybe a workaround. See example attached

note : pattr objects can not be seen by a parent pattrstorage if there's no autopattr object in the abstraction (that's not true for simple subpatches)

leo,

if it works with named ui objects, then its looking more and more like a bug... can someone from c74 verify?

thanks,

j

c74 support are looking into this, and have suggested sending: "subscribemode 0" to pattrstorage to update the clientlist. i have tested this and it works on my system.

j

Three years later, difference person, different place, but same error message, this time 18 times :

object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj object_attr_enforcelocal: could not enforce restore in newobj

If it's a bug, it's still in there ! :-)

Three more years later (because I was seeing this today)…

I was getting a number of these errors in one of my patchers. It was happening in an abstraction where there were a few [pattr] objects which had both an @initial value hardcoded into them as wells as connected [loadmess #1] boxes sending values into them.

The errors were cleaned up when I changed the @initial value to be #1 and removed the [loadmess] objects (which were redundant).

Here in 2019 - @subscribemode 0, had to be written into the pattrstorage.