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 the 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, for 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 with 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 discussing.
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 danomatika.com robotcowboy.com
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list