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 these ranges(3) write methods Control_next_ak, Control_next_kacaveat: 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 archive: https://listarc.bham.ac.uk/marchives/sc-dev/ search: https://listarc.bham.ac.uk/lists/sc-dev/search/