Multibus API

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 :slight_smile:

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.

1 Like

This rebase operation doesnā€™t seem to be visible in the public repository on github, perhaps you havenā€™t pushed it?

If you havenā€™t already, well, Iā€™m all in favor of using merge instead of rebase, like @myhrman said. Just my 2 cents

Yes Iā€™ll do merges from now on. Let me check why the rebase didnā€™t workā€¦

1 Like

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.

1 Like

Wellā€¦ something is still not good, because in the new multibus tip it seems that the rename

BusesLayouts (plural layouts) -> BusesLayout (singlular layout)

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ā€¦

Is this deliberate?

No not deliberate. Thanks for pointing this out.

OK hopefully the last two commits on experimental/multibus fixes all the issues.

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?

Yup just working on this.

1 Like

Should be working again.

1 Like

The problem with muted outputs in Cubase seems to be fixed in this branch. Great!

related thread:

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'

Now with AAX support. Iā€™ll have a look at that compiler warning.

2 Likes

Iā€™ll check this out early next week ā€“ will this work with 2/32 (2 in, 32 out)? Will it let us name the Aux Outputs?

Using the original pre JUCE 4.1 code I have the Multiouts working and named ā€œOut n - mā€.

Video (Flash required):

In Plugin: http://screencast.com/t/9IyNpvdxA

In Pro Tools menu: http://screencast.com/t/Ixxgk6LY

Thanks,

Rail

Yes. One of my test plug-ins has one stereo input and 16 stereo outputs.

If the outputs are stereo then it will come up as ā€œOut n - Lā€ and ā€œOut n - Rā€ etc.

If there are no objections then we will merge the experimental/multibus branch to develop in the next few days. So last chances to test!

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)

1 Like

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.