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

    Nov 28 2011 | 12:06 am
    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.
    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)
    It's far from elegant, any suggestions welcome!
    in case the 'OneCopyControl' patcher doesn't come through right, here it is:

    • Nov 28 2011 | 11:05 pm
      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.
    • Nov 29 2011 | 12:45 am
      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!
    • Nov 29 2011 | 1:24 am
      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)
    • Nov 29 2011 | 8:42 am
      Scripting maybe? Do you need it to be dynamically though? Else just use v #1 and give your ID as an argument.
    • Nov 29 2011 | 1:28 pm
      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!
    • Nov 29 2011 | 7:37 pm
      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.
    • Nov 30 2011 | 12:09 am
      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!!
    • Nov 30 2011 | 12:21 am
      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!
    • Jun 05 2012 | 2:22 pm
      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.
    • Jun 05 2012 | 3:58 pm
      What about the 'loadunique' message to [pcontrol]? Doesn't that effectively do what you want?
    • Jun 05 2012 | 4:10 pm
      spectro, I didn't know that. And it even there since Max5!! Thanks a lot .
    • Jun 07 2012 | 1:03 pm
      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.