[PD] Unified Library was Re: Call for GSoC mentors! March 9th deadline!

danomatika danomatika at gmail.com
Tue Mar 17 01:13:50 CET 2009

        yeah sorry frank, i should have explained more clearly.
        i also think that no GUI is the way to go for functional
        abstractions.  that
        was the big flaw of the DIY library i did, that the function of
        abstractions was tied in with the gui component.  i did it that
        way because
        i didn't want to clutter the namespace with too many
        abstractions, and the
        thought of one abstraction for function, and then a different
        one for GUI
        was not appealing at the time.
        but now, i think that is the only way to go.  like, as you said,
        polyphony.  and then also for the many many cases in which you'd
        want to
        build your own gui for custom control.
        i do think you guys have got a really really strong system there
        rjlib.  but i was just saying that without the gui stuff, it
        doesn't exactly
        fit into being that 'all purpose building blocks' library that
        we are

This is where the pd-mtl convention makes so much sense ...

Core functionality is made into patches with an underscore at the end of
the name and the regular name is just
a gui wrapper around it.  I've started using the approach in the
rc-patches and, as Frank said before, it makes
building larger gui objects much simpler.  The right inlet takes all the
control whenever possible using name messages.

So rc-chorus~_ is a regular object and rc-chorus~ is a gui wrapper with
SSSAD.  So if you want SSSAD you use the gui.

Dan Wilcox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090317/e6849d20/attachment.htm>

More information about the Pd-list mailing list