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.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
