[PD] questions about PD-extended 0.43 build on Mac (GUI-oriented)

Scott R. Looney scottrlooney at gmail.com
Sat Dec 31 10:07:44 CET 2011


>
> You can make your own object category menu using the attached
> category_menu plugin.  Edit menutree.tcl to customize your layout.  You can
> find out more about what you can do with plugins here:
> http://puredata.info/docs/guiplugins
>
>
> > 2. also read about key bindings-VERY interested in this as i have some
> RSI issues and shortcuts would be helpful for common tasks.
>
> You can just put the "bind" statements into a text file, name it
> mybindings-plugin.tcl.  Read thru
> Pd-extended.app/Contents/Resources/tcl/pd_bindings.tcl (inside the app) to
> see the default bindings.  There is an experimental 'quick bindings' plugin
> which lets you do more, but its rough.
>
>
> using a tiny tiny bit of programming in a plugin, you can do a ton of
> customization.  Here's some example plugins:
>

thanks a bunch for these Hans-Christoph! i've been looking at the tcl
pd_bindings file a bit earlier today. seems relatively straightforward to
bind a key to an object, although which objects can be selected and their
exact assumed path seems fuzzy to me.

for example 'bng' in the tcl file (Bang) is listed as 'bng.pd_darwin' in
pd-extended.app/Contents/Resources/extra/vanilla folder. is this the object
folder referred to by pd_bindings.tcl? more importantly, if i wanted to
create my own key binding to say, a cyclone library object like biquad~, is
the search path universal so that the app looks for a file called
'biquad~.pd_darwin' in whatever folder it needs?

as for the context menu, i would be defining both the category and
individual elements in menutree.tcl myself, right? so i define categories
like 'timing' 'math' and so on, and 'a1 b2', etc becomes the named PD
objects like 'counter line'. and we assume PD will search for them in the
same manner as the key bindings?

i like the idea of creating a local PD folder to put scripts in so that
updates don't overwrite the scripts. makes updating both convenient and
more stable, though of course the GUI scripts themselves may need to be
altered to accomodate future changes.



> Its more alpha/beta than experimental.  It should be ready for real work
> but I am sure people will still find bugs.
>

although it's early, i'm quite happy so far with what's already being done
with PD-extended, i think it's looking quite good and it's nice to know i
can get a certain amount of object similarity with Max/MSP. thanks to you
and rest of the developers for your hard work! i think PD is really growing
up in terms of user-friendliness.

scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111231/4b2d2006/attachment-0001.htm>


More information about the Pd-list mailing list