On 9/22/18 6:26 PM, Miller Puckette wrote: > Oh dear, I was worried this might cause problems. > > The rationale is that, especially for beginning users but often for > experienced ones, it is rarely desirable to have two copies of, for > instance, the test tone patch running at once. (An example from my own > usage is that I have a "play" shell command that opens a patch to play > a soundfile but I don't want to spawn a new one every time I want to play > a new file.) > > Anyhow, to make the old behavior possible (which I think is only useful for > experts) I could imagine a couple of ways: > > 1) ugly workaround, make symlinks to the same patch so it can be opened > (and then managed) via different filenames or directory names)
urgh. > > 2) I could add a message to pd or perhaps a startup flag, or both, to > switch the behavior on and off. > > 3) (I doubt this is a good idea) I could make it "0.48 compatible" to open > duplicates. urgh again. so what if i want infinite undo (or any other cool feature introduced in 0.50) but still want to open the same patch multiple times? so from my side, i really only see something along the lines of #2. i'd do: - handle no-dupe-open in the GUI - add a GUI-preference to enable/disable this behaviour as a side-effect, the "pd open" would always allow for duplicate open. i don't know how your shell-script works but it probably should open the patch via file associations ("xdg-open playsound.pd"), which in turn would open the patch via pd-gui (as opposed to pd-core) which would filter out duplicate open requests (in the case of opening a file via association the no-dupe protection might even kick in unconditionally; but that might also just be overengineering) fgmdsar IOhannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list