to be clear… the ‘my’ OS does not create folders, nor break patches
users can still put patches in the /usbdrive/Patches folder and they will work as before.
the issue is if a patch is written in such a way, that it cannot be renamed, or it hard codes the fact that it is in /Patches… then if the user places such in a sub folder (or renames it) it will not work, as is the case with the current os.
there is no reason, for patch developers to make these assumptions, and its easy to fix, but as mentioned the issue is some older patches need to be updated to reflect this.
also it should be noted, that the ‘technobear os’ is not an alternative OS, these are betas for features Ive been adding that are going into the official os i.e. the next C&G release will include all features in ‘my beta’ O/S.
so patches can be updated now (and still be compatible with 2.1) , or wait for ‘bug reports’ when C&G release these features.
hmm, that’s an interesting idea…
I guess this is akin to how normally a user would define the paths in pure data preferences.
we cant re-write the .pdsettings as this is read-only (for good reason).
I could certainly create a configuration file for this, and then pass this to pure data on the command line… this would allow not only lib/path changes but also other overrides.
what do you think @oweno ?
we could create a config file, which allowed ‘extra’ pure data cmd line options to be set…
following my current model, /System/pdsettings for all patches patchdir/pdsettings just for the patch.
because these settings are passed on the command line to pure data, they can also include the environment variables I create e.g. $PATCHDIR $WORKDIR etc.
(do we thing pdsettings is a good name, of perhaps pd-opts.txt)
I like where this went and thanks for the clarifications.
i am trying to organize a full pd-libs folder to retire the “extended” idea too so what you are proposing sounds great to me at least it will save a bunch of questioning and questions as we move FW
one thing i think we have to be careful for both of these, is not to make it more difficult for users developing organelle patches on a desktop computers, I dont think the above really causes an issue since:
most of the things going into the pd-opts file, could be added to .pdsettings, or I guess temporarily add a declare at the top of the patch.
the ‘pd-libs’ folder could be replicated on a desktop computer
but still, Im a little wary…
for more complex patches (and where I’m developing new externals) , I inevitably do much of the development on my mac… if anything, Id like to improve this workflow (mother-desktop.pd! ) , and avoid hindering it, with expectations on what is setup by the ‘mother exec’, missing externals etc.
sorry, this is all going a bit OT, mods feel free to move it
i think community wise the idea of “extended” is something everyone needs to move beyond. we can call it whatever but i do not want to assign the new work we are all doing to “pd-extended” any longer. That’s just a private opinion and we can come up with an acronym or just call it pdlibs but ‘extended’ simply as a term i am sunsetting i agree with the rest you share i think if possible we can/should create a darwin/linux/windows folder for the externals so it’s seemless and people can start making/fixing and tweaking their own patches easier i am shy on the windows front though
