i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
-Jonathan
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
You can set paths in the preferences still. I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
.hc
-Jonathan
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
that would be so one might have a different gui look for each of their patchs. or could distribute a gui-plug specific to their patch with their patches, etc.
in my case im using the gui-plugs to make my patch look like some absrtacted, glitch, unusable mess... but then if i leave it in the standerd path every patch i would open would be like that there for if i could [declare] the path to the gui-plug then i wouldn't have to worry about it. only that one patch would have those properties....
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
i agree hence the "in patch" gui-plugin loading....
hmmmm
m
On Fri, Jan 25, 2013 at 4:01 PM, Hans-Christoph Steiner hans@at.or.at wrote:
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
You can set paths in the preferences still. I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
.hc
-Jonathan
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/25/2013 04:21 PM, me.grimm wrote:
plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
that would be so one might have a different gui look for each of their patchs. or could distribute a gui-plug specific to their patch with their patches, etc.
in my case im using the gui-plugs to make my patch look like some absrtacted, glitch, unusable mess... but then if i leave it in the standerd path every patch i would open would be like that there for if i could [declare] the path to the gui-plug then i wouldn't have to worry about it. only that one patch would have those properties....
Hmm, that would be tricky for Pd to make a GUI-plugin only apply to a single patch, but you could program that in GUI plugin itself. Use [wm stackorder .] to get the list of open windows, then go thru the list and check [wm title ], then compare that to the patchname you want to affect. Then use that to make a canvas id, and only use that canvasid to change things. ROughtly like:
foreach mytoplevel [wm stackorder .] { if {[regsub {mypatchname} [wm title $mytoplevel]]} { set tkcanvas [tkcanvas_name $mytoplevel] break } }
Now $tkcanvas is the canvas that you want. I didn't try the above code, it might have errors, but that's the idea. You can also do that in a patch itself with [hcs/window_name] and [hcs/canvas_name].
.hc
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
i agree hence the "in patch" gui-plugin loading....
hmmmm
m
On Fri, Jan 25, 2013 at 4:01 PM, Hans-Christoph Steiner hans@at.or.at wrote:
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
You can set paths in the preferences still. I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
.hc
-Jonathan
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/25/2013 04:34 PM, Hans-Christoph Steiner wrote:
On 01/25/2013 04:21 PM, me.grimm wrote:
plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
that would be so one might have a different gui look for each of their patchs. or could distribute a gui-plug specific to their patch with their patches, etc.
in my case im using the gui-plugs to make my patch look like some absrtacted, glitch, unusable mess... but then if i leave it in the standerd path every patch i would open would be like that there for if i could [declare] the path to the gui-plug then i wouldn't have to worry about it. only that one patch would have those properties....
Hmm, that would be tricky for Pd to make a GUI-plugin only apply to a single patch, but you could program that in GUI plugin itself. Use [wm stackorder .] to get the list of open windows, then go thru the list and check [wm title ], then compare that to the patchname you want to affect. Then use that to make a canvas id, and only use that canvasid to change things. ROughtly like:
foreach mytoplevel [wm stackorder .] { if {[regsub {mypatchname} [wm title $mytoplevel]]} { set tkcanvas [tkcanvas_name $mytoplevel] break } }
Now $tkcanvas is the canvas that you want. I didn't try the above code, it might have errors, but that's the idea. You can also do that in a patch itself with [hcs/window_name] and [hcs/canvas_name].
Hmm, now that i think about it, there is a better way, which would be using the <<Loaded>> event.
If you receive it:
bind all <<Loaded>> {receive_loaded %W}
proc receive_loaded {mytoplevel} { if {[regsub {mypatchname} [wm title $mytoplevel]]} { set tkcanvas [tkcanvas_name $mytoplevel] # apply your tricks here } }
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, January 25, 2013 4:01 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard
Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
You can set paths in the preferences still.
Ok, I didn't see that.
I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
By user-set, do you mean by setting the paths in Preferences from the "Edit" menu?
Also, is there a tcl variable that holds the paths that were set by a [declare], or one that holds the paths for the currently opened patches?
-Jonathan
As for the prefs pane for loading libs at startup, that is bad behavior that should be discouraged. Libs should be loaded in the patch using [import] or [declare -lib].
.hc
-Jonathan
m
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/25/2013 06:12 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, January 25, 2013 4:01 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 03:31 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: me.grimm megrimm@gmail.com To: pd_list Listserve pd-list@iem.at Cc: Sent: Friday, January 25, 2013 9:25 AM Subject: [PD] Loading Gui-Plugin in a Directory Other than in Standard
Path
i tried declare like so:
[declare -stdpath /Users/megrimm/Desktop]
but that didn't work.
is there anyway to load gui plugins other than dropping them in ~/Library/Pd , etc ?
I don't know.
Hans-- is there a translation page that shows the new way to do everything in Pd-extended that used to be done through the path and startup dialogs?
I guess first of all-- is it possible to do everything on the current release that could be done on the last, such as the behavior in question above?
You can set paths in the preferences still.
Ok, I didn't see that.
I never tested whether GUI plugins can be loaded from the user-set path because I didn't see a reason why someone would want to do that.
By user-set, do you mean by setting the paths in Preferences from the "Edit" menu?
Also, is there a tcl variable that holds the paths that were set by a [declare], or one that holds the paths for the currently opened patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the canvas-local path (ie. [path] or [declare -path]) in the GUI.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
[...]
Also, is there a tcl variable that holds the paths that were set by a [declare], or one that holds the paths for the currently opened patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the canvas-local path (ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the path of the patch that was loaded, so I think it is already desired.
-Jonathan
.hc
On 01/25/2013 06:24 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
[...]
Also, is there a tcl variable that holds the paths that were set by a [declare], or one that holds the paths for the currently opened patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the canvas-local path (ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the path of the patch that was loaded, so I think it is already desired.
Yeah, it could be useful. Its a matter of someone implementing it. I can't think of any objections. It seems to me that it would basically end up having a mirror of the t_class struct in the GUI.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:26 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 06:24 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in
Standard Path
[...]
Also, is there a tcl variable that holds the paths that were set
by a
[declare], or one that holds the paths for the currently opened
patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the
canvas-local path
(ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the path of
the
patch that was loaded, so I think it is already desired.
Yeah, it could be useful. Its a matter of someone implementing it. I can't think of any objections. It seems to me that it would basically end up having a mirror of the t_class struct in the GUI.
That was one thing that was neat about the the object-oriented GUI approach of DesireData-- you ended up with a mirror of the Pd side of things (at least it looked that way).
BTW-- I've done a little work on my "rename" hack, and it seems to work ok so far. The question is should the FUDI message that I generate look exactly like the FUDI message that triggered the event in Pd that generated the message to the gui in the first place, or does it just need to follow the FUDI syntax?
-Jonathan
.hc
On 01/25/2013 07:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:26 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 06:24 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in
Standard Path
[...]
Also, is there a tcl variable that holds the paths that were set
by a
[declare], or one that holds the paths for the currently opened
patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the
canvas-local path
(ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the path of
the
patch that was loaded, so I think it is already desired.
Yeah, it could be useful. Its a matter of someone implementing it. I can't think of any objections. It seems to me that it would basically end up having a mirror of the t_class struct in the GUI.
That was one thing that was neat about the the object-oriented GUI approach of DesireData-- you ended up with a mirror of the Pd side of things (at least it looked that way).
BTW-- I've done a little work on my "rename" hack, and it seems to work ok so far. The question is should the FUDI message that I generate look exactly like the FUDI message that triggered the event in Pd that generated the message to the gui in the first place, or does it just need to follow the FUDI syntax?
Since pd-gui --> pd is FUDI, pd --> pd-gui should be too. Then it also fits in to the 'Pure Data' idea of the same message format everywhere, including within Pd, between pd and pd-gui, in the file format, in network communication, etc.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, January 29, 2013 12:37 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 07:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:26 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in
Standard Path
On 01/25/2013 06:24 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than
in
Standard Path
[...]
Also, is there a tcl variable that holds the paths that
were set
by a
[declare], or one that holds the paths for the currently
opened
patches?
-Jonathan
Hmm, off the top of my head, I don't think you can get the
canvas-local path
(ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the
path of
the
patch that was loaded, so I think it is already desired.
Yeah, it could be useful. Its a matter of someone implementing it. I
can't
think of any objections. It seems to me that it would basically end up
having
a mirror of the t_class struct in the GUI.
That was one thing that was neat about the the object-oriented GUI approach of DesireData-- you ended up with a mirror of the Pd side of things (at
least it
looked that way).
BTW-- I've done a little work on my "rename" hack, and it
seems to work ok
so far. The question is should the FUDI message that I generate look
exactly
like the FUDI message that triggered the event in Pd that generated the
message
to the gui in the first place, or does it just need to follow the FUDI
syntax?
Since pd-gui --> pd is FUDI, pd --> pd-gui should be too. Then it also fits in to the 'Pure Data' idea of the same message format everywhere, including within Pd, between pd and pd-gui, in the file format, in network communication, etc.
Of course both messages will have the same syntax, but what about content:
pd -> pd: %x tip 1 Hello World pd -> gui: %x.c tip 1 1 Hello World
-Jonathan
.hc
On 01/29/2013 02:13 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, January 29, 2013 12:37 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/25/2013 07:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:26 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in
Standard Path
On 01/25/2013 06:24 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:17 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than
in
Standard Path
[...]
> Also, is there a tcl variable that holds the paths that
were set
by a
> [declare], or one that holds the paths for the currently
opened
patches?
> > -Jonathan
Hmm, off the top of my head, I don't think you can get the
canvas-local path
(ie. [path] or [declare -path]) in the GUI.
Someone wanted to search whatever libs they had loaded, or in the
path of
the
patch that was loaded, so I think it is already desired.
Yeah, it could be useful. Its a matter of someone implementing it. I
can't
think of any objections. It seems to me that it would basically end up
having
a mirror of the t_class struct in the GUI.
That was one thing that was neat about the the object-oriented GUI approach of DesireData-- you ended up with a mirror of the Pd side of things (at
least it
looked that way).
BTW-- I've done a little work on my "rename" hack, and it
seems to work ok
so far. The question is should the FUDI message that I generate look
exactly
like the FUDI message that triggered the event in Pd that generated the
message
to the gui in the first place, or does it just need to follow the FUDI
syntax?
Since pd-gui --> pd is FUDI, pd --> pd-gui should be too. Then it also fits in to the 'Pure Data' idea of the same message format everywhere, including within Pd, between pd and pd-gui, in the file format, in network communication, etc.
Of course both messages will have the same syntax, but what about content:
pd -> pd: %x tip 1 Hello World pd -> gui: %x.c tip 1 1 Hello World
I think that when messages have the same content, they should be exactly the same in either direction.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, February 1, 2013 2:54 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in Standard Path
On 01/29/2013 02:13 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Tuesday, January 29, 2013 12:37 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than in
Standard Path
On 01/25/2013 07:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Friday, January 25, 2013 6:26 PM Subject: Re: [PD] Loading Gui-Plugin in a Directory Other than
[...]
Of course both messages will have the same syntax, but what about content:
pd -> pd: %x tip 1 Hello World pd -> gui: %x.c tip 1 1 Hello World
I think that when messages have the same content, they should be exactly the same in either direction.
I thought the same thing. In the case of "tip" it suggests a redesign-- separating out the "autotips" from the manual tips (which is probably a good idea anyway). But in terms of this plugin, I could just make two separate methods available-- "tip" and "autotip" instead of using an arg, then the message content for "tip" would be the same between pd and the gui.
-Jonathan
.hc
-
Hans-Christoph Steiner -
Jonathan Wilkes -
me.grimm