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?

2»

Comments

  • j_liljedahlj_liljedahl

    @NeonSilicon said:

    @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.

    I see. AUM currently does not look at an AU's channelCapabilities, and just tries a stereo config. But it should not hang if the config was not accepted by the AU. Did you try this with the recent version?

    Using channelCapabilities would require the user to start loading of a plugin before getting to choose between mono/stereo. It would be nicer if it could be queried without instantiating it, perhaps via the app extension Info.plist. I don't think there's any standard for that though.

  • NeonSiliconNeonSilicon

    @j_liljedahl said:

    @NeonSilicon said:

    @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.

    I see. AUM currently does not look at an AU's channelCapabilities, and just tries a stereo config. But it should not hang if the config was not accepted by the AU. Did you try this with the recent version?

    No, this was definitely on older versions of all the hosts I tested in. Since it became pretty obvious to me that stereo-stereo processing was the de facto standard on iOS, I changed the AU's I was working to support it and just went with it for the things I've worked on since. It would be pretty easy for me to test this again but I haven't seen the need to.

    Using channelCapabilities would require the user to start loading of a plugin before getting to choose between mono/stereo. It would be nicer if it could be queried without instantiating it, perhaps via the app extension Info.plist. I don't think there's any standard for that though.

    Yeah, it's definitely not ideal. I don't know of any other way to do it though. That's part of the reason that I think the macOS based hosts do some scanning and caching to get this info. The other reason I think they might do this is the AU validation tool thing on macOS and the way it get's used. I am just guessing here though. I should do some more investigation. It might be helpful for me to attach a debugger to the channelCapabilities property of a test AU and mess with the version numbers and see when it gets called.

  • j_liljedahlj_liljedahl

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @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.

    I see. AUM currently does not look at an AU's channelCapabilities, and just tries a stereo config. But it should not hang if the config was not accepted by the AU. Did you try this with the recent version?

    No, this was definitely on older versions of all the hosts I tested in. Since it became pretty obvious to me that stereo-stereo processing was the de facto standard on iOS, I changed the AU's I was working to support it and just went with it for the things I've worked on since. It would be pretty easy for me to test this again but I haven't seen the need to.

    Using channelCapabilities would require the user to start loading of a plugin before getting to choose between mono/stereo. It would be nicer if it could be queried without instantiating it, perhaps via the app extension Info.plist. I don't think there's any standard for that though.

    Yeah, it's definitely not ideal. I don't know of any other way to do it though. That's part of the reason that I think the macOS based hosts do some scanning and caching to get this info. The other reason I think they might do this is the AU validation tool thing on macOS and the way it get's used. I am just guessing here though. I should do some more investigation. It might be helpful for me to attach a debugger to the channelCapabilities property of a test AU and mess with the version numbers and see when it gets called.

    However, I think a way to do it would be to allow the user to set a preferred stereo/mono config before selecting AU's to load, and only when loading it would check if the AU could be instantiated with that config or not. It wouldn't even need to check channelCapabilities, it could just try and see if allocateRenderResources fails or not. (Since I guess most iOS AU's out there in the wild does not set channelCapabilities..)

  • NeonSiliconNeonSilicon

    @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @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.

    I see. AUM currently does not look at an AU's channelCapabilities, and just tries a stereo config. But it should not hang if the config was not accepted by the AU. Did you try this with the recent version?

    No, this was definitely on older versions of all the hosts I tested in. Since it became pretty obvious to me that stereo-stereo processing was the de facto standard on iOS, I changed the AU's I was working to support it and just went with it for the things I've worked on since. It would be pretty easy for me to test this again but I haven't seen the need to.

    Using channelCapabilities would require the user to start loading of a plugin before getting to choose between mono/stereo. It would be nicer if it could be queried without instantiating it, perhaps via the app extension Info.plist. I don't think there's any standard for that though.

    Yeah, it's definitely not ideal. I don't know of any other way to do it though. That's part of the reason that I think the macOS based hosts do some scanning and caching to get this info. The other reason I think they might do this is the AU validation tool thing on macOS and the way it get's used. I am just guessing here though. I should do some more investigation. It might be helpful for me to attach a debugger to the channelCapabilities property of a test AU and mess with the version numbers and see when it gets called.

    However, I think a way to do it would be to allow the user to set a preferred stereo/mono config before selecting AU's to load, and only when loading it would check if the AU could be instantiated with that config or not. It wouldn't even need to check channelCapabilities, it could just try and see if allocateRenderResources fails or not. (Since I guess most iOS AU's out there in the wild does not set channelCapabilities..)

    This sounds like a reasonable approach to me. It might be a problem if some AU's don't check the channel configurations on the busses in allocateRenderResources. Maybe a check on channelCapabilities before you do allocateRenderResources to catch those that do set the channelCapabilities param would help. Checking in the debugger on the default value of channelCapabilities before I set it I get that it is set to nil. So, if you see a nil value you could try doing the allocate call and see if it passes. I think you are right that there are going to be AU's on iOS that don't set the parameter, but those that are coming over from macOS should.

    I've been doing some sifting through the AVFoundation header files and come across something that is related and indicates why this is more common on macOS hosts. On macOS, AVAudioUnitComponent has a call, supportsNumberInputChannels(_:outputChannels:) -> Bool, that isn't available on iOS and there is a parameter passesAUVal that is also not available on iOS. So, I'm guessing that the reason that it is more painful on the iOS side is the lack of the auval tool.

  • j_liljedahlj_liljedahl

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @j_liljedahl said:

    @NeonSilicon said:

    @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.

    I see. AUM currently does not look at an AU's channelCapabilities, and just tries a stereo config. But it should not hang if the config was not accepted by the AU. Did you try this with the recent version?

    No, this was definitely on older versions of all the hosts I tested in. Since it became pretty obvious to me that stereo-stereo processing was the de facto standard on iOS, I changed the AU's I was working to support it and just went with it for the things I've worked on since. It would be pretty easy for me to test this again but I haven't seen the need to.

    Using channelCapabilities would require the user to start loading of a plugin before getting to choose between mono/stereo. It would be nicer if it could be queried without instantiating it, perhaps via the app extension Info.plist. I don't think there's any standard for that though.

    Yeah, it's definitely not ideal. I don't know of any other way to do it though. That's part of the reason that I think the macOS based hosts do some scanning and caching to get this info. The other reason I think they might do this is the AU validation tool thing on macOS and the way it get's used. I am just guessing here though. I should do some more investigation. It might be helpful for me to attach a debugger to the channelCapabilities property of a test AU and mess with the version numbers and see when it gets called.

    However, I think a way to do it would be to allow the user to set a preferred stereo/mono config before selecting AU's to load, and only when loading it would check if the AU could be instantiated with that config or not. It wouldn't even need to check channelCapabilities, it could just try and see if allocateRenderResources fails or not. (Since I guess most iOS AU's out there in the wild does not set channelCapabilities..)

    This sounds like a reasonable approach to me. It might be a problem if some AU's don't check the channel configurations on the busses in allocateRenderResources. Maybe a check on channelCapabilities before you do allocateRenderResources to catch those that do set the channelCapabilities param would help. Checking in the debugger on the default value of channelCapabilities before I set it I get that it is set to nil. So, if you see a nil value you could try doing the allocate call and see if it passes. I think you are right that there are going to be AU's on iOS that don't set the parameter, but those that are coming over from macOS should.

    Sure, that sounds like the safest way. However, setting channelCapabilities is optional (as far as I know), while checking that the bus format is supported in allocateRenderResources is not optional - a plugin that doesn't do that will be considered buggy until fixed!

    I've been doing some sifting through the AVFoundation header files and come across something that is related and indicates why this is more common on macOS hosts. On macOS, AVAudioUnitComponent has a call, supportsNumberInputChannels(_:outputChannels:) -> Bool, that isn't available on iOS and there is a parameter passesAUVal that is also not available on iOS. So, I'm guessing that the reason that it is more painful on the iOS side is the lack of the auval tool.

    Ah, good find!

  • 0tolerance4silence0tolerance4silence

    @brambos
    Would it be possible (UI & technically) to add main out to multiout version of Ruismakers, so it's switchable instead of 'all or nothing'
    In most cases I don't need all outputs only 1-2 and looking for ways to reduce channel count.

  • 0tolerance4silence0tolerance4silence

    Actually never mind, sorry :)
    I guess you would have gone that route in the first place if it wouldn't require too much rework...

Sign In or Register to comment.