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
--
a.