collective back to patch??


    Apr 28 2006 | 3:00 pm
    hi
    a stupid thing - years ago i build a max patch into a collective (for
    some other musician to play it), now i want to use the same _kind_ of
    patch
    but of course the original patch is gone... I have the collective only....
    how could I open the collective as a patch?? (i of course have max,
    latest version - and i work on a MAC)
    many thanks
    kasper
    --
    Kasper T. Toeplitz
    noise, composition, bass, computer

    • Apr 28 2006 | 3:34 pm
      i don't know if this will be of any help, but there used to be a
      patch that was part of nato (or one of the other antiorp/nn packages)
      that did this successfully. I think that it may have only shown the
      insides of the patch, rather than make it editable, but even that
      would be of help. it would, of course, have been written in OS9.
      Perhaps someone has a copy, or knows more?
      hth
      David
    • Apr 28 2006 | 3:44 pm
      well, i can SEE what's in the patch (beside, i have build it so
      understanging the logic is easy for me) it's that one does almost
      what i want, instead of re-patching a new one..
      thanks
      kasper
    • Apr 28 2006 | 6:58 pm
      dzien dobry Kasper !
      You know, you don't always have to make a collective when you give a
      patcher to a musician that uses RunTime to
      make it work.
      A simple patch in .pat works just as well !!!
      The only thing is to launch the runtime and then open the patcher for
      runtime (in this order) otherwise the computer
      won't know which app to open the patcher with by default.
      As for me, i usualy do not even make collectives, i just give the patches
      and that's all.
      Standalone is an other story but this is not the subject.
      Cheers.
      Seb.Tworowski
    • Apr 28 2006 | 8:16 pm
      On 28-Apr-2006, at 20:58, tworowski.sebastien@laposte.net wrote:
      > A simple patch in .pat works just as well !!!
      This assumes the person you've given the patch to has all the
      externals needed.
      Unless you never, ever, no-fingers-crossed-and-hope-to-die, never use
      external objects outside the standard distrbution, that assumption is
      simply not tenable. And there are simply too many useful 3rd party
      objects out in the world.
      I have been involved in too many concerts where a performer comes,
      brings a patch, borrows a computer with Max/MSP and... "error:
      foo.baz not found", at which point all hell breaks loose and the Tech
      Guy/Gal has to go searching for that critical stray object.
      Inevitably, it's not listed on maxobjects and the original source
      site has gone down.
      Standalones are the most robust solution if you're going to perform a
      piece on someone else's computer. Particularly a computer that
      doesn't have a Max license!
      Of course, loosing the original patch is unfortunate, too. Bonne
      chance, Kasper!
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Apr 29 2006 | 9:41 am
      �right, and not only for externals but abstractions as well and one
      reason i have been hoping for some kind of "save as collection" in a
      way that max saves all externals, abstraction, jpgs, texts files and
      what not used in the patch into a subfolderstructure.
      similar to lives "save as selfcontained" ...
      this would really help moving projects as well as for backup.
      t.
    • Apr 29 2006 | 11:49 am
      That correct Peter but it's true that as much as i can, i try not to use
      third party externals.
      Usualy those externals are not kept up to date in a long time and it's not
      really reliable to use them when you can
      use only the externals that come along with max-msp.
      I prefer to spend (if i have time) two days remaking an object as a
      sub-patcher than to use a third party external.
      Also, as you said, standalone are much more reliable i think.
      Anyway...
      Cheers.
    • Apr 29 2006 | 11:52 am
      It can't be done automatically, since many objects open files
      dynamically.
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • Apr 29 2006 | 1:32 pm
      Mileage varies. Peter Elsea arguably sets the record for longest-
      lifespan of 3rd party externals regularly updated, and there are many
      other reliable sources. OTOH, there are some externals that came with
      the original Max that have long since been orphaned. Very few,
      exceptional, but abandoned nonetheless.
      And there are some things that are simply far easier to do far more
      efficiently with an external.
      I have posted before that Litter Power RNGs perform 10-20 faster than
      the equivalent patchers (yes, bernie and stu and norm &c. all began
      life as patchers). Someone once posted a patcher that generated
      variable-color noise, but it clocked in at 50% CPU on my Mac at the
      time. Compare that to about 2% for lp.pvvv~, which fills the same
      purpose.
      If the standard external distribution fills your needs, that's fine.
      But don't assume they are all things for all people. They ain't.
      -- P.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • May 01 2006 | 8:39 am
      I don't see evidence for this statement. If it can be collected into a
      collective, it is possible to collect the same into a folder. I'd love
      it, that would make source code distribution a lot easier. For the
      handfull of dynamically loaded files I am usually aware of. Its exactly
      those which I would have to include into a collective/plug/standalone as
      well.
      I'd definitely would welcome a "build as distribution" feature (I
      requested it some time ago myself). Should not be too difficult to
      enhance the existing build structure, just one more choice, the creation
      of a folder and copying all the involved 3rd party externals and all
      subpatchers and nondynamically loaded files (colls, pattr.xml...)...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • May 01 2006 | 9:59 am
      Yes Yes Yes ! It worths what it worths, but I second that.
      Julien.
    • May 01 2006 | 2:39 pm
      I have been working on a python script that parses the text of a max
      patcher and collects all of its dependencies. It is not ready for
      distribution yet (and I'm crunched for time to work on it right now),
      but if anyone would like to test it or hack on it, contact me off list.
      -charlie
    • May 02 2006 | 10:01 pm
      > > It can't be done automatically, since many objects open files dynamically.
      >
      > I don't see evidence for this statement. If it can be collected into a
      > collective, it is possible to collect the same into a folder.
      nah, the "build collective" task has no chance
      to know what picturefile a pictcntrl object is
      pointing too unless we build some path-output
      unction into every object ...
      I'd love
      > it, that would make source code distribution a lot easier.
      i could agree if you would be right about the idea
      that a collectives can be called the "source" of the
      project. :)
      paths to stuff has been my problem for a long time,
      but in between i am very organized, and sharing sources
      is really easy when you always make one folder only
      per project and only work inside the search path.
      simply zip the folder, share it, and instruct your
      buddy to unzip it and put it into his search path.
      using funky unique names is also a must for sharing
      sources; avoid filenames like "knob.pct" or "patch.pat"
      not sure if that works when you are connected via a
      french provider.
      -110 (connected via the 110.110.110.110 gateway)
    • May 03 2006 | 4:47 am
      I would be aware that I need the sound files (I'd need to include them
      into a standalone for example as well)
      There is no need to include sfplay~ as its part of the standard
      distribution. But if that construction is inside a "MyPlayerAbstraction"
      then I need to include "MyPlayerAbstraction".
      When I give a patch distribution to a friend, I never ever came across
      missing media, but missing an abstraction or external somewhere hidden
      in the patcher hirarchy is almost always a problem. I would have to load
      the patch at least twice, list all missing objects, include them load it
      again until there are no missing objects anymore.
      As this might be somwhere in a different part of the world...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • May 03 2006 | 5:57 am
      Roman Thilenius wrote:
      > nah, the "build collective" task has no chance to know what
      > picturefile a pictcntrl object is pointing too unless we build some
      > path-output unction into every object ...
      this proves you wrong, as you see, the name of the pict is in there,
      alex.pct has to be included into the distribution...
      Paths are never the same on different machines, they are of no relevance
      in a distribution.
      > i could agree if you would be right about the idea that a collectives
      > can be called the "source" of the project. :)
      Never said that, the thread drifted to something else...
      > sharing sources is really easy when you always make one folder only
      > per project and only work inside the search path. simply zip the
      > folder, share it, and instruct your buddy to unzip it and put it into
      > his search path.
      And then she's missing all the 3rd party objects including 110...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • May 03 2006 | 9:27 am
      On 3 May 2006, at 05:47, Stefan Tiedje wrote:
      > There is no need to include sfplay~ as its part of the standard
      > distribution. But if that construction is inside a
      > "MyPlayerAbstraction" then I need to include "MyPlayerAbstraction".
      Butbutbut... the collective builder does all this automatically, via
      a depth-first search?
      Doesn't it?
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • May 03 2006 | 7:22 pm
      Nick Rothwell wrote:
      > Butbutbut... the collective builder does all this automatically, via a
      > depth-first search?
      >
      > Doesn't it?
      Yes, that was my first argument, if the collective builder does it, it
      can be done... (Don't know how its done, depth-first or whatever...)
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • May 03 2006 | 10:22 pm
      > #P window clipboard copytext "#P user pictctrl 129 115 228 162 alex.pct
      > this proves you wrong, as you see, the name of the pict is in there,
      > alex.pct has to be included into the distribution...
      well ok .. so the build collective task can know
      that the picture is in our search path ... but
      what if you put this picture into the search
      path after you launched max the last time?
      the runtime does not always know where the picture
      is, you could have moved it within the search path ...
      when i think about it, the max window also lists
      all sources of the patch, isnt it.
      > > sharing sources is really easy when you always make one folder only
      > > per project and
      > And then she's missing all the 3rd party objects
      including 110...
      ... and there is no support for the 110s. OMG!
      like i said, i do not think that is the idea of
      "sharing source" when including some 110 object
      into a collective.
      you are right of course that automatic inclusion
      would be the only safe way not to forget anything.
      but when i use abstractions i also copy them into
      my project folder, and rename them to a unique
      project releated filename, not an issue.
      after a while i have 03-110.foo, 04-110.foo, and
      05-110.foo in my search path, but the good thing
      about this is that i can change every copies content
      when necessary.
      who is alex? how does she look like?
    • May 08 2006 | 9:43 am
      Roman Thilenius wrote:
      > who is alex? how does she look like?
      Its a cat, look at pictctrl.help...
      (should be in your search path... ;-)
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      Stefan Tiedje
      Klanggestalter
      Electronic Composition
      &
      Improvisation
      /~~~~~
      \ /|() ()|
      ))))) )| | |( \
      /// _/)/ )))))
      ___/ ///
      -------------------------x----
      --_____-----------|-----------
      --(_|_ ----|-----|-----()----
      -- _|_)----|-----()-----------
      ----------()------------x-----
      14, Av. Pr. Franklin Roosevelt,
      94320 Thiais, France
      Phone at CCMIX +33-1-57 42 91 09
    • May 08 2006 | 1:31 pm
    • Jul 11 2006 | 12:18 pm
      Searching in the forum I found this very interesting discussion.
      But I found no definitive answer to the original question:
      Is it possible to go back from collective to patch? Yes or no?
      Or in my special case: Is it possible to port an old MacOS9 collective to MacOSX? Yes or no?
      Juergen