A couple of commits

[miguel-negrao]

Hi Wouter,

I have a couple of commits up for discussion. The two main features are recursive UGroups and UBus. I implemented UBus in the spirit of UGroup. Each UBus is identified by a symbol, the bus is allocated at prepare time and it is freed when the unit is disposed. It is to be used with args which have a PositiveIntegerSpec. UBus is handy for sending audio to and from UChains using UGroup. Example:

(
Udef.loadOnInit = true;
Udef(\test, { Out.ar(\bus.kr(0), SinOsc.ar([440,880])*0.1) }).setSpec(\bus, PositiveIntegerSpec() );
Udef(\out2, { Out.ar(0, In.ar(\bus.kr(0),2)) }).setSpec(\bus, PositiveIntegerSpec() );
)

(
x = UScore( 
    UChain( [\test, [\bus, UBus(\a,2) ]] ).ugroup_('default'), 
    UChain( [\out2, [\bus, UBus(\a,2)]]).ugroup_('default').addAction_(\addToTail) 
);
x.prepareAndStart
)

The rest are cosmetic improvements.

[miguel-negrao]

Hum, I'm thinking that Bus.audio might be allocating buses which UChains are using internally... have to check that.

[woutersnoei]

Hi Miguel, yes, Bus.audio assigns private buses, and it doesn't know which ones are used by the UChains internally. This problem also comes up when people mix normal SC code with ULib, especially Jitlib type of things. It could be problematic for implementing this idea. There is only a limited amount of audio buses avialable, and private bus 0-31 are already reserved for internal UChain communication. Alhough I hardly use more than 8 buses in a chain, it should still be possible to play for example a 32-channel soundfile. On the GOL system (and WFSCollider in general) also there are only 32 private buses. This is for optimization reasons; every extra audio bus costs extra cpu (times 8 for an 8 core system). So, if you would create extra buses to do the UBus thing (given that you assign them yourself) it would also cost extra CPU.

[woutersnoei]

Another thing about the UBus; instead of using PositiveIntegerSpec you would need to create an UBusSpec, which constrains values to become UBuses, and has a default UBus object. Otherwise as soon as you change anything via gui the UBus will be replaced by an Integer.

[woutersnoei]

Thinking more of this, perhaps we could actually make the allocators used by Bus.audio know which buses are used by UChains. Have to look a bit into how these things work. Although it could still be problematic if an UBus is on a bus, and then a new UChain starts using it. Another idea could be to use dynamic bus management (via Bus.audio) internally for UChains as well. We've discussed that before as it would also be needed to make ULib behave well on supernova. This would require some architectural re-thinking though..

[miguel-negrao]

Well, at least to get it working without a major rewrite UBus could have it's own bus allocator which would allocate only buses above UBus.firstBus with a sensible default value (first private bus + 32 ?) . If the user used more UChain internal buses then she could set that parameter higher. I think that would be a quick fix.

[miguel-negrao]

Or actually better, do

server.audioBusAllocator.reserve(server.options.firstPrivateBus, 32, true);

On starting ImmLib which will make sure the allocator doesn't give those buses.

[miguel-negrao]

Another thing about the UBus; instead of using PositiveIntegerSpec you would need to create an UBusSpec, which constrains values to become UBuses, and has a default UBus object. Otherwise as soon as you change anything via gui the UBus will be replaced by an Integer.

I would say the best would be to have a spec which can both accept integers or UBuses, so as to be interchangeable, so that we can use the \output udef also for this. The gui would have to be adapted for this.

[miguel-negrao]

I've refactored UBus quite a bit in the mean time, but it's still missing proper guis. I'll close this one and open another one when I have a fully working and tested solution. Btw, I also have a UGroup, UBus style version of BufSndFile which is great for loading buffers only once. It also needs polishing and proper guis, hopefully during the summer I'll have time to work on that.