paulrussell wrote:on the original video, which started the thread, I demonstrated how VC-64 didn't work. But Noel pointed out to me that I hadn't used the 'key' button. Doh!
hey Paul it would be really good if you could try the server version using two computers, since you hve Sonar X1. In my tests, 8.5.3, still has a buffering issue which increases Sonar's CPU. Basically the server is not usable in 8.5.3. So I'd like to see if this buffering issue persists in the latest release. It seems they tackled side-chaining as you said so who knows.
update: au version based on a couple of busses is not straightforward. It requires at least a couple of weeks for a basic tested implementation. The main issue is that we are not using frameworks like juce or similar, and we don't have native patches tested for multi-bus, but we should change apple code and test it again.
An other important thing to say, it seems like AU is managing multiple busses indipendently, which makes our existing code useless (at the moment we are managing synchronized input and output channels, and believe me, it's already a COMPLEX piece of code). I can't confirm it immediatly (I should play a bit with their renderbus method on different hosts), but in such case I'm not sure we'll release it now, we chould postpone the development. I don't want overcomplicated code, because we should add a lot of features and I don't like new constraints. An indipendant bus could add a new ugly constraint to our architecture, creating early issues on incoming new develpments. I don't want to add bugs to all versions just because this au madness. I hope you understand.
ok, I should give up. Other developments are urgent and I can't spend too much time on this AU mess. Explanation is simple: RenderBus (core audio) processes busses indipendently. I'm not sure that you could pull all inputs as soon as you receive a request on a single bus, and I should test all hosts.
This doesn't fit with our current architecture, and could lead to new bugs, and I can't start hunting bugs again now (we just completed a bug hunting cycle, and I'm pretty tired). If nebula was a compressor it would be a simple thing, but nebula is NOT a compressor, and our process subroutine is waaaay to much complex for a quick changement, because we should take in account all possible combinations of processing buffers, threading, mutexes....
So today we'll release a new version for all platforms and that's all.
I don't think they will change anything. Anyway this is a clear trouble of them. They are not respecting their own specifications. We are creating a plug with 4 inputs and 2 outputs.... we should not be forced to support multiple busses, especially because their examples and base classes are not supporting them and because this convoluted approach requires additional logic and headaches.
They should support all kind of possible routing to the standard basic configuration. Fair enough.