but anyway, I have a few doubts how [clone] would deal with internals, and this is just a rough idea so far, and we'll have to better discuss this when time is right...
for instance, how would someone deal with arguments?
Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which takes multichannel signals and distributes them from channel 1.
In clone, I need a damn simple abstraction with [inlet~] going into [dac~ $1], and I use the '-di' flag to distribute multichannel input and '-s 1' so '$1' gets values starting from 1. It works great, I also have an argument in [clone] for the number of abstractions that in this case represents maximum channels.
So, being able to call internal objects inside [clone] saves us the need to write a simple abstraction for this or any other object, which is good, but how would I be able to set the argument of [dac~] in [clone] and have it receive the instance number? That's something to think about, because simply calling "dac~" instead of an abstraction name doesn't or shouldn't do it.
Now, I can and will gladly code an abstraction that mimics MAX's [mc.dac~] in ELSE (actually I have already, just to test these things). The abstraction uses [clone] internally and uses yet another abstraction with [dac~] inside, so the user just needs to call the abstraction name. With what we have, someone can make a library with all internals and whatever more externals they like in a similar fashion. It's great that the doors are opened for this and that we can go crazy. It would also be nice that we didn't have to worry about this and have our "wrapper object". If not into [clone], maybe a new object, why not call it [mc~]? I think such a new object is needed because it might be hard to expand [clone] to do more things than it's doing. this [mc~] object than takes object names as an argument, and further arguments according to the objects argument. This [mc~] object would be similar to [clone] and create inlets/outlets according to the given object name and we'd have a way to use them to set all copies or each of them.
Maybe "mc.dac~" is a special case... let's think of a [lop~] object, we wouldn't really need to specify "$1" as an argument... it doesn't make much sense. It does make sense to maybe use a cutoff argument for all copies though, so you could have [mc~ lop~ 500] and all signal inputs get filter at 500hz. For [dac~], the special case, we could give it $1 as an argument and it would mean instance number, and a similar flag '-s 1' could set it, so we'd have [mc~ -s 1 dac~ $1].
well, I guess that's it, I'm tired and going to bed
cheers and good night