I might look this up I want to have a 1 file setup. I want to have editable abstraction file parts inside the main file. - like normal. but I want the offical abstraction patch design, to hide inside the main file for saving it there. and then maybe spit out a copy into the main folder when you open the main file. - so does pd make .pd files from maybe a pd subpatch only and then the patch is automatically turned into its own file on loadbang. maybe this isnt hard?
-
abstraction files. can you keep them in the main file? /
-
so the main flle, can it spit out smaller files different from the main file? with different names? I dont even care if it works from loadbang.
-
@willblackhurst You can use the [savetofile( message to save a subpatch which you can then use as an abstraction:
But any existing instance of that abstraction in main.pd will fail to load since the subpatch will not be saved before the patch is loaded. You might be able to make that work with [iemguts/initbang] but not sure, if it does work you would have to pay attention to creation order, the subpatch would have to be created before any instance of the abstraction. You would also want to make use of [file] to check to see if the file already exists/guard against accidental overwriting of files, etc. There are few good uses of this and it should generally be avoided. -
thanks !
-
@oid I got it to work directly into my pd folder once without putting home/will etc etc.
and then it suddenly stopped working! and now needs the entire path. -
@oid ok I got this to work again someehow
-
@willblackhurst I believe that would be working from pd's cwd which is not all that reliable and will change, possible savetofile always is relative to home dir but I would not expect that or rely on that. Best to always use full and absolute paths and use [file] to confirm all is well or you will eventually get bitten. Doubly so if you plan on sharing patches which exploit this.
-
interesting discussion! i hadn't considered using the
savetofile
message before. combined with thedir
message topdcontrol
for retrieving the patch path, this should be quite reliable, no?... this works well for me and might actually be an option to keep everything in one file. thanks!
-
@ben.wes if it were me I would also put main.pd into a subpatch and have a mypatch-installer.pd that installs all files and makes things explicit for the user. This also makes it so you can pop open savepanel and have it prompt the user for where to install and an easy way to do a fresh install, all those things people expect from an installer.
Edit: or is that what you are implying with the "everything" subpatch? Not quite clear on your example.
-
@oid you're right that my subpatch naming is a bit confusing here.
pd $0-main
only serves as the canvas where everything is created. so the idea here was that opening this file would directly create a running patch (which could have more dependencies created similarly to everything.pd). but your suggestion sounds good to just create an installer and let the user choose where to install.the reason for the dynamic patching of
everything
intopd $0-main
here is that i had no luck withiemguts/initbang
since it would not trigger first in a subpatch used for file creation unfortunately (this is mentioned in its help file). -
@ben.wes [initbang] would not have to be in the subpatch, it would just replace the [loadbang] in the main patch. That idea was based on the guess that pd did initbangs right after object creation and then after all objects were created/initialized it would connect them and then do the loadbangs, but I just tested it and it seems it creates all objects, does the initbangs, connects them all and then does the loadbangs so we can not exploit creation order for this.
Regarding an installer patch, creating them can be automated easily enough with an abstraction so you don't have to do all that copying and pasting. Use an [openpanel] to select the patch and its abstractions you want to make an installer for, then drip the file list, have it open the file, send the selectall, copy, and close messages, create the suppatch, send paste and then close the subpatch. Repeat to the end of the file list. Have it finish off with it patching in the installer logic/abstraction and deleting itself with [iemguts/canvasdelete] so all that is left for you to do is a few informative comments. Suppose you could just read the main patch into a [text] and have it go through the objects and find the abstractions automatically, using a tcl plugin to search for the abstractions would probably be easiest but you could also use [iemguts/canvasindex] to find anything with the class of canvas and a binbuf which does not start with "pd " but tcl seems the better way to go here.
Edit: Actually, reading into a [text] and searching for abstractions does not need to be that complicated because we would not want to find abstractions from libraries, could do this mostly if not completely with [file], no tcl/externals.