On 06/22/2012 08:09 PM, Patrice Colet wrote:
Hello,
you've described explicitely the reasons why I don't use abstractions in a dynamic patching project, at least the audio part. The signal objects won't work unless you make some connections inside your abstraction, manually or with an internal message. In fact instead of dynamically creating abstractions, using internal messages for constructing all the patch should be a better approach, you can store the lines of code that is constructing the patches with [textfile], and then you can clear and reconstruct any part of the patch by using an internal message manager, that can be made with a few objects.
i see. i guess i will try that approach to dynamically create various variations of the player and then use those in production, to avoid problem with dynpatching...
Also, I don't really get why you don't use [throw~] [catch~] [send~] and [receive~] instead of [inlet~] [outlet~]
oh, i did. the reason why i'd like to use outlet~s rather than throw~ is that they make my abstraction more intuitive to use - you see the outlets and immediately know what to do. i tried another approach: a player which used only throw~s and then a separate abstraction (dynpatched to catch~ the data and funnel it into outlets), but i found that a bit awkward to use - not exactly discoverable, and who reads manuals :)