Is it possible to change an object name dynamically with a message? I figured out how to call something using [namecanvas], but is it possible to change the name of an already existing object?
Cheers,
R
-
Changing object dynamically
-
i don't think so, but here's a little 'hack' that works for simple objects. could also be modified to deal with audio objects easily.
would need a bit more hacking to work with objects that have more than one inlet/ outlet
-
Ah, I think this will help a great deal. Thanks mod
Will post something back in a while. -
O.K. This works great. I have included a simple rename patch too. Wondering if there is a message you can send to save the patch to disk?
-
Clever! I've done some dynamic patching of audio abstractions before, but it never occurred to me that it could be encapsulated in an abstraction like that. This is going to make my life easier. Thanks!
I made a couple of modifications in the attached. You can use $0 in subpatch names, and you should here if you are going to have more than one of these objects. Also, when using [send~] and [receive~] there could be a problem with execution order, and you might find block-sized delays depending on the order of creation. So I tucked them in subpatches connected by dummy [inlet~]/[outlet~]s to force the order. And then there is the issue of patching in abstractions with lots of dsp objects. If you leave dsp on, it will recompile the dsp graph once for every single object, which may cause long dropouts. So this one will turn it off, patch in the abstraction, and turn it back on, so the graph is only compiled once. You still might get a short drop, but it won't be nearly as bad.
What part are you trying to save?
-
@.mmb said:
What part are you trying to save?
I was wondering if there is a message I can send to console that will save the patch to disk, in the same way I am able to change the name of the patch with a message i.e.
[;test rename $1(
And thanks for your mods. Will look at this tomorrow morning, but looks great!
-
Ah, okay. After renaming, do [; test menusave(, and it will save the patch with the new name in the same directory.
-
Kudos to you, kind sir.
-
maelstorm,
that route dsp thing doesn't seem to work. i think the problem is that when you turn dsp off with the message, that message also gets sent to the route object.
also, even if it were working, you still have the issue that if you create the dynamo~ object after turning dsp on (which would often be the case), then it doesn't know that dsp is on.if it were me, i'd just do dsp 1
-
Ah, you're right, thanks.
But, I don't really like the idea of objects turning dsp on for you when you don't want them to. So, I've attached an updated version that closes a [spigot] on the [r pd] when the [dsp 0( message is sent. I also made a subpatch that uses [bang~] to test if dsp is on to begin with.
I noticed there is a potential issue of missing [send~] errors when it first instantiates, so I made it default to a [*~ 1] object. You can also provide the default object as an argument, but it can only take the object name and one argument. I would normally use [dollarg] to get around this, but I thought I'd try to make it vanilla. I'm not sure if there's a better solution.
-
yeah, i guess i'm in a minority here, as i debated this point with andy obiwannabe too. i just don't see many occasions when you would do audio patching and NOT turn dsp on.
embedded devices would probably be one area where it would be quite important, but from recent and not so recent threads about that, it hardly seems as if embedding pd is a particular boom area (although i reckon it should be!)
-
Well, I now have a dynamic DSP chain per string. Works quite well (cf. screenshot).
