[PD] multiple instances of a patch forbidden in 0.49, why?

[katja]

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 at 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 at 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 at 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 at lists.iem.at mailing list
>> >> > UNSUBSCRIBE and account-management ->
>> >> > https://lists.puredata.info/listinfo/pd-list
>> >> >
>> >
>> >> _______________________________________________
>> >> Pd-list at lists.iem.at mailing list
>> >> UNSUBSCRIBE and account-management ->
>> >> https://lists.puredata.info/listinfo/pd-list
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Pd-list at lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> > https://lists.puredata.info/listinfo/pd-list
>> >
>>
>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>