Great to keep the branch up-to-date, but why not choose merge strategy instead of rebase? While rebase is great on strictly local branches, to keep the history clean, it is not very good practice on remote branches. It can in fact cause quite some headaches
Excellent work on the reworked APIs btw! Iām monitoring closely, but did not yet find time to do any real tests. Looking to do this shortly.
OK. Finally managed to force push this now. You probably need to delete the experimental/multibus branch and re-pullā¦ sorry. Every time I think I have understood git, it bites me in the back.
that was done in commit 06930cd70acbc0f2f02d269f22525e9e23fce215 on the old branch, is not there any more: the classes and method names in the new tip seem to have reverted to BusesLayouts (plural layouts) which, for the reasons I have written some posts above, sounds wrongā¦
As a plugin, how do I tell which channel layout am I in?
I mean after the user choose the configuration (Stereo, multiout) in Logic. How do I know which mode am I in, because it looks like there are always the max channel number of output buffers coming into process method.
I think the multibus branch is no longer compatible with Projucer from develop branch (problems with VST #includes). So perhaps time to integrate develop via a merge operation again?
Some compiler warnings in VS2013 that probably needs fixing:
1>juce_AudioProcessor.h(472): warning C4512: 'juce::AudioProcessor::AudioProcessorBus' : assignment operator could not be generated
juce_audio_processors\processors/juce_AudioProcessor.h(340) : see declaration of 'juce::AudioProcessor::AudioProcessorBus'
You said you liked my proposal for the BusHandle class a few posts above, but it doesnāt seem it has been implemented yet.
Since it is not a behavioral change but it affects the methodās signatures, maybe itās better to put in the little extra effort to implement that prior to merging in develop, so that method signatures wonāt change after the merge.
Also, in AudioProcessor there are a couple of nested classes (AudioProcessorBus, AudioBusesLayout, AudioBusProperties, etc.) in which the āAudioā prefix is, in my opinion, redundant because itās already implied in the fact that AudioProcessor is the containing class.
In fact, I think that replacing them with AudioProcessor::ProcessorBus (or even AudioProcessor::Bus in this case), AudioProcessor::BusesLayout, AudioProcessor::BusProperties would still be descriptive enough, while shortening the client code (hence improving its readability)
Hi yfede, I tried a version of your proposal but it got quite convoluted as it added yet another subclass. For such a class to be useful, it would be good for it to have some convenient methods which resulted in lots of repeated code. So I then tried a version with AudioProcessorBus essentially just being a āhandleā - i.e. it only stores the processor, direction and index (the latter two were combined into one int32). That was nice as it was possible to use the handle as an iterator and passing it by value - but overall things like ownership and life-time got even more confusing. So I undid all my changes again and kept the current version.