Your patch doesn't seem to work for me, even if i correct the zl.slice part?

Attached is my onecopy replacement, mainly to get arround lions annoying auto-restore "features".

ID should be easy to do by adding one argument. Save as abstraction and connect to thispatcher in parent patch. Be careful when you're still working on you main patch - dispose can bite you.

grg - great. 'value' is new to me but it's definitely a lot more elegant and simple than my version. No idea why it wouldn't work - but irrelevant now as I'll make one similar to yours!

Ok so here's my new version, I can't believe how much simpler it is - thanks for the tip using 'value' grg. I am using 'wclose' instead of 'dispose'. If you made changes it will even ask you whether you want to close or not.

question... is it possible to set the value name from an inlet or message box? (I couldn't find it in the documentation)

Scripting maybe? Do you need it to be dynamically though? Else just use v #1 and give your ID as an argument.

Thanks grg -

scripting with 'thispatcher' cant do it as far as I can see. Javascript looks more promising but I don't know anything about it!

I posted my question on the java script separately.. https://cycling74.com/forums/request-for-a-favour-could-someone-help-me-with-this-javascript

hm ... either you didn't get the hint in my last post, or I fail to grasp what you are after. Try this: In the last patch you posted, replace [v OneCopy] with [v #1]. Save it as myonecopy. Then in your patches use

[myonecopy iPad-IO] | [thispatcher]

in the next patch use [myonecopy Launchpad-IO] etc.

yup - totally missed you hint and it is _exactly_ what I needed! searching the Max6 documentation for #1 doesn't give any results.. so I went back to Max5 and now I totally get it. I just got the one using scripting to work, but this definitely is more what I intended. Thanks grg!!

New version (so much simpler, I love it)

to be saved as an abstraction (I called it 'OneCopyControl')

It's use is for the following situation: when you have different patchers (maybe different versions, maybe different names even) of which you only need 1 running. Add the OneCopyControl to your patcher, give an ID as an argument, and connect a thispatcher object to the outlet. With the 'ID' you set a unique identifier: any patcher that opens with that same identifier will close itself because there is already a patcher running carrying out the same function.

I used it to make sure only one patcher listens to a specific udp port. Also if you have a patcher in your extras, but have the same function in a different patcher (or - when you open the 'extras' patcher from finder) - it will prevent from 2 copies running at the same time

Am I doing something silly? any comments welcome!

Having the same "opecopy" problem, I just built a patch that didn't really work: it doesn't in case the "one copy" patch is opened using a load message sent to pcontrol. So I looked in the forum and discovered a couple of solutions: this one and Peter Castine's lp.argus. Funnily, I did almost the same patch as basvlk discussed in this topic.

None of them do work in my case.

But I found a solution: a deferlow should be inserted before the wclose is sent. Here is a patch, but I would be happy if some options were introduced in the original onecopy to control its behavior.

What about the 'loadunique' message to [pcontrol]? Doesn't that effectively do what you want?

spectro, I didn't know that. And it even there since Max5!! Thanks a lot .

p

Updating lp.argus was broken by the change from Max 4 to 5.

Since what argus did relied on accessing data that Cycling '74 had changed the API to once (and, therefore, possibly again), I had been rather hoping that they would address the need for a means to prevent multiple instantiations of the same patcher from opening. I gather they have done so with the 'loadunique' message. Cool.

RIP, lp.argus.