On Wed, Jul 29, 2009 at 11:52 AM, Scott Wilson
<s.d.wilson.1@xxxxxxxxxx> wrote:
Isn't sendsSignalTo effectively just a synonym for moveAfter then?
moveAfter is not persistent, but sendsSignalTo would be.
b.moveAfter(a);
a.moveToTail(s); // now b is before a and we have no way to repair it automatically
but...
b.receivesSignalFrom(a); // (the reverse method for mixerchannel)
a.moveToTail(s); // order is broken
Node.reorder; // hypothetical method that would fix the node ordering
This is something we should proceed with very carefully I think. The danger of making too many assumptions about how people will work is pretty high I'd guess. To 'light-weight' and 'in line with current object-style usage' I'd add 'surprisingly elegant' as a good criterion. Like observer pattern elegant.
Agreed.
Sciss -- MixerChannel doesn't optimize bus usage because every MixerChannel owns its set of audio buses.
That goes nicely with Scott's point about a decorator -- some users might want to manage bus usage themselves, and would need only a minimal node order-er. A different node order manager could take on the full DAG topological sorting and bus optimization.
hjh