Hello,
say i have [repeat] in older patches but now i want to substitute this, for example, for my own [num.repeat] vanilla abstraction without changing original patch. can this be done with gui-plugin?
i am noticing since moving from pdx that its quite a pain to replace once relied upon pdx objects with others that have same functions even with perl/sed scripts in tips_and_tricks.
if ability to substitute directly with plugin then custom user libs could draw from only needed objects from pdx based patches i was thinking....
cheers m
I think it makes more sense to do those substitutions on the level of the library loading mechanism than in the GUI.
In your example, what I would want is to put an abstraction called [repeat] in the same directory as my patch. Inside my [repeat] abstraction I'd have a [num.repeat]. Then when I load the patch I would want Pd to load my abstraction instead of loading any external by the same name. That's a much easier process because it doesn't require any changes to the original patch.
Pd doesn't work that way currently, but IIUC it would work this way using IOhannes' recent revisions to the loader mechanism. For more complex cases maybe a massive search/replace is necessary, but I'd still prefer your sed/awk approach to massive search/replace in a running patch. It's just way safer to substitute "foo" for "bar" when you know there aren't side effects like memory allocation of associated objects, binding-symbols, class search, socket traffic, GUI redrawing, maybe even forgetting that audio was running the whole time, etc. -Jonathan
On Sunday, November 1, 2015 5:10 PM, me.grimm <megrimm@gmail.com> wrote:
Hello, say i have [repeat] in older patches but now i want to substitute this, for example, for my own [num.repeat] vanilla abstraction without changing original patch. can this be done with gui-plugin? i am noticing since moving from pdx that its quite a pain to replace once relied upon pdx objects with others that have same functions even with perl/sed scripts in tips_and_tricks. if ability to substitute directly with plugin then custom user libs could draw from only needed objects from pdx based patches i was thinking.... cheersm _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
ok got it... thanks for info!
yeah i was also thinking something like this might be useful for abbreviations for example [mfn] creates [makefilename]
so looking here: https://puredata.info/docs/guiplugins/GUIPlugins
what would be the use of say "set sys_searchpath {}" or "set startup_flags {}" which should be library level loading not GUI according to your logic no? but then again it would load paths prior to user patching which seems to make sense. Or might there be a difference between substitutions in real-time while patching and initializing a path when a gui-plugin loads....
i am aware i am rambling at this point because i am just trying to understand a little more of what IS possible with a gui-plug, what is not possible, or what IS possible but is unnecessary.
a real world case scenario is class room situation (i am dealing with it this semester) where at one point in the past I just made students install pdx and we were all on the same page. it becomes difficult to troubleshoot when each student has something slightly different going on. so my idea was to have some kind of master gui-plug + class lib they just drop in ~/Library/Pd and we all Rock & Roll to the same beat...
i believe deken (can we all agree this is awesome!) solves a number of probs of this sort in the wake of pdx demise BUT it is only for libs NOT for other standardizations that might make it easier to teach.... but then again maybe object abbreviations or substitutions would just make more complications.
cheers m
On Sun, Nov 1, 2015 at 10:19 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I think it makes more sense to do those substitutions on the level of the library loading mechanism than in the GUI.
In your example, what I would want is to put an abstraction called [repeat] in the same directory as my patch. Inside my [repeat] abstraction I'd have a [num.repeat]. Then when I load the patch I would want Pd to load my abstraction instead of loading any external by the same name. That's a much easier process because it doesn't require any changes to the original patch.
Pd doesn't work that way currently, but IIUC it would work this way using IOhannes' recent revisions to the loader mechanism.
For more complex cases maybe a massive search/replace is necessary, but I'd still prefer your sed/awk approach to massive search/replace in a running patch. It's just way safer to substitute "foo" for "bar" when you know there aren't side effects like memory allocation of associated objects, binding-symbols, class search, socket traffic, GUI redrawing, maybe even forgetting that audio was running the whole time, etc.
-Jonathan
On Sunday, November 1, 2015 5:10 PM, me.grimm megrimm@gmail.com wrote:
Hello,
say i have [repeat] in older patches but now i want to substitute this, for example, for my own [num.repeat] vanilla abstraction without changing original patch. can this be done with gui-plugin?
i am noticing since moving from pdx that its quite a pain to replace once relied upon pdx objects with others that have same functions even with perl/sed scripts in tips_and_tricks.
if ability to substitute directly with plugin then custom user libs could draw from only needed objects from pdx based patches i was thinking....
cheers m
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Can you distribute GUI plugins over Deken? -Jonathan
On Monday, November 2, 2015 10:56 AM, me.grimm <megrimm@gmail.com> wrote:
ok got it... thanks for info! yeah i was also thinking something like this might be useful for abbreviations for example [mfn] creates [makefilename] so looking here: https://puredata.info/docs/guiplugins/GUIPlugins what would be the use of say "set sys_searchpath {}" or "set startup_flags {}" which should be library level loading not GUI according to your logic no? but then again it would load paths prior to user patching which seems to make sense. Or might there be a difference between substitutions in real-time while patching and initializing a path when a gui-plugin loads.... i am aware i am rambling at this point because i am just trying to understand a little more of what IS possible with a gui-plug, what is not possible, or what IS possible but is unnecessary. a real world case scenario is class room situation (i am dealing with it this semester) where at one point in the past I just made students install pdx and we were all on the same page. it becomes difficult to troubleshoot when each student has something slightly different going on. so my idea was to have some kind of master gui-plug + class lib they just drop in ~/Library/Pd and we all Rock & Roll to the same beat... i believe deken (can we all agree this is awesome!) solves a number of probs of this sort in the wake of pdx demise BUT it is only for libs NOT for other standardizations that might make it easier to teach.... but then again maybe object abbreviations or substitutions would just make more complications. cheersm On Sun, Nov 1, 2015 at 10:19 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I think it makes more sense to do those substitutions on the level of the library loading mechanism than in the GUI.
In your example, what I would want is to put an abstraction called [repeat] in the same directory as my patch. Inside my [repeat] abstraction I'd have a [num.repeat]. Then when I load the patch I would want Pd to load my abstraction instead of loading any external by the same name. That's a much easier process because it doesn't require any changes to the original patch.
Pd doesn't work that way currently, but IIUC it would work this way using IOhannes' recent revisions to the loader mechanism. For more complex cases maybe a massive search/replace is necessary, but I'd still prefer your sed/awk approach to massive search/replace in a running patch. It's just way safer to substitute "foo" for "bar" when you know there aren't side effects like memory allocation of associated objects, binding-symbols, class search, socket traffic, GUI redrawing, maybe even forgetting that audio was running the whole time, etc. -Jonathan
On Sunday, November 1, 2015 5:10 PM, me.grimm <megrimm@gmail.com> wrote:
Hello, say i have [repeat] in older patches but now i want to substitute this, for example, for my own [num.repeat] vanilla abstraction without changing original patch. can this be done with gui-plugin? i am noticing since moving from pdx that its quite a pain to replace once relied upon pdx objects with others that have same functions even with perl/sed scripts in tips_and_tricks. if ability to substitute directly with plugin then custom user libs could draw from only needed objects from pdx based patches i was thinking.... cheersm _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
interesting....
does "foo-plugin.tcl" end up at pd folder root? i thought it sticks it in a folder "~/Library/Pd/foo-plugin/foo-plugin.tcl" where in this case Pd would not find off the bat eh?
so really anything can be distributed via deken hence the "security" discussion a couple weeks back.
so in dutch deken stands for.... blanket?
:) m
On Mon, Nov 2, 2015 at 12:11 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Can you distribute GUI plugins over Deken?
-Jonathan
On Monday, November 2, 2015 10:56 AM, me.grimm megrimm@gmail.com wrote:
ok got it... thanks for info!
yeah i was also thinking something like this might be useful for abbreviations for example [mfn] creates [makefilename]
so looking here: https://puredata.info/docs/guiplugins/GUIPlugins
what would be the use of say "set sys_searchpath {}" or "set startup_flags {}" which should be library level loading not GUI according to your logic no? but then again it would load paths prior to user patching which seems to make sense. Or might there be a difference between substitutions in real-time while patching and initializing a path when a gui-plugin loads....
i am aware i am rambling at this point because i am just trying to understand a little more of what IS possible with a gui-plug, what is not possible, or what IS possible but is unnecessary.
a real world case scenario is class room situation (i am dealing with it this semester) where at one point in the past I just made students install pdx and we were all on the same page. it becomes difficult to troubleshoot when each student has something slightly different going on. so my idea was to have some kind of master gui-plug + class lib they just drop in ~/Library/Pd and we all Rock & Roll to the same beat...
i believe deken (can we all agree this is awesome!) solves a number of probs of this sort in the wake of pdx demise BUT it is only for libs NOT for other standardizations that might make it easier to teach.... but then again maybe object abbreviations or substitutions would just make more complications.
cheers m
On Sun, Nov 1, 2015 at 10:19 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
I think it makes more sense to do those substitutions on the level of the library loading mechanism than in the GUI.
In your example, what I would want is to put an abstraction called [repeat] in the same directory as my patch. Inside my [repeat] abstraction I'd have a [num.repeat]. Then when I load the patch I would want Pd to load my abstraction instead of loading any external by the same name. That's a much easier process because it doesn't require any changes to the original patch.
Pd doesn't work that way currently, but IIUC it would work this way using IOhannes' recent revisions to the loader mechanism.
For more complex cases maybe a massive search/replace is necessary, but I'd still prefer your sed/awk approach to massive search/replace in a running patch. It's just way safer to substitute "foo" for "bar" when you know there aren't side effects like memory allocation of associated objects, binding-symbols, class search, socket traffic, GUI redrawing, maybe even forgetting that audio was running the whole time, etc.
-Jonathan
On Sunday, November 1, 2015 5:10 PM, me.grimm megrimm@gmail.com wrote:
Hello,
say i have [repeat] in older patches but now i want to substitute this, for example, for my own [num.repeat] vanilla abstraction without changing original patch. can this be done with gui-plugin?
i am noticing since moving from pdx that its quite a pain to replace once relied upon pdx objects with others that have same functions even with perl/sed scripts in tips_and_tricks.
if ability to substitute directly with plugin then custom user libs could draw from only needed objects from pdx based patches i was thinking....
cheers m
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- ____________________ m.e.grimm, m.f.a, ed.m. syracuse u., tc3 megrimm.net ____________________
oh your right my mistake. i was under assumption the plugin needed to be in standard path (not in subfolder) but i see now that is not the case.....
m
On Mon, Nov 2, 2015 at 1:32 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 11/02/2015 06:44 PM, me.grimm wrote:
interesting....
does "foo-plugin.tcl" end up at pd folder root? i thought it sticks it
in a
folder "~/Library/Pd/foo-plugin/foo-plugin.tcl" where in this case Pd
would
not find off the bat eh?
how come?
mfgdsar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmölnig -
Jonathan Wilkes -
me.grimm