Hello,

I want to call multiple instances of an abstraction AND I want to be able to change the contents of each instance dynamically using broadcast messages stored within each instance.

I'm sending the usual connect and object messages to the patch using a [send] object.

• [s pd-pdpatchname] (is there a way to make this local / unique? I tried the usual $0-). Perhaps I can use some other format to recreate the patch from within?

The issue here, of course, is that when I change the configuration of one instance this way, it changes the configuration in all instances (because it's using a global patch name).

There may not be a way around this giving this awkward approach but I thought I'd reach out to see what you good folks think!

Screen shots attached.

All the best,

Ricky

@ricky Hello Ricky,
I don't know if it is the best or easiest way to do what you want.
In the past I have used an "is the message for me" test in my abstractions..... so.... if you add a unique sequential number to your abstractions on creation........... [obj x y Object z( ..... where z = 1...n then you can use z in your [s message_z] (via $1) to talk to only one abstraction from your "mother" patch. $0 is not useful, as it is unpredictable.
z does not have to be a number, it could be a name called from a list, but that is for another day!
Here is a small example (which I don't think you need - but it could be useful for some-one else)... open abstraction-help.pd, create your abstractions, and then test.
talk_abstraction.zip
David

Hi David,

Thanks for the patches. Nice idea! I guess it could work this way, potentially. From a design standpoint, I don't want to rely on a 'mother' patch, as such, but I will explore the idea of adding a unique id on creation. The kicker is the setting the array / table name for tabread~ for each unique instance. Older settings are overwritten when multiple instances of the abstraction are called.

The other option is to set buffers outside of the abstractions and define them as an argument, which I wanted to avoid initially, but I guess that's not a bad solution either. Or I could include one buffer inside of each grain voice but that seems like overkill. Thanks for your idea!

All the best,

Ricky

@ricky Hello again,
It's a bit of a head-twist, but you can get the $1 of each abstraction into its array as well so that each [tabplay~] is also unique and can be addressed:
Play.zip
David.

@whale-av Definitely a nice alternative. Thanks, Dave.