Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Multi channel AU support?

So I was looking into NYCompressor and realized it has built in side chaining support with four inputs if your host supports it. I wasn’t aware of this feature in AU. I’ve seen posts from a while ago about no hosts supporting it but has this changed?

«1

Comments

  • Not as far as I know. AUv3 has supported it from the get-go, but I’m not aware of any hosts that do.

  • That would be cool and I do wonder if it will be @LFS and the Cubasis team that will bring this AUv3 feature to us in some of the Cubasis updates scheduled for 2018 together with AUv3 Midi etc. etc.. :)

  • @Samu said:

    That would be cool and I do wonder if it will be @LFS and the Cubasis team that will bring this AUv3 feature to us in some of the Cubasis updates scheduled for 2018 together with AUv3 Midi etc. etc.. :)

    This would be a nice movement. Also for multi-output drum AU

  • @realdavidai said:
    @Samu said:

    That would be cool and I do wonder if it will be @LFS and the Cubasis team that will bring this AUv3 feature to us in some of the Cubasis updates scheduled for 2018 together with AUv3 Midi etc. etc.. :)

    This would be a nice movement. Also for multi-output drum AU

    In Cubasis I just duplicate the tracks and remove un-needed notes. They eat so little cpu anyway. Same in GarageBand. This works for me since I mostly use samples.(ie. Sample the source / sound and sequence it). This also keeps the number of apps running at the same time as low as possible.

    What I would love to see happen in Cubasis is better routing of midi and audio so one midi track could be used to drive multiple destinations and also grouping / routing of audio tracks.

  • @Samu said:

    @realdavidai said:
    @Samu said:

    That would be cool and I do wonder if it will be @LFS and the Cubasis team that will bring this AUv3 feature to us in some of the Cubasis updates scheduled for 2018 together with AUv3 Midi etc. etc.. :)

    This would be a nice movement. Also for multi-output drum AU

    In Cubasis I just duplicate the tracks and remove un-needed notes. They eat so little cpu anyway. Same in GarageBand. This works for me since I mostly use samples.(ie. Sample the source / sound and sequence it). This also keeps the number of apps running at the same time as low as possible.

    What I would love to see happen in Cubasis is better routing of midi and audio so one midi track could be used to drive multiple destinations and also grouping / routing of audio tracks.

    Yes that works. I just like the flexibily of changing MIDI rearrangements at any time, there’s just a bit more friction in doing so when the drums are spread across multiple tracks so it forces me to commit :D

  • @realdavidai said:

    Yes that works. I just like the flexibily of changing MIDI rearrangements at any time, there’s just a bit more friction in doing so when the drums are spread across multiple tracks so it forces me to commit :D

    That could work in Cubasis too if it would get proper 'midi filtering/routing'.
    Drive all instrument-instances from one midi track and make each instance listen to just a specific note.

    Can't help to think about an idea of separating control-tracks & instruments.
    Keep the instruments in a 'rack' and drive them using the controll-tracks :)

  • @Samu said:

    @realdavidai said:

    Yes that works. I just like the flexibily of changing MIDI rearrangements at any time, there’s just a bit more friction in doing so when the drums are spread across multiple tracks so it forces me to commit :D

    That could work in Cubasis too if it would get proper 'midi filtering/routing'.
    Drive all instrument-instances from one midi track and make each instance listen to just a specific note.

    Can't help to think about an idea of separating control-tracks & instruments.
    Keep the instruments in a 'rack' and drive them using the controll-tracks :)

    Good ideas. So it looks like we have some things to dream about for a few more years

  • Well, it’s mid 2019 and still no multi channel AU support...

    Fabfilter plugins are supposed to use multi input/output for sidechaining, as well as DDMF compressor, but still no single host is capable of supporting this standard AUv3 feature.

    IAA is being deprecated by Apple, so several drums apps and multitimbral synths are being/will be updated to AUv3 but no multichannel support is available in any host.

    What are devs waiting for? Is there anything that prevents them from implementing this standard AUv3 feature?

  • Chicken and eggs. That’s all.

  • @brambos
    Well, I believe there are already enough chickens then... or eggs... :)

  • @Rodolfo said:
    @brambos
    Well, I believe there are already enough chickens then... or eggs... :)

    I mean.. without hosts and plugins to test with (even without sample code from Apple) there is nothing to use the feature with for users and nothing to test with for developers. And it’s not a trivial feature to add.

  • @brambos said:

    @Rodolfo said:
    @brambos
    Well, I believe there are already enough chickens then... or eggs... :)

    I mean.. without hosts and plugins to test with (even without sample code from Apple) there is nothing to use the feature with for users and nothing to test with for developers. And it’s not a trivial feature to add.

    I perfectly understand, I’m just saying that there are enough plugins available at the moment with no host capable of providing multi channel support yet..
    I read on the Fabfilter forum that a couple of devs are already working on their hosts (maybe AUM? Cubasis?) to incorporate this feature. I hope they do, it’s something that -in my opinion- could really help IOS music apps to raise the bar to another level.

  • Are there any hosts at this point that let you do mono to stereo AU's. I have some AU's that work best in this setting and I haven't been able to test them outside my own rather hacky host I use for testing.

  • @NeonSilicon said:
    Are there any hosts at this point that let you do mono to stereo AU's. I have some AU's that work best in this setting and I haven't been able to test them outside my own rather hacky host I use for testing.

    AUM has mono to stereo node.

  • @espiegel123 said:

    @NeonSilicon said:
    Are there any hosts at this point that let you do mono to stereo AU's. I have some AU's that work best in this setting and I haven't been able to test them outside my own rather hacky host I use for testing.

    AUM has mono to stereo node.

    As far as I can tell, AUM doesn't work in the way I need. It seems to run everything as stereo, even when using a mono input channel or after the stereo-to-mono routing. What I need, is the ability to install my mono-to-stereo AU effects in the same way that this works in something like Logic.

  • If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

  • @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

  • This would be great. Main use case I can think of is routing each drum sound from a drum au to a separate channel in AB. You could then add a different fx chain to each drum sound. This would be much better than duplicating the drum au multiple times


  • N-track does have a multi route option, but the app is pretty unstable

  • @j_liljedahl any chance you have looked into adding this? In addition to side chaining. multi out for things like EG Pulse and Drambo would be great.

  • @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

  • @rezidue said:
    @j_liljedahl any chance you have looked into adding this? In addition to side chaining. multi out for things like EG Pulse and Drambo would be great.

    Multi-bus support is on my TODO, yes. This includes side-chaining.

  • @j_liljedahl said:

    @rezidue said:
    @j_liljedahl any chance you have looked into adding this? In addition to side chaining. multi out for things like EG Pulse and Drambo would be great.

    Multi-bus support is on my TODO, yes. This includes side-chaining.

    👍

  • @[Deleted User] said:

    @j_liljedahl said:

    @rezidue said:
    @j_liljedahl any chance you have looked into adding this? In addition to side chaining. multi out for things like EG Pulse and Drambo would be great.

    Multi-bus support is on my TODO, yes. This includes side-chaining.

    👍

    Can't wait!

  • edited October 2019

    @j_liljedahl said:

    @rezidue said:
    @j_liljedahl any chance you have looked into adding this? In addition to side chaining. multi out for things like EG Pulse and Drambo would be great.

    Multi-bus support is on my TODO, yes. This includes side-chaining.

    This would be a major milestone on IOS, I believe AUM should be the one to set the standard for others to follow.

  • @j_liljedahl said:

    @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

    The AU's aren't mono-to-stereo. They can run as mono-mono, mono-stereo, and stereo-stereo. So, when they are hooked up in a stereo-stereo setting, I don't know if the user really wants a mono-to-stereo signal path. I could put a control on the UI, but that would be somewhat confusing and it wouldn't give the memory efficiency that having the choice made before the allocate render resources call does.

    I understand that having AUM setup like it's a stereo mixer probably gives a cleaner architecture. I just feel that since you have the Stereo Processing inserts in the design, enabling mono paths and mono-to-stereo processing could be really useful and in some cases make for more efficient AU's. Most of the playing/recording I do personally has a purely mono path until it's placed in the final stereo field. I guess I'm probably in the minority with that usage now though.

  • @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

    The AU's aren't mono-to-stereo. They can run as mono-mono, mono-stereo, and stereo-stereo. So, when they are hooked up in a stereo-stereo setting, I don't know if the user really wants a mono-to-stereo signal path. I could put a control on the UI, but that would be somewhat confusing and it wouldn't give the memory efficiency that having the choice made before the allocate render resources call does.

    I understand that having AUM setup like it's a stereo mixer probably gives a cleaner architecture. I just feel that since you have the Stereo Processing inserts in the design, enabling mono paths and mono-to-stereo processing could be really useful and in some cases make for more efficient AU's. Most of the playing/recording I do personally has a purely mono path until it's placed in the final stereo field. I guess I'm probably in the minority with that usage now though.

    Yeah, I agree that it would be a nice optimization to allow different parts of the channel signal chain to be in actual mono. However, internally in AUM it wouldn't save much. Each audio strip reuses the same stereo buffer so there's no memory saving, and copying one buffer to another is quite cheap. But if the inserted AU plugins uses true stereo processing, it would save the processing of one extra channel of course.

    However, it would certainly complicate the architecture. For example, what happens if you drag and reorder a plugin instantiated in mono-configuration so that it becomes stereo? It would need to deinitialize the plugin and reallocate render resources. And how does the user in AUM decide if a plugin that gets feed with mono input should also output mono, or if it should output stereo?

  • @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

    The AU's aren't mono-to-stereo. They can run as mono-mono, mono-stereo, and stereo-stereo. So, when they are hooked up in a stereo-stereo setting, I don't know if the user really wants a mono-to-stereo signal path. I could put a control on the UI, but that would be somewhat confusing and it wouldn't give the memory efficiency that having the choice made before the allocate render resources call does.

    I understand that having AUM setup like it's a stereo mixer probably gives a cleaner architecture. I just feel that since you have the Stereo Processing inserts in the design, enabling mono paths and mono-to-stereo processing could be really useful and in some cases make for more efficient AU's. Most of the playing/recording I do personally has a purely mono path until it's placed in the final stereo field. I guess I'm probably in the minority with that usage now though.

    Yeah, I agree that it would be a nice optimization to allow different parts of the channel signal chain to be in actual mono. However, internally in AUM it wouldn't save much. Each audio strip reuses the same stereo buffer so there's no memory saving, and copying one buffer to another is quite cheap. But if the inserted AU plugins uses true stereo processing, it would save the processing of one extra channel of course.

    However, it would certainly complicate the architecture. For example, what happens if you drag and reorder a plugin instantiated in mono-configuration so that it becomes stereo? It would need to deinitialize the plugin and reallocate render resources. And how does the user in AUM decide if a plugin that gets feed with mono input should also output mono, or if it should output stereo?

    In most DAW like settings that allow for mono-to-stereo plugins, the user has to explicitly choose which version they want when they setup the processing chain. I can't think of any that allow for a channel to be moved from stereo down to mono either. Maybe there are some, but I can't remember seeing any. I think the only way this could possible work in AUM is if the user explicitly set it up using a Stereo Processing node. So, a mono strip is purely mono until an AUM stereo node is placed in the path. Then, only the AU that is right before the change can be stereo-to-mono. But, disabling that AU node or the user moving it would still complicate the internal processing for AUM. It would also complicate user expectation.

    I think that you are right. Allowing for mono-to-stereo AU's doesn't fit well with the free form flow of AUM and the complications it would introduce for the user would be pretty bad. I don't think it would be worth it.

    How about allowing for purely mono strips? If a strip starts and ends with a mono device (or a bus send), then every AU in the path is fixed to be mono. That would still require some UI complications either in the final mix or where a mono channel enters a send. There would need to be a pan control at those points. There would also be the possible confusion for users wondering why some AU's don't show up as a choice on some channels. The efficiency gains could be pretty big though and the UI complications probably wouldn't be too bad. I don't know how useful this would be for others, but I'd use it all the time.

    BTW, thanks for AUM! I use it all the time and the UI is wonderful to work with.

  • @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

    The AU's aren't mono-to-stereo. They can run as mono-mono, mono-stereo, and stereo-stereo. So, when they are hooked up in a stereo-stereo setting, I don't know if the user really wants a mono-to-stereo signal path. I could put a control on the UI, but that would be somewhat confusing and it wouldn't give the memory efficiency that having the choice made before the allocate render resources call does.

    I understand that having AUM setup like it's a stereo mixer probably gives a cleaner architecture. I just feel that since you have the Stereo Processing inserts in the design, enabling mono paths and mono-to-stereo processing could be really useful and in some cases make for more efficient AU's. Most of the playing/recording I do personally has a purely mono path until it's placed in the final stereo field. I guess I'm probably in the minority with that usage now though.

    Yeah, I agree that it would be a nice optimization to allow different parts of the channel signal chain to be in actual mono. However, internally in AUM it wouldn't save much. Each audio strip reuses the same stereo buffer so there's no memory saving, and copying one buffer to another is quite cheap. But if the inserted AU plugins uses true stereo processing, it would save the processing of one extra channel of course.

    However, it would certainly complicate the architecture. For example, what happens if you drag and reorder a plugin instantiated in mono-configuration so that it becomes stereo? It would need to deinitialize the plugin and reallocate render resources. And how does the user in AUM decide if a plugin that gets feed with mono input should also output mono, or if it should output stereo?

    In most DAW like settings that allow for mono-to-stereo plugins, the user has to explicitly choose which version they want when they setup the processing chain. I can't think of any that allow for a channel to be moved from stereo down to mono either. Maybe there are some, but I can't remember seeing any. I think the only way this could possible work in AUM is if the user explicitly set it up using a Stereo Processing node. So, a mono strip is purely mono until an AUM stereo node is placed in the path. Then, only the AU that is right before the change can be stereo-to-mono. But, disabling that AU node or the user moving it would still complicate the internal processing for AUM. It would also complicate user expectation.

    I think that you are right. Allowing for mono-to-stereo AU's doesn't fit well with the free form flow of AUM and the complications it would introduce for the user would be pretty bad. I don't think it would be worth it.

    How about allowing for purely mono strips? If a strip starts and ends with a mono device (or a bus send), then every AU in the path is fixed to be mono. That would still require some UI complications either in the final mix or where a mono channel enters a send. There would need to be a pan control at those points. There would also be the possible confusion for users wondering why some AU's don't show up as a choice on some channels. The efficiency gains could be pretty big though and the UI complications probably wouldn't be too bad. I don't know how useful this would be for others, but I'd use it all the time.

    BTW, thanks for AUM! I use it all the time and the UI is wonderful to work with.

    Can an AU tell the host which input/output channel configurations it supports before being hosted?

    I think it would be possible if the user would choose the configuration when instantiating a plugin. AUM could then do any stereo/mono conversion on demand as needed depending on the next node in the chain. I like the idea and will certainly think about it some more and consider it for the future!

  • @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @espiegel123 said:
    If you put your mono to stereo effect as a node below a mono node on the same channel how does this differ from what you are after?

    Maybe you could give a specific example to clarify?

    In the testing I've done, the mono node in AUM isn't mono. It runs a stereo channel with the mono hardware input copied on both the left and right channel. It never instantiates the mono-to-stereo routing on my AU. It always chooses the stereo only routing on the AU.

    Yes, AUM always runs AU plugins in stereo for both input and output. If you have a mono-to-stereo effect plugin, you can simply use only the left or right channel input.

    The AU's aren't mono-to-stereo. They can run as mono-mono, mono-stereo, and stereo-stereo. So, when they are hooked up in a stereo-stereo setting, I don't know if the user really wants a mono-to-stereo signal path. I could put a control on the UI, but that would be somewhat confusing and it wouldn't give the memory efficiency that having the choice made before the allocate render resources call does.

    I understand that having AUM setup like it's a stereo mixer probably gives a cleaner architecture. I just feel that since you have the Stereo Processing inserts in the design, enabling mono paths and mono-to-stereo processing could be really useful and in some cases make for more efficient AU's. Most of the playing/recording I do personally has a purely mono path until it's placed in the final stereo field. I guess I'm probably in the minority with that usage now though.

    Yeah, I agree that it would be a nice optimization to allow different parts of the channel signal chain to be in actual mono. However, internally in AUM it wouldn't save much. Each audio strip reuses the same stereo buffer so there's no memory saving, and copying one buffer to another is quite cheap. But if the inserted AU plugins uses true stereo processing, it would save the processing of one extra channel of course.

    However, it would certainly complicate the architecture. For example, what happens if you drag and reorder a plugin instantiated in mono-configuration so that it becomes stereo? It would need to deinitialize the plugin and reallocate render resources. And how does the user in AUM decide if a plugin that gets feed with mono input should also output mono, or if it should output stereo?

    In most DAW like settings that allow for mono-to-stereo plugins, the user has to explicitly choose which version they want when they setup the processing chain. I can't think of any that allow for a channel to be moved from stereo down to mono either. Maybe there are some, but I can't remember seeing any. I think the only way this could possible work in AUM is if the user explicitly set it up using a Stereo Processing node. So, a mono strip is purely mono until an AUM stereo node is placed in the path. Then, only the AU that is right before the change can be stereo-to-mono. But, disabling that AU node or the user moving it would still complicate the internal processing for AUM. It would also complicate user expectation.

    I think that you are right. Allowing for mono-to-stereo AU's doesn't fit well with the free form flow of AUM and the complications it would introduce for the user would be pretty bad. I don't think it would be worth it.

    How about allowing for purely mono strips? If a strip starts and ends with a mono device (or a bus send), then every AU in the path is fixed to be mono. That would still require some UI complications either in the final mix or where a mono channel enters a send. There would need to be a pan control at those points. There would also be the possible confusion for users wondering why some AU's don't show up as a choice on some channels. The efficiency gains could be pretty big though and the UI complications probably wouldn't be too bad. I don't know how useful this would be for others, but I'd use it all the time.

    BTW, thanks for AUM! I use it all the time and the UI is wonderful to work with.

    Can an AU tell the host which input/output channel configurations it supports before being hosted?

    I think it would be possible if the user would choose the configuration when instantiating a plugin. AUM could then do any stereo/mono conversion on demand as needed depending on the next node in the chain. I like the idea and will certainly think about it some more and consider it for the future!

    I haven't looked at this from the host side. I think the only call to the AU is via the channelCapabilities property. My suspicion from looking at interactions with hosts on the macOS side is that they keep a database of AU's and then look for new AU's or changed versions on launch of the host and then query the changed or new AU's at that point. I think that's also a point where some hosts will invalidate crashing AU's or AU's that don't scan for what the host needs.

    The other kinda open question is how many AU's on iOS set the channelCapabilities parameter. I haven't looked for some time now, but when I was experimenting with how the hosts worked with the AU's, almost everything assumed that the path was stereo-stereo and attempted to instantiate that way. If I set my channelCapabilities to only mono-mono, hosts would still attempt to give me a 2, 2 channel setup and the instantiation would hang if sent an error back at AU initialization. So, there could be bunches of AU's on iOS that don't specify the channelCapabilities to what they need and everything would still work OK as long as they did support stereo IO.

Sign In or Register to comment.