Basvlk

Spent half the weekend making an abstraction I'm not sure I'll use - I'm sure many of you will be familiar with it.

My purpose: an abstraction that allows patchers to check after loading if there's already a patcher open doing something similar. If there is, maybe it will close itself or maybe it will just display a warning, I don't know yet.

The idea is you place a copy of 'OneCopyControl' in your patcher and feed it with an ID string. the ID string indicates what the patcher it is place in is supposed to do. Eg I will [loadmess M4L_IO] for patchers that communicate with M4L. When such a patcher loads it will check if there are any other patchers running with the 'M4L_IO' and if there are either close or display a warning.

* the 'ID' can be freely set so it can be used for different kinds of patchers of which you only want 1 to be open at any one time: Eg only 1 M4L IO patch, only one midi monitoring patch, etc

* only the newly opened patch receives the bang when there is already a patcher in the same category running (if both the newly-opened and the already-open patcher receive a bang I would end up closing both)

It's far from elegant, any suggestions welcome!

in case the 'OneCopyControl' patcher doesn't come through right, here it is:

Spent half the weekend making an abstraction I'm not sure I'll use - I'm sure many of you will be familiar with it. 

Design criteria:
* the 'ID' can be freely set so it can be used for different kinds of patchers of which you only want 1 to be open at any one time: Eg only 1 M4L IO patch, only one midi monitoring patch, etc
* only the newly opened patch receives the bang when there is already a patcher in the same category running (if both the newly-opened and the already-open patcher receive a bang I would end up closing both)

in case the 'OneCopyControl' patcher doesn't come through right, here it is:


onecopycontrol-a-onecopy-for-any-patch-what-do-you-think

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.

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

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

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

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

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

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 

. So I looked in the forum and discovered a couple of solutions: this one and Peter Castine's 

. Funnily, I did almost the same patch as basvlk discussed in this topic.

Here is a patch, but I would be happy if some options were introduced in the original 

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.

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

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

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.

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. 

'OneCopyControl': a OneCopy for any patch. What do you think?