Forums > MaxMSP

collective back to patch??

April 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


April 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


April 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


April 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


April 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/


April 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.


April 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.


April 29, 2006 | 11:52 am

It can’t be done automatically, since many objects open files
dynamically.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com


April 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 1, 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



jln
May 1, 2006 | 9:59 am

Yes Yes Yes ! It worths what it worths, but I second that.

Julien.


May 1, 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 2, 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 3, 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 3, 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 …

#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P comment 77 45 472 196617 #P user pictctrl 129 115 228 162 alex.pct 0
0 1 0 2 0 0 0 228 162 128 0 1 1 1 0 1 270 ; #P window clipboard
copycount 1 ;;
#P window clipboard copytext "#P user pictctrl 129 115 228 162 alex.pct
0 0 1 0 2 0 0 0 228 162 128 0 1 1 1 0 1 270;
#P window clipboard copycount 1;
" #E;
#P window clipboard copycount 1;

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 3, 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://
http://www.cassiel.com


May 3, 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 3, 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 8, 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 8, 2006 | 1:31 pm


May 9, 2006 | 6:57 pm



Anonymous
July 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


Viewing 22 posts - 1 through 22 (of 22 total)