pattrstorage question: adding clients dynamically?

justin

i have a pattrstorage in my main patch, and i'm dynamically creating copies of a patch with a pattr inside...
only problem is the clientlist doesnt update in pattrstorage. is there a message i have missed which will update / rescan available clients?

thanks

justin

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

367.scripting+pattr.zip

zip

Léopold Frey

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

hope this helps

léo

justin

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:

Léopold Frey

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)

373.scripting+pattr.zip

zip

justin

leo,

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

thanks,

justin

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.

Glennzone

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 ! :-)

tyler mazaika

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

Wetterberg

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