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 http://www.sleazeArt.com

    • 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 http://www.dspaudio.com/
    • 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 http://www.dspaudio.com/
    • 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