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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
