managing multiple patches
i am new forgive me for that.
i have been working with oscillator, sampler, sequencer and various patches. i had a dream where all of these elements were in one place for a piece. should i be looking to make one big patch?
how can i arrange the various components where i can have access to all of them at once for a particular piece?
if you open a folder, and you had four of five different patches in there, you open each, how do you connect them and move data around?
or do you arrange in one big patch and use sub-patches.
sorry if the question is kinda spotty, i'm trying to visualize the end result and it's not exactly clear.
thank you in advance.
danny barnes
bpatcher
bpatcher is certainly an option, but it's definitely not the only way to manage complex patches in Max/MSP. It really depends on your end goals, and from the sound of your post it seems like you're not quite sure what you're after (don't worry, many of us are in similar positions... I find myself feeling that way over and over...)
I would definitely recommend checking out the Max46Topics.pdf document, there are chapters on "Efficiency" and "Encapsulation" that might be particularly relevant to your questions.
Other than that... be patient, try things out, and feel free to come back to this forum with more specific questions or patches to post. I think you'll find a very helpful community out there...
Hope that helps,
Dan
Sorry didn't mean to be short in my response.. I echo all the nice and helpful things Dan said as well. It was just that bpatcher really helped me get my complex patches way under control.
best
b
Danny Barnes schrieb:
> i have been working with oscillator, sampler, sequencer and various
> patches. i had a dream where all of these elements were in one place
> for a piece. should i be looking to make one big patch?
>
> how can i arrange the various components where i can have access to
> all of them at once for a particular piece?
I do it two fold: I have a collection of useful subpatchers (My St.ools
and abhaXions) which are independent of a specific project. They stay
where they are, because they will be needed by many/all projects...
Then I create a folder for my project, inside that folder I have a
subfolder called "patches" or somthing like that, also a folder like
"samples" or "media". I place all project specific subpatchers into the
"patcher" folder.
Now if I want to give the ready made project to a client, I just add
another "3rd party" folder and place my complete St.ools in there in
addition to any other 3rd party objects which might be required.
The client will immediately find the main patcher if opening the project
folder, she does not have to deal with all theses subpatchers, they
reside peacefully inside the folders and will be found by Max...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Stefan Tiedje wrote on Sat, 02 February 2008 12:08
----------------------------------------------------
> The client will immediately find the main patcher if opening the project
> folder, she does not have to deal with all theses subpatchers, they
> reside peacefully inside the folders and will be found by Max...
Um, as far as I know patches in subfolders are not found by max unless you put that subfolder explicitly in the search path. If I'm wrong, I'd love to know!
Mattijs
I thought the newer versions of max automatically add the folder of
the patch being opened to the search path for that 'max being open'
session, and thus things are found recursively.
At least, im 99% sure, as I dont add many subfolders and my patches
are found. Maybe ive lost my mind again?
On Feb 2, 2008, at 7:24 AM, Mattijs Kneppers wrote:
>
> Quote: Stefan Tiedje wrote on Sat, 02 February 2008 12:08
> ----------------------------------------------------
>
>> The client will immediately find the main patcher if opening the
>> project
>> folder, she does not have to deal with all theses subpatchers, they
>> reside peacefully inside the folders and will be found by Max...
>
> Um, as far as I know patches in subfolders are not found by max
> unless you put that subfolder explicitly in the search path. If I'm
> wrong, I'd love to know!
>
> Mattijs
>
>
my max (4.6.3) only finds subpatches that are in the same directory, not in a subdirectory.
without adding anything to the eearch path this works:
/path/to/patch/main_patch +
/path/to/patch/sub_patch
and this doesn't:
/path/to/patch/main_patch +
/path/to/patch/sub/sub_patch
in the second example it can't find the sub patch. would be very nice if it would though. i'd prefer to keep all the dependencies of a big patch in a sub dir of the folder where the patch itself is, and _know_ that max will look there first, before it searches elsewhere in my file path.. things can be confusing when you have different versions of patches, subpatches, abstractions or externals floating around in the search path.
now i just put all the dependencies in the same folder as the main patch.
regards,
kjg
Quote: vade wrote on Sat, 02 February 2008 19:18
----------------------------------------------------
> I thought the newer versions of max automatically add the folder of
> the patch being opened to the search path for that 'max being open'
> session, and thus things are found recursively.
>
> At least, im 99% sure, as I dont add many subfolders and my patches
> are found. Maybe ive lost my mind again?
>
>
Hmm.. could it be that your entire main patch folder is inside the max search path? For instance in ../MaxMSP 4.6/patches?
I attached an example of how it doesn't work for me. If I unpack this zip to my desktop and open 'main', I get an error that the abstraction isn't found.
Mattijs
Yup, that's how it has always happened for me. Hope Max 5 changes this.
On 2/2/08 2:25 PM, "Mattijs Kneppers" wrote:
> Quote: vade wrote on Sat, 02 February 2008 19:18
> ----------------------------------------------------
>> I thought the newer versions of max automatically add the folder of
>> the patch being opened to the search path for that 'max being open'
>> session, and thus things are found recursively.
>>
>> At least, im 99% sure, as I dont add many subfolders and my patches
>> are found. Maybe ive lost my mind again?
>>
>>
>
> Hmm.. could it be that your entire main patch folder is inside the max search
> path? For instance in ../MaxMSP 4.6/patches?
>
> I attached an example of how it doesn't work for me. If I unpack this zip to
> my desktop and open 'main', I get an error that the abstraction isn't found.
>
> Mattijs
Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson
Yes, sorry, it adds the FOLDER, not the subfolders. I was remembering
incorrectly, as I dont normally worry about it and have procedurally
created hard coded paths with my module loading system, so I can NOT
think about it.
Sorry for the confusion.
On Feb 2, 2008, at 5:53 PM, Gary Lee Nelson wrote:
> Yup, that's how it has always happened for me. Hope Max 5 changes
> this.
>
>
> On 2/2/08 2:25 PM, "Mattijs Kneppers" wrote:
>
>> Quote: vade wrote on Sat, 02 February 2008 19:18
>> ----------------------------------------------------
>>> I thought the newer versions of max automatically add the folder of
>>> the patch being opened to the search path for that 'max being open'
>>> session, and thus things are found recursively.
>>>
>>> At least, im 99% sure, as I dont add many subfolders and my patches
>>> are found. Maybe ive lost my mind again?
>>>
>>>
>>
>> Hmm.. could it be that your entire main patch folder is inside the
>> max search
>> path? For instance in ../MaxMSP 4.6/patches?
>>
>> I attached an example of how it doesn't work for me. If I unpack
>> this zip to
>> my desktop and open 'main', I get an error that the abstraction
>> isn't found.
>>
>> Mattijs
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> www.timara.oberlin.edu/GaryLeeNelson
>
>
thank you so very much for the answers.
you all have given me so much to work on and think about.
i sure appreciate it.
danny barnes
Quote: vade wrote on Sun, 03 February 2008 02:32
----------------------------------------------------
> Yes, sorry, it adds the FOLDER, not the subfolders. I was remembering
> incorrectly, as I dont normally worry about it and have procedurally
> created hard coded paths with my module loading system, so I can NOT
> think about it.
>
Actually things wouldn't be so bad if it was possible to use the relative path to the subfolder, as in [subfolder/jeanclaudevandamme]. But that doesn't work either.
Mattijs
Mattijs Kneppers schrieb:
> Um, as far as I know patches in subfolders are not found by max
> unless you put that subfolder explicitly in the search path. If I'm
> wrong, I'd love to know!
Yes, though always advertised it never worked. I tell them to place it
or an alias into the patches folder, which is easy enough...
But the recent thread about a patch which will add to the search path
might do it. You double click the patch to add the search path, and the
same will load the main patch afterwards.
One could also have a test subpatcher, if its found will interupt the
following sequence:
add the folder to the search path, restart the patch, close the non
complete patch from the forst attempt...
But the error messages in the Max window will remain...
Probably its too much hassle...
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
Quote: Stefan Tiedje wrote on Sun, 03 February 2008 17:44
----------------------------------------------------
> I tell them to place it
> or an alias into the patches folder, which is easy enough...
No, this is bad practice. If you have multiple versions of the same abstraction hidden in the depths of the patches folder you will never know which one is loaded. And yeah, the patches folder is advertised in the manual. It shouldn't be.
>
> But the recent thread about a patch which will add to the search path
> might do it. You double click the patch to add the search path, and the
> same will load the main patch afterwards.
Yeah, I still have to try that idea. It doesn't feel good though, looking at the sometimes-synchronous-sometimes-not behaviour when creating larger abstractions with scripting..
Mattijs
Mattijs Kneppers schrieb:
> No, this is bad practice. If you have multiple versions of the same
> abstraction hidden in the depths of the patches folder you will never
> know which one is loaded. And yeah, the patches folder is advertised
> in the manual. It shouldn't be.
Though in most cases they have just my patch to run in MaxPlay. Its less
of a danger than in my own environment. And it wouldn't change anything
if they'd just add the folder to the search path, search path is search
path no matter if its in the patches folder or elsewhere. And Murphy
tought me, that its always the wrong version loading if you have several
of them no matter where you place it... ;-)
Stefan
--
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com
My workaround for this particular problem is module loading at patch
runtime.
Any subpatches I need are kept in a module folder, which is specified
in my patch as an argument to my module loading abstraction. When the
patch is run it searches the modules folder and makes a full path to
the subpatch. This removes any issues with file path issues or
duplicate names, as the path is hard coded, etc.
it works, but makes loading a bit slower with larger amounts of modules.
just my 2.c workaround :)
On Feb 3, 2008, at 2:03 PM, Stefan Tiedje wrote:
> Mattijs Kneppers schrieb:
>> No, this is bad practice. If you have multiple versions of the same
>> abstraction hidden in the depths of the patches folder you will never
>> know which one is loaded. And yeah, the patches folder is advertised
>> in the manual. It shouldn't be.
>
> Though in most cases they have just my patch to run in MaxPlay. Its
> less of a danger than in my own environment. And it wouldn't change
> anything if they'd just add the folder to the search path, search
> path is search path no matter if its in the patches folder or
> elsewhere. And Murphy tought me, that its always the wrong version
> loading if you have several of them no matter where you place
> it... ;-)
>
> Stefan
>
> --
> Stefan Tiedje------------x-------
> --_____-----------|--------------
> --(_|_ ----|-----|-----()-------
> -- _|_)----|-----()--------------
> ----------()--------www.ccmix.com
>
Quote: Mattijs wrote on Sun, 03 February 2008 18:45
> Yeah, I still have to try that idea. It doesn't feel good though, looking at the sometimes-synchronous-sometimes-not behaviour when creating larger abstractions with scripting..
I'm not sure I get what you mean here. To what extend the "sometimes-synchronous-sometimes-not" behaviour would cause problems using the strategy mentioned. When all the scripting part happens in the main patch, all paths are in Max's search preferences (until it is restarted), no ?
I attach what I often use. I never had some troubles but never did a big patch involving a lot of scripting so maybe I'm missing something...
Best,
Julien.
Argh. Forgot to click 'upload file'...
Sorry. Here it is.
Julien
BTW, I've had problems in the past with max being confused and crashing when there's multiple patches with the same name in the search patch. Say a couple folders with different versions of a project with some of the same named patches. C74 tech support helped me figure this out as I used to have all my patches in the search path. Now I'm more strategic.
best
b
Quote: jln wrote on Sun, 03 February 2008 20:53
----------------------------------------------------
> Quote: Mattijs wrote on Sun, 03 February 2008 18:45
>
> > Yeah, I still have to try that idea. It doesn't feel good though, looking at the sometimes-synchronous-sometimes-not behaviour when creating larger abstractions with scripting..
>
> I'm not sure I get what you mean here. To what extend the "sometimes-synchronous-sometimes-not" behaviour would cause problems using the strategy mentioned. When all the scripting part happens in the main patch, all paths are in Max's search preferences (until it is restarted), no ?
Ah no it was more of a general statement, patches loading other patches sounds unreliable. A bit too general, perhaps. I'll try it first.
Mattijs
Quote: jln wrote on Sun, 03 February 2008 20:56
----------------------------------------------------
> Argh. Forgot to click 'upload file'...
>
> Sorry. Here it is.
>
> Julien
----------------------------------------------------
This is a nice example, thanks for sharing!
Mattijs
Ok, I've been checking with a big patch that also does a fair amount of scripting on load and so far your solution seems to work great! Thanks again :)
Btw by relying on synchronous events I think you could slightly simplify your patch:
Mattijs
Quote: jln wrote on Sun, 03 February 2008 20:53
----------------------------------------------------
> Quote: Mattijs wrote on Sun, 03 February 2008 18:45
>
> > Yeah, I still have to try that idea. It doesn't feel good though, looking at the sometimes-synchronous-sometimes-not behaviour when creating larger abstractions with scripting..
>
> I'm not sure I get what you mean here. To what extend the "sometimes-synchronous-sometimes-not" behaviour would cause problems using the strategy mentioned. When all the scripting part happens in the main patch, all paths are in Max's search preferences (until it is restarted), no ?
>
> I attach what I often use. I never had some troubles but never did a big patch involving a lot of scripting so maybe I'm missing something...
>
> Best,
> Julien.
----------------------------------------------------
Quote: Mattijs wrote on Mon, 04 February 2008 10:55
----------------------------------------------------
> Quote: jln wrote on Sun, 03 February 2008 20:56
> ----------------------------------------------------
> > Argh. Forgot to click 'upload file'...
> >
> > Sorry. Here it is.
> >
> > Julien
> ----------------------------------------------------
>
> This is a nice example, thanks for sharing!
>
> Mattijs
----------------------------------------------------
This is going to be very helpful indeed, thanks. Allow me to suggest a version that doesn't rely on a fixed folder structure.
_
johan
Quote: jln wrote on Mon, 04 February 2008 12:35
----------------------------------------------------
> the
> '100' argument should be removed from [filepath] so paths are not
> saved in Max's preferences on quit. It's not a big problem but I guess
> people don't want their preferences to be changed by my patch.
Actually I see a reason not to remove the 100. This way, it will not be a problem to open an older version of your patch first and then load a newer version without restarting max. If you remove the 100 there is a chance that the newer version will use files from the older version because the paths of the older version aren't overwritten.
>
> The reason I send the 'dispose' message from the main patch is only
> cosmetic. As I use the launcher patch as a pseudo appsplash, I like
> seeing it going away only when the main patch is ready and fully
> initialized.
Ah, I see. But that would also require a delay before loading the real patch. I don't get a graphics update until everything is loaded.
Adding a slider in the launcher showing the progress of
> the main patch initialization is also rather neat. :-)
As far as I can see for this to work you'd need the graphics redraws to happen in a separate thread, which unfortunately isn't the case in max.
Best,
Mattijs
Quote: jvkr wrote on Mon, 04 February 2008 12:59
----------------------------------------------------
>
> This is going to be very helpful indeed, thanks. Allow me to suggest a version that doesn't rely on a fixed folder structure.
>
>
Ha! Nice one :)
Mattijs
Hi Julien,
Do you happen to use your loader to from inside a collective? If so, I'd be interested to know if you ran into any issues.
Mattijs
Quote: jln wrote on Tue, 05 February 2008 13:42
----------------------------------------------------
> I did not yet. I thought about doing so in order to include some
> script files or things like these, but until a recent conversation I
> thought that there were no way to get the path to a collective. I will
> give it a try if needed. However, if I recall correctly, there's a bug
> with [absolutepath] which only work if the collective is outside Max's
> search path, so it's hardly a solution yet, for me.
I see. There is this strange behaviour that a 'path' message to thispatcher outputs a space (?) inside a collective. Anyway, the whole collective and paths thing is a little fishy.
>
> By the way, I made a quick sketch last late evening based on my patch
> and Johan's one. It should work fine and prevent the patch from
> loading if a directory is missing (the patch can be loaded anyway from
> a dialog window). I'll try to check if I did not missed a problem and
> post it later.
That sounds interesting. Please do.
One more question (shamelessly exploiting your search path expertise), do you know where the paths are stored? I can't seem to find any text file..
Mattijs
Quote: Mattijs wrote on Tue, 05 February 2008 14:49
----------------------------------------------------
> I see. There is this strange behaviour that a 'path' message to thispatcher outputs a space (?) inside a collective. Anyway, the whole collective and paths thing is a little fishy.
CNMAT's [printit] display "" as [thispatcher] output. It looks like a reeaaally tiny space... Weird. Maybe some info will raise on the other thread ?
> One more question (shamelessly exploiting your search path expertise), do you know where the paths are stored? I can't seem to find any text file.
I assume you mean paths added with a 0 argument for [filepath]. If so, I'm afraid my "expertise" stops here... I thought the paths would be removed the paths from the maxsearchpaths.txt situated in Max's preferences folder when quitting Max, but it doesn't seem to be the case. I gave a search to see if a temporary file was created somewhere but with no luck. Maybe Max do this internally ? That or the file is well hidden...
I attach the patch mentioned earlier today - with an intentional path error. It needs some polish and some possible optimizations. I feel there's a better way to compare paths and check if they're all present but the principle seems to work. I did not test it in real situation, though. Feel free to post some suggestions.
Best,
Julien.
> > One more question (shamelessly exploiting your search path expertise), do you know where the paths are stored? I can't seem to find any text file.
>
> I assume you mean paths added with a 0 argument for [filepath]. If so, I'm afraid my "expertise" stops here... I thought the paths would be removed the paths from the maxsearchpaths.txt situated in Max's preferences folder when quitting Max, but it doesn't seem to be the case.
Added search paths must be kept in memory. Anyhow using the append message to filepath appends paths without saving them in preferences file, according to the documentation. That would mean that the integer, be it 0 or 100, would not make a difference.
Anyhow, there seems to be a discrepancy between the help file and the documentation concerning the set message. The help file explains: set changes the path
whereas the pdf states:
The word set, followed by the name of a Max search path type (search, startup,
help, action, or default), sets the current search path to the type specified.
Filepath appears to do the former.
_
johan
Aha! maxsearchpaths.txt was what I was looking for. I'm not an experienced mac user (although I own one and spend several tens of hours a week working on them, maybe I just don't want to learn) so it just didn't occur to me to look in the library/preferences folder.
I removed the 100 from the filepath object in my modified version of juliens first example, because if I look at maxsearchpaths.txt I do see an entry appearing for number 100. Appearantly the append message -does- save the new path in the text file if you type a number as second argument to filepath.
I think this can be filed as a bug.
Steps to reproduce:
1) open maxsearchpaths.txt, see that there is no entry 45, close maxsearchpaths.txt
2) open this patch, choose a folder
3) open maxsearchpaths.txt, now there is an entry 45
Expected behaviour:
from the help file: "append adds to the list of paths (but is not saved in the preferences file)"
Max 4.6.3, Mac OS 10.4.11
Mattijs
Quote: jvkr wrote on Wed, 06 February 2008 10:42
----------------------------------------------------
>
> > > One more question (shamelessly exploiting your search path expertise), do you know where the paths are stored? I can't seem to find any text file.
> >
> > I assume you mean paths added with a 0 argument for [filepath]. If so, I'm afraid my "expertise" stops here... I thought the paths would be removed the paths from the maxsearchpaths.txt situated in Max's preferences folder when quitting Max, but it doesn't seem to be the case.
>
> Added search paths must be kept in memory. Anyhow using the append message to filepath appends paths without saving them in preferences file, according to the documentation. That would mean that the integer, be it 0 or 100, would not make a difference.
>
> Anyhow, there seems to be a discrepancy between the help file and the documentation concerning the set message. The help file explains: set changes the path
> whereas the pdf states:
> The word set, followed by the name of a Max search path type (search, startup,
> help, action, or default), sets the current search path to the type specified.
>
> Filepath appears to do the former.
>
> _
> johan
----------------------------------------------------
hello all,
this thread is quite old, but i think that it would be still gerat, if
max would include all patches, which are located in subfolders beside the main patch.
this works:
/path/to/patch/main_patch +
/path/to/patch/sub_patch
and this doesn't:
/path/to/patch/main_patch +
/path/to/patch/sub/sub_patch
as described, the actual workaround is:
- open a loaderpatch (loader)
- set the searchpath
- open the main patch
this is not very compfortable and unflexible ...
this feature should not be that hard to implement.
thank you for your attention,
lydia