collective back to patch??

Apr 28, 2006 at 3:00pm

collective back to patch??

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

#25698
Apr 28, 2006 at 3:34pm

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

#75953
Apr 28, 2006 at 3:44pm

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

#75954
Apr 28, 2006 at 6:58pm

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

#75955
Apr 28, 2006 at 8:16pm

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/

#75956
Apr 29, 2006 at 9:41am

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

#75957
Apr 29, 2006 at 11:49am

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.

#75958
Apr 29, 2006 at 11:52am

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

– N.

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

#75959
Apr 29, 2006 at 1:32pm

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/

#75960
May 1, 2006 at 8:39am

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

#75961
May 1, 2006 at 9:59am

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

Julien.

#75962
May 1, 2006 at 2:39pm

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

#75963
May 2, 2006 at 10:01pm

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

#75964
May 3, 2006 at 4:47am

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

#75965
May 3, 2006 at 5:57am

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

#75966
May 3, 2006 at 9:27am

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

#75967
May 3, 2006 at 7:22pm

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

#75968
May 3, 2006 at 10:22pm

> #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?

#75969
May 8, 2006 at 9:43am

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

#75970
May 8, 2006 at 1:31pm

#75971
May 9, 2006 at 6:57pm

#75972

Anonymous

Anonymous
Jul 11, 2006 at 12:18pm

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

#75973

You must be logged in to reply to this topic.