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
Le 10/11/2014 19:44, Alessio Degani a écrit :
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
This method works pretty good nowadays indeed, sorry to not put explanation comments, but I can give some clues...
We create [dac~ n] (n is channel number) in a subpatch protected with $0 variable in subpatch name.
Instance specific dynamic patching is explained here but this is a bit old:
http://puredata.info/docs/tutorials/TipsAndTricks#instance-specific-dynamic-...
Now we can put $0 at the middle of a name, then [makefilename] method becomes obsolete.
I don't think we would go on mem alloc issues by doing simple things like this, it might happen on huge dynamic creation but I never encountered this, maybe someone that knows better pd core would give more accurate answers.
Also, I've made it fast and figured out that [t b b]-[$1] is useless, you can directly connect [loadbang] to [pack $0 $1].
Look at internal messages to know more about dynamic patching:
On 10/11/2014 21:20, patrice colet wrote:
This method works pretty good nowadays indeed, sorry to not put explanation comments, but I can give some clues...
We create [dac~ n] (n is channel number) in a subpatch protected with $0 variable in subpatch name.
Perfect! The only thing that I've noticed is that everytime I change the channel argument, in the subpatch I've that $0=$0+1 I think because a new dynamic patch is created... but I think that should not be an issue... at least in the real use case where the channel is selected once at the "init"
Instance specific dynamic patching is explained here but this is a bit old:
http://puredata.info/docs/tutorials/TipsAndTricks#instance-specific-dynamic-...
Thanks, now it's perfectly clear the meaning of the message block... It's quite easy, but I was not familiar with dynamic patching! :)
[CUT]
Also, I've made it fast and figured out that [t b b]-[$1] is useless, you can directly connect [loadbang] to [pack $0 $1].
True, but I've already modified that part of the patch in order to select a default channel if no argument is supplyed!
Thank you Patrice! :)
Le 10/11/2014 22:13, Alessio Degani a écrit :
True, but I've already modified that part of the patch in order to select a default channel if no argument is supplyed!
Oupse indeed! I forgot the default arg, which was the main request... A corrected patch is attached.