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 <[email protected]> wrote: > Can you distribute GUI plugins over Deken? > > -Jonathan > > > > On Monday, November 2, 2015 10:56 AM, me.grimm <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > > _______________________________________________ > [email protected] 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 > ____________________ > > > -- ____________________ m.e.grimm, m.f.a, ed.m. syracuse u., tc3 megrimm.net ____________________
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
