[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Some 3.3 work
On Dec 17, 2008, at 3:28 PM, Julian Rohrhuber wrote:
so all that is to do is:
(1) offset the ControlBusAllocator by num_audiobusses.
(2) write a macro in plugins that checks if a bus is in either of
(3) write methods Control_next_ak, Control_next_ka
caveat: this does not work with manually allocated control bus
numbers, and can break code.
yes... I think that is it... if only I could have put it so clearly
myself. My clarity skills are, currently, at a minimum (lack of
sleep due to a teething monster).
So, I think the most important thing is - are we willing to break
hard coded busses with 3.3? And, are we willing to try and change
the Audio Bus and Control Bus structure into a single Bus structure?
I imagine this will look something like this. In ServerOptions,
there will be numAudioBusses and numTotalBusses (where the number of
control busses will be numTotalBusses - numAudioBusses). Allocators
will also have to change.
If yes, I'll start working on the code and publish the diffs.
I think the only thing that will break is code where control bus ids
are hard coded (audio bus ids that are hard coded should be fine).
Since we have been urging users to use Bus or s.audioBusAllocator
and s.controlBusAlloctor, these uses in code should still work
(though the implementations will change).
I think this is a good idea, but maybe let's wait for some more
opinions on this.
The decisive question is: should we allow for control bus numbers
beginning only from numAudioBusChannels (i.e. usually starting from
128)? This (only) breaks code that uses hand coded control bus
numbers below 128.
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml