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:
- ugly workaround, make symlinks to the same patch so it can be opened
(and then managed) via different filenames or directory names)
urgh.
- I could add a message to pd or perhaps a startup flag, or both, to
switch the behavior on and off.
- (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