Vincent Goudard

I was looking for a way to use pattr in different top-level patchers, and found out it was not possible currently (or am i wrong ?)

So, my question is : could that be a feature request that pattr family extends its scope to be able to cross top-level-patcher-borders ?

I was thinking it could be an attribute "@global_scope" on pattr objects, with default zero, so that it wouldn't break existing patches.

And if people think it is not a good idea, it is possible to know the good reason why ?

pattrstorage-global-scope-feature-request

ok, I found out about pattrmaker, but its philosophy seems somehow clumsy to me..

Let's say patcher "host.maxpat" hosts the pattrstorage.

When one load another patch (let's call it client.maxpat), pattrmaker behaviour would imply to instanciate as many pattr objects in the host as one would need for the client...

Which —correct me if I am wrong— would mean to script the creation of such pattr objects.

Is there a way to skip these pattr objects in the host and declare client's pattr directly to host's pattrstorage ?

Let's say patcher "host.maxpat" hosts the pattrstorage.
When one load another patch (let's call it client.maxpat), pattrmaker behaviour would imply to instanciate as many pattr objects in the host as one would need for the client...
Which —correct me if I am wrong— would mean to script the creation of such pattr objects.

Is there a way to skip these pattr objects in the host and declare client's pattr directly to host's pattrstorage ?


pattrstorage global scope (feature request)