Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose. Moreover, when trying to load a patch twice, pd becomes unresponsive in some cases.
The new behavior is a show stopper for projects that rely on, or benefit from, loading multiple instances from a patch. As it happens I'm currently working on such a project. So my questions are: what is the rationale behind this 'feature', and is it really going to stay?
Katja
On 9/22/18 3:17 PM, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose.
funnily, i recently worked on a related regression where double-clicking on a Pd-patch (in your favourite Windows exploder) would start a new instance of Pd (rather than switching to the current instance and raising the patch if already opened).
note however, that this regression (fix) is unrelated to what you are describing.
and i agree that it should be possible to open the same patch multiple times. esp. on a programmatic layer (that is: by sending messages to Pd). i guess, when opening an already opened patch from the menu (Ctrl-O), Pd could *ask* whether this is really intended.
gkmdsar IOhannes
Ah, yes, a fourth option: have a new "pd really-open" message to open a file without checking if it's a duplicate.
cheers M
On Sat, Sep 22, 2018 at 06:18:42PM +0200, IOhannes m zm??lnig wrote:
On 9/22/18 3:17 PM, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose.
funnily, i recently worked on a related regression where double-clicking on a Pd-patch (in your favourite Windows exploder) would start a new instance of Pd (rather than switching to the current instance and raising the patch if already opened).
note however, that this regression (fix) is unrelated to what you are describing.
and i agree that it should be possible to open the same patch multiple times. esp. on a programmatic layer (that is: by sending messages to Pd). i guess, when opening an already opened patch from the menu (Ctrl-O), Pd could *ask* whether this is really intended.
gkmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I support IOhannes' idea of distinguishing between opening from the menu and opening from the OS file system, and of asking the user if they want a new instance.
Another case for multiple patches is this: the user is editing a patch, but worries that he has misplaced a connection or damaged it somehow. So before saving it, he opens the earlier version from the menu, just to check that everything is in place. Then he closes the old version and saves the new one. I find myself doing this a lot, and it doesn't seem particularly "expert" to me.
Having said this, I think the new feature is worth keeping, so long as there is some provision for multiple instances of the same patch. ________________________________ From: Pd-list pd-list-bounces@lists.iem.at on behalf of Miller Puckette msp@ucsd.edu Sent: 22 September 2018 17:27 To: IOhannes m zm??lnig Cc: pd-list@lists.iem.at Subject: Re: [PD] multiple instances of a patch forbidden in 0.49, why?
Ah, yes, a fourth option: have a new "pd really-open" message to open a file without checking if it's a duplicate.
cheers M
On Sat, Sep 22, 2018 at 06:18:42PM +0200, IOhannes m zm??lnig wrote:
On 9/22/18 3:17 PM, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose.
funnily, i recently worked on a related regression where double-clicking on a Pd-patch (in your favourite Windows exploder) would start a new instance of Pd (rather than switching to the current instance and raising the patch if already opened).
note however, that this regression (fix) is unrelated to what you are describing.
and i agree that it should be possible to open the same patch multiple times. esp. on a programmatic layer (that is: by sending messages to Pd). i guess, when opening an already opened patch from the menu (Ctrl-O), Pd could *ask* whether this is really intended.
gkmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I have to say I like the new feature and being able to avoid loading the same patch twice, even as an expert, so I guess a flag or something that allows us to configure this is fine.
Em sáb, 22 de set de 2018 às 13:30, Miller Puckette msp@ucsd.edu escreveu:
Ah, yes, a fourth option: have a new "pd really-open" message to open a file without checking if it's a duplicate.
cheers M
On Sat, Sep 22, 2018 at 06:18:42PM +0200, IOhannes m zm??lnig wrote:
On 9/22/18 3:17 PM, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose.
funnily, i recently worked on a related regression where double-clicking on a Pd-patch (in your favourite Windows exploder) would start a new instance of Pd (rather than switching to the current instance and raising the patch if already opened).
note however, that this regression (fix) is unrelated to what you are describing.
and i agree that it should be possible to open the same patch multiple times. esp. on a programmatic layer (that is: by sending messages to Pd). i guess, when opening an already opened patch from the menu (Ctrl-O), Pd could *ask* whether this is really intended.
gkmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
when trying to load a patch twice, pd becomes unresponsive
I confirm that; whatever the decision, this doesn't seem to be a desirable behavior...;-)
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 à 19:35, Alexandre Torres Porres porres@gmail.com a écrit :
I have to say I like the new feature and being able to avoid loading the same patch twice, even as an expert, so I guess a flag or something that allows us to configure this is fine.
Em sáb, 22 de set de 2018 às 13:30, Miller Puckette msp@ucsd.edu escreveu:
Ah, yes, a fourth option: have a new "pd really-open" message to open a file without checking if it's a duplicate.
cheers M
On Sat, Sep 22, 2018 at 06:18:42PM +0200, IOhannes m zm??lnig wrote:
On 9/22/18 3:17 PM, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose.
funnily, i recently worked on a related regression where double-clicking on a Pd-patch (in your favourite Windows exploder) would start a new instance of Pd (rather than switching to the current instance and raising the patch if already opened).
note however, that this regression (fix) is unrelated to what you are describing.
and i agree that it should be possible to open the same patch multiple times. esp. on a programmatic layer (that is: by sending messages to
Pd).
i guess, when opening an already opened patch from the menu (Ctrl-O), Pd could *ask* whether this is really intended.
gkmdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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)
- 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.
Which do you think is the better option? Any of these would be easy for me to accomodate.
cheers Miller
On Sat, Sep 22, 2018 at 03:17:20PM +0200, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose. Moreover, when trying to load a patch twice, pd becomes unresponsive in some cases.
The new behavior is a show stopper for projects that rely on, or benefit from, loading multiple instances from a patch. As it happens I'm currently working on such a project. So my questions are: what is the rationale behind this 'feature', and is it really going to stay?
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Sorry for reporting this so late in the test phase. One thing that surprises me is, why would it be considered an accident to open more than one instance of the same patch? This depends on the purpose of a patch or project. For the audio test it makes no sense indeed to open more than one. On the other hand, uses cases for multiple instances are innumerable, for live performance, analysis, and who knows what else. A patch is a tool and no one can tell how people use it. I would rather say that unintentionally loading the same patch twice is a mistake, but not one that pd must take care of by prohibiting it. A popup warning or the like would be annoying enough in my view. Not sure what would be a good solution. Frankly I'm just perplexed that this protective behavior came up in pd.
Katja
On 9/22/18, Miller Puckette msp@ucsd.edu 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)
- 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.
Which do you think is the better option? Any of these would be easy for me to accomodate.
cheers Miller
On Sat, Sep 22, 2018 at 03:17:20PM +0200, katja wrote:
Much to my alarm, Pd 0.49test3 prevents loading multiple instances of a patch, and release notes tell us that this is on purpose. Moreover, when trying to load a patch twice, pd becomes unresponsive in some cases.
The new behavior is a show stopper for projects that rely on, or benefit from, loading multiple instances from a patch. As it happens I'm currently working on such a project. So my questions are: what is the rationale behind this 'feature', and is it really going to stay?
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
- ugly workaround, make symlinks to the same patch so it can be opened
(and then managed) via different filenames or directory names)
- 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.
my vote is #2 !
(that is: both a startup flag AND a possible message to PD to dynamically turn it on/off)
now we only have to decide what the default behaviour should be ;-)
(i personally think that multiple patch instances should stay the default.)
best
oliver
I can imagine it being it a GUI preference. maybe there could be a dialog asking you if you really want to open the same patch again with the usual 'yes', 'no' + 'don't ask me again' (saving your selection in the GUI preferences).
OTOH, I kind of agree with the others that I never thought it was a problem that you can open the same patch several times... if it's just for test tone patch, this could be solved in other ways.
Christof
Gesendet: Samstag, 22. September 2018 um 22:53 Uhr Von: oliver oliver@klingt.org An: Pd-list pd-list@mail.iem.at Betreff: Re: [PD] multiple instances of a patch forbidden in 0.49, why?
- ugly workaround, make symlinks to the same patch so it can be opened
(and then managed) via different filenames or directory names)
- 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.
my vote is #2 !
(that is: both a startup flag AND a possible message to PD to dynamically turn it on/off)
now we only have to decide what the default behaviour should be ;-)
(i personally think that multiple patch instances should stay the default.)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Christof Ressi wrote:
I can imagine it being it a GUI preference. maybe there could be a dialog asking you if you really want to open the same patch again with the usual 'yes', 'no' + 'don't ask me again' (saving your selection in the GUI preferences).
mmh, i for one really don't like the idea of any kind of "popup windows" scenario, (which could easily become a problem in any automation/installation etc. setups).
i think a startup flag (probably also a toggle in the preferences menu) and a message to PD should do it
best
oliver
On Sat, 2018-09-22 at 23:11 +0200, Christof Ressi wrote:
OTOH, I kind of agree with the others that I never thought it was a problem that you can open the same patch several times...
Me neither. I do think it should be allowed one way or the other. Having to use a flag for it (probably the least annoying option) is still slightly annoying.
Roman
I guess the least annoying of all would be to revery back to the way it was, and then to add an "open-unique" message to pd for anyone who wants this behavior (apparently not many do).
cheers Miller
On Sat, Sep 22, 2018 at 11:26:48PM +0200, Roman Haefeli wrote:
On Sat, 2018-09-22 at 23:11 +0200, Christof Ressi wrote:
OTOH, I kind of agree with the others that I never thought it was a problem that you can open the same patch several times...
Me neither. I do think it should be allowed one way or the other. Having to use a flag for it (probably the least annoying option) is still slightly annoying.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-L2Ork offers -unique startup flag that leverages Tcl/Tk's ability to share variables across multiple apps. By default it tries to open patches in an existing instance to prevent newcomers who tend to open patches by double-clicking on icons from opening multiple instances of Pd-L2Ork and thereby getting confused by the existing patches (if any) not communicating with the new one (e.g. via sends and received) or having two consoles. With some minor modifications, this should be also able to do the same per patch Please feel free to copy/port, as needed.
Best,
Ico
A bit trickier solution would be to add the possibility to lock a given patch, i.e forbid to open it twice.
This could be either via an additional object (e.g [lock]), or a GUI property that would be saved into the patch file, like the font size.
This would require that, when a patch is requested for opening, the file would be first read, then discard if either [lock] is present or lock_property is set and a toplevel patch of this file is already opened.
Antoine
Le sam. 22 sept. 2018 à 23:11, Christof Ressi christof.ressi@gmx.at a écrit :
I can imagine it being it a GUI preference. maybe there could be a dialog asking you if you really want to open the same patch again with the usual 'yes', 'no' + 'don't ask me again' (saving your selection in the GUI preferences).
OTOH, I kind of agree with the others that I never thought it was a problem that you can open the same patch several times... if it's just for test tone patch, this could be solved in other ways.
Christof
Gesendet: Samstag, 22. September 2018 um 22:53 Uhr Von: oliver oliver@klingt.org An: Pd-list pd-list@mail.iem.at Betreff: Re: [PD] multiple instances of a patch forbidden in 0.49, why?
- ugly workaround, make symlinks to the same patch so it can be opened
(and then managed) via different filenames or directory names)
- 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.
my vote is #2 !
(that is: both a startup flag AND a possible message to PD to dynamically turn it on/off)
now we only have to decide what the default behaviour should be ;-)
(i personally think that multiple patch instances should stay the default.)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Of course [once] would be much better than [lock]....
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 à 23:28, Antoine Rousseau antoine@metalu.net a écrit :
A bit trickier solution would be to add the possibility to lock a given patch, i.e forbid to open it twice.
This could be either via an additional object (e.g [lock]), or a GUI property that would be saved into the patch file, like the font size.
This would require that, when a patch is requested for opening, the file would be first read, then discard if either [lock] is present or lock_property is set and a toplevel patch of this file is already opened.
Antoine
Le sam. 22 sept. 2018 à 23:11, Christof Ressi christof.ressi@gmx.at a écrit :
I can imagine it being it a GUI preference. maybe there could be a dialog asking you if you really want to open the same patch again with the usual 'yes', 'no' + 'don't ask me again' (saving your selection in the GUI preferences).
OTOH, I kind of agree with the others that I never thought it was a problem that you can open the same patch several times... if it's just for test tone patch, this could be solved in other ways.
Christof
Gesendet: Samstag, 22. September 2018 um 22:53 Uhr Von: oliver oliver@klingt.org An: Pd-list pd-list@mail.iem.at Betreff: Re: [PD] multiple instances of a patch forbidden in 0.49, why?
- ugly workaround, make symlinks to the same patch so it can be
opened
(and then managed) via different filenames or directory names)
- 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.
my vote is #2 !
(that is: both a startup flag AND a possible message to PD to dynamically turn it on/off)
now we only have to decide what the default behaviour should be ;-)
(i personally think that multiple patch instances should stay the default.)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as an argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 à 23:55, Roman Haefeli reduzent@gmail.com a écrit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Well, I ended up simply reverting to the old behavior but leaving a hook in so that users can specifically ask only to open a patch once.
cheers M
On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as an argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli reduzent@gmail.com a ??crit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
thanks Miller, it works perfectly!
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le dim. 23 sept. 2018 à 00:37, Miller Puckette msp@ucsd.edu a écrit :
Well, I ended up simply reverting to the old behavior but leaving a hook in so that users can specifically ask only to open a patch once.
cheers M
On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as
an
argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli reduzent@gmail.com a
??crit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Thanks Miller for this quick yet powerful fix.
It currently operates on patches as opened from the window menu. Help patches can still be opened more than once from the contextual menu. I verified that this can be fixed by calling glob_open() instead of glob_evalfile() from open_via_helppath() in s_path.c:
glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1);
However to make it work, the prototype of glob_open() must be declared when compiling s_path.c, otherwise the float argument is not passed correctly for some reason (while the file and dir name are, isn't that odd?)
Katja
On 9/23/18, Miller Puckette msp@ucsd.edu wrote:
Well, I ended up simply reverting to the old behavior but leaving a hook in so that users can specifically ask only to open a patch once.
cheers M
On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as an argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli reduzent@gmail.com a ??crit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
actually, it's probably not a serious problem that one can multiply open help files (if one really wants to), so probably it's not worth fixing this.
On the other hand, a naive user on a Mac would expect that clicking on a file in the "finder", if Pd already has the file open, would show the user the open file instead of opening another copy.
Supposing the "open" menu called "pd open" with the third nonzero argument, but if "pd open" acted as it does now so that one could programmatically open multiple copies of a patch, would this permit you to do what you're planning? (I think that this would be patch-level back compatible).
cheers Miller
On Sun, Sep 23, 2018 at 11:52:54AM +0200, katja wrote:
Thanks Miller for this quick yet powerful fix.
It currently operates on patches as opened from the window menu. Help patches can still be opened more than once from the contextual menu. I verified that this can be fixed by calling glob_open() instead of glob_evalfile() from open_via_helppath() in s_path.c:
glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1);
However to make it work, the prototype of glob_open() must be declared when compiling s_path.c, otherwise the float argument is not passed correctly for some reason (while the file and dir name are, isn't that odd?)
Katja
On 9/23/18, Miller Puckette msp@ucsd.edu wrote:
Well, I ended up simply reverting to the old behavior but leaving a hook in so that users can specifically ask only to open a patch once.
cheers M
On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as an argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli reduzent@gmail.com a ??crit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em dom, 23 de set de 2018 às 17:35, Miller Puckette msp@ucsd.edu escreveu:
actually, it's probably not a serious problem that one can multiply open help files (if one really wants to), so probably it's not worth fixing this.
On the other hand, a naive user on a Mac would expect that clicking on a file in the "finder", if Pd already has the file open, would show the user the open file instead of opening another copy.
yeah, that and also not opening multiple instances of the help patch and test audio. I'm often seeing many duplicates that I really didn't mean to, and sometimes I get errors like "array multiply defined" and such because of that.
not a big deal though
anyway, this seems to be gone in the last test5 version, right?
so does it mean the entry "Opening patches from menu, command line, or messages to "pd" first check of the file is already open and if so only bring the existing patch to front." in the release notes is no longer true?
Em dom, 23 de set de 2018 às 20:43, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em dom, 23 de set de 2018 às 17:35, Miller Puckette msp@ucsd.edu escreveu:
actually, it's probably not a serious problem that one can multiply open help files (if one really wants to), so probably it's not worth fixing this.
On the other hand, a naive user on a Mac would expect that clicking on a file in the "finder", if Pd already has the file open, would show the user the open file instead of opening another copy.
yeah, that and also not opening multiple instances of the help patch and test audio. I'm often seeing many duplicates that I really didn't mean to, and sometimes I get errors like "array multiply defined" and such because of that.
not a big deal though
Miller do you mean to extend the single-open mechanism from the doc files to the 'file>open' menu? Like when you try to open a C file in Geany while it is already open, Geany will pop the existing one rather than open a second instance. For a code editor that makes sense. And Pd is a code editor after all. But it is a code interpreter at the same time, which is exactly why Pd is so great for education and prototyping. And for an interpreter it doesn't always make sense to prohibit multiple instances of a program, it just depends on the nature of the work. Let me give an example: Martin Brinkmann's Chaosmonster (http://www.martin-brinkmann.de/pd-patches.html) is an wonderful sound generator on a small patch. Depending on parameter settings it can produce very different sounds and it's fun to load a few of them. I know people who use the patch in live performance. Imagine their surprise when Pd refuses to load more than one.
The question when multiple instances are useful or potentionally harmful is complex. Even when loading from 'menu>open' is restricted to a single instance (which I hope is not going to be default behavior), it is still possible to edit multiple instances of an abstraction, causing the confusion and frustration that I remember indeed from my first year with Pd. Probably there's even more details and possible situations than we've discussed so far. On the other hand, it is true that a single-instance-from-menu mechanism would not raise patch-compatibility issues. So you could evaluate the effect in classroom and pd community, then decide if it is worth keeping it.
By the way my own current use case for multiple instances is unrelated to the menu. I'm working on a mouse widget that communicates with a pd patch as properties dialog. In other words it uses Pd's own message system and widgets to set its properties. Some advantages of this arrangement were unexpected and I was just about to praise Pd for its self-supportiveness and flexibility when stumbling into the new no-duplicates behavior. At least for this project the issue is solved. More about it later.
And thanks for listening to pd users even under the pressure of the upcoming semester.
On 9/23/18, Miller Puckette msp@ucsd.edu wrote:
actually, it's probably not a serious problem that one can multiply open help files (if one really wants to), so probably it's not worth fixing this.
On the other hand, a naive user on a Mac would expect that clicking on a file in the "finder", if Pd already has the file open, would show the user the open file instead of opening another copy.
Supposing the "open" menu called "pd open" with the third nonzero argument, but if "pd open" acted as it does now so that one could programmatically open multiple copies of a patch, would this permit you to do what you're planning? (I think that this would be patch-level back compatible).
cheers Miller
On Sun, Sep 23, 2018 at 11:52:54AM +0200, katja wrote:
Thanks Miller for this quick yet powerful fix.
It currently operates on patches as opened from the window menu. Help patches can still be opened more than once from the contextual menu. I verified that this can be fixed by calling glob_open() instead of glob_evalfile() from open_via_helppath() in s_path.c:
glob_open(0, gensym((char*)basename), gensym(dirbuf), (t_floatarg)1);
However to make it work, the prototype of glob_open() must be declared when compiling s_path.c, otherwise the float argument is not passed correctly for some reason (while the file and dir name are, isn't that odd?)
Katja
On 9/23/18, Miller Puckette msp@ucsd.edu wrote:
Well, I ended up simply reverting to the old behavior but leaving a hook in so that users can specifically ask only to open a patch once.
cheers M
On Sun, Sep 23, 2018 at 12:10:01AM +0200, Antoine Rousseau wrote:
Yes I realized that. So it should be something more specific. Why not a wider scope object, like [pdconfig], that would take "once" as an argument?
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
Le sam. 22 sept. 2018 ?? 23:55, Roman Haefeli reduzent@gmail.com a ??crit :
On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
Of course [once] would be much better than [lock]....
[once] is taken by iemlib. Not that I think every library in existence should be considered regarding name conflicts when introducing new objects to Pd, but I feel that [once] is in wide use and adding a [once] with totally different behavior would be a bold move.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Antoine Rousseau -
Christof Ressi -
IOhannes m zmölnig -
Ivica Bukvic -
katja -
Liam Goodacre -
Miller Puckette -
oliver -
Roman Haefeli