On 10/11/2014 19:12, patrice colet wrote:
hi
Le 10/11/2014 18:36, Alessio Degani a écrit :
[CUT] I've temporarily resolved this using throw~, since the throw object accept the message [set bus_name(, but in this way, I'm forced to create the correspondant [catch~ bus_name] and link them to a given [dac~ channel_num]. And I don't want this! :)
why don't you want this?
Mainly beacuse of design purposes. The abstraction needs "to be the DAC" itself. Furthermore, it is designed to work out-of-the-box. With my workaround, the user must create all of the catch~ objects and link them to a specified dac~ channel. Otherwise, I can create another abstraction that contains all catch~ and dac~ and "force" the user to put that abstraction in its own projects, but is not my goal!
Basically, I need a procedure to set the dac~ channel during the init of an abstraction to $1 if passed or to default_channe il $1 is not passed.
there is a way with dynamic patching, dac~ could be created at abstraction init with default arg, if you don't know how to do this I've attached an example
Thank you Patrice! The attached patch do exactly what I want! It's a little bit tricky to understand what exactly the patch does but it simply works.
Are there some drawbacks when using this approach to dynamic dac~ channel allocation? (i.e. unhandled exceptions, memory allocation, overhead, ...)
Bests