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.

AU effects render problems in GB

Growing concern of AU effects sounding one way during playback and then differently (or not at all) on export. My best guess is that there some kind of offline flag or API that developers are not aware of?

Here’s an example of the issue with new Filterstation 2

«1

Comments

  • Interesting--and concerning!! Would playing the audio live from GarageBand and recording the result in AUM be a workaround for this problem for now?

  • Something seems up with AU in the latest Garageband. I'm getting reports that Ripplemaker doesn't work properly with multiple instances in GB, and loads with completely bizarre default settings. I think Apple broke something with their recent update.

  • @Audiojunkie said:
    Interesting--and concerning!! Would playing the audio live from GarageBand and recording the result in AUM be a workaround for this problem for now?

    I only use AU instruments in GB because AU effects have been problematic from day 1. But if I had something worthwhile with AU I wanted to use in GB then I would probably record directly out of the audio interface into a desktop :# :)

    Curious about an AUM real-time option though.

  • @brambos said:
    Something seems up with AU in the latest Garageband. I'm getting reports that Ripplemaker doesn't work properly with multiple instances in GB, and loads with completely bizarre default settings. I think Apple broke something with their recent update.

    Interesting I thought things had become much more stable because the hard AU crashes stopped completely after the last update. Looks like there’s more work to do.

  • edited January 2018

    Have got tons of issues with AU effects during export too, especially with audio damage suite as mentioned on the other thread.

    Still possible to use interapp to connect AUM and load synths, effects and even loops in there. You will record audio. Have tested it and that works. But it’s a more complicated process for an app that should just works, especially as it’s from Apple, which are behind iaa and AU. And GB is their only iOS music app, so that should work if they want to promote iOS as a stable music platform.

    Desktop-like daw workflow is what can make GB a nice option if it’s fixed. But we still need true freeze features as this app is much more cpu intensive than AUM with AU.

  • edited January 2018

    @Janosax said:
    Have got tons of issues with AU effects during export too, especially with audio damage suite as mentioned on the other thread.

    Still possible to use interapp to connect AUM and load synths, effects and even loops in there. You will record audio. Have tested it and that works. But it’s a more complicated process for an app that should just works, especially as it’s from Apple, which are behind iaa and AU. And GB is their only iOS music app, so that should work if they want to promote iOS as a stable music platform.

    Desktop-like daw workflow is what can make GB a nice option if it’s fixed. But we still need true freeze features as this app is much more cpu intensive than AUM with AU.

    Yes for the most part I just use the default GB instruments and effects which offers a quick and easy escape route to Logic if a project gets threatened.

    So AU has become primarily a fun AUM jamming thing for me these days.

  • @realdavidai very glad that you started this post!!! We were discussing the same issue with @marcel on another thread. This issue is driving me crazy, even a glass of Jack Daniels after a fitness session of 1 hour does not help!

    So as usual I've focused on the filter demo example provided by Apple, and I have to say that is working more often that with other plugs (so I mean exporting the result of the fx and not only the dry version). But after some repetitive exports, even Filter Demo failed sometimes. I've compared every lines I've written in Maxima against Filter Demo (except for magical species of course o_O) and we are doing the same regarding basic processing bla bla bla.

    @brambos Could you please also have a look to the Filter Demo? Ps: Something strange with the sample provided by Apple, have you also noticed that they provided a new version (somewhere after September I think) and they removed it?

    I don't know who is part of the AudioDamage team in this forum, but it will be also interesting to get their feedbacks.

    I hate those kind of bug, no log, no exception, only a dry version of the signal O_O

  • edited January 2018

    I'm inclined to think that the issue is in GB. So unless the same issues pop up in one of the many other AU hosts out there I'm putting my priorities elsewhere. It's highly likely something we can't fix on our end. The fact that these issues weren't there in the previous version of GB (which I used for testing prior to releasing Ripplemaker) supports that theory ;)

  • edited January 2018

    @brambos said:
    I'm inclined to think that the issue is in GB. So unless the same issues pop up in one of the many other AU hosts out there I'm putting my priorities elsewhere. It's highly likely something we can't fix on our end. The fact that these issues weren't there in the previous version of GB (which I used for testing prior to releasing Ripplemaker) supports that theory ;)

    The issues were worse for AU effects (not instruments) in previous versions of GB in that even during real-time playback, tracks with AU would suddenly go silent until the AU was removed. This was very common. After the latest update this behavior went away.

    So probably there’s a different code path that GB uses for share/export and that’s where the bug might be. But now that GB promotes AU in the App Store this could get out-of-hand with plugins getting unnecessarily blamed.

    There’s got to be some kind of offline render flag because it was briefly mentioned by the developer when I was troubleshooting offline render issues for crudebyte Colossus Piano

  • edited January 2018

    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

  • @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

  • @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Thx! This is the workarround! I’ve also tested with Maxima and it’s rendering properly. So definitely a GB issue!

  • edited January 2018

    @FredAntonCorvest said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Thx! This is the workarround! I’ve also tested with Maxima and it’s rendering properly. So definitely a GB issue!

    Great! Now we just need to deal with those unsightly pillars on iPad 12.9 ;)

  • edited January 2018

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage Replicant 2 AU, didn’t test with other AU.

  • @realdavidai said:

    @FredAntonCorvest said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Thx! This is the workarround! I’ve also tested with Maxima and it’s rendering properly. So definitely a GB issue!

    Great! Now we just need to deal with those unsightly pillars on iPad 12.9 ;)

    Yes! ;)

  • @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

  • edited January 2018

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Can’t the cache of the renders be tackled by duplicating the project first? in other words: is the cache of the renders also duplicated? I shall try this now ...

    Edit: it didn’t work....tried it (duplicating a project which has 5 instances of Maxima active, and where only 2 of them came out wet in the song) , exporting the duplicated project without opening the project first, resulted still in 2 wet and 3 dry tracks in the song.

  • @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Weird! This thread should be maybe pinned ?

  • edited January 2018

    @Marcel said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Can’t the cache of the renders be tackled by duplicating the project first? in other words: is the cache of the renders also duplicated? I shall try this now

    Not sure. The cache is probably in the project bundle...so perhaps GB compares project time stamp with rendered file time stamp. If they are the same it just shoots out the same rendered file again :D so when duplicating the project I bet it will leverage the duplicated cache as well.

    So the work around would be to open the project once. Change something minor, close it again , kill AU process then re-render.

  • @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

  • @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

    Can you repro on a one audio track project and email the GB file to me? I have those same plugins. I’ll see how it behaves on my system

    realdavidai(at)dfmedia.com

  • @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

    I ve got a successful export with Maxima on a simple test :s

  • edited January 2018

    @realdavidai said:

    @Marcel said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Can’t the cache of the renders be tackled by duplicating the project first? in other words: is the cache of the renders also duplicated? I shall try this now

    Not sure. The cache is probably in the project bundle...so perhaps GB compares project time stamp with rendered file time stamp. If they are the same it just shoots out the same rendered file again :D so when duplicating the project I bet it will leverage the duplicated cache as well.

    So the work around would be to open the project once. Change something minor, close it again , kill AU process then re-render.

    Didn’t completely understand what you meant by ‘kill AU process’ but I tested it by: open the project, changed something minor, close it, shut down my iPad, open iPad, export to song. A pity, but it didn’t help.

  • @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

    Can you repro on a one audio track project and email the GB file to me? I have those same plugins. I’ll see how it behaves on my system

    realdavidai(at)dfmedia.com

    Thanks for that :smile: mail is sending via mail drop, should take a moment.

  • edited January 2018

    @FredAntonCorvest said:

    @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

    I ve got a successful export with Maxima on a simple test :s

    Just exported single drum track with blamsoft resampler and maxima while removing Replicant 2 and that render properly. Audio damage has more issues.

  • @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Could you give the steps to take to render off line? I understand the force quit part, but I've never tried rendering a GB project off line and don't know how to do that. Thanks!

  • Render export issue with Filterstation2 too.

  • @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @Janosax said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Do you mean you do a hard reboot and don’t load project? I tested that and the issue is still there with Audio Damage AU.

    Another confounding factor is that renders are cached. (You can tell by the time stamps on the rendered file). So once you get a bad render you will keep getting it. To test I had to force GB to create a new render by choosing a different compression scheme

    Just tried that still don’t works with Blamsoft resampler, Maxima and Replicant 2 on a drum track :(

    Can you repro on a one audio track project and email the GB file to me? I have those same plugins. I’ll see how it behaves on my system

    realdavidai(at)dfmedia.com

    Thanks for that :smile: mail is sending via mail drop, should take a moment.

    Okay hasn’t come thru yet. I’ll keep an eye out for it

  • edited January 2018

    @Audiojunkie said:

    @realdavidai said:

    @brambos said:
    Yes, an offline render flag exists, but it’s an optional feature. The host tells the plugin when it’s in offline mode (not many hosts do, though) so the plugin knows it can take its sweet time rendering in high quality. At first glance I don’t see any plausible explanation for the render problems being caused by the offline mode: the host doesn’t do anything differently and the plugin can choose to do so, but most probably don’t :)

    Having said that: Apple has made offline AU rendering a really painful process. I know because the WAV export from all my apps is basically an offline AU render. And I’ve been in contact about this with three other host makers. Our shared conclusion is that offline rendering of AUs is more like a hack than a well-thought-through feature. Perhaps Apple are now suffering from their own design flaw in the framework. That would be ironic B)

    Thanks this got me thinking! It’s likely an AU persistence issue. I just experimented by clearing out the AU subsystem (iOS force quit) and rendering the GB project offline again -without- opening it first.

    This time Filterstation2 showed up perfectly in the offline bounce.

    Could you give the steps to take to render off line? I understand the force quit part, but I've never tried rendering a GB project off line and don't know how to do that. Thanks!

    Oh GB only renders off line (when you share from the song browser) What I’m finding so far is that certain problematic effects will have issues if:

    1) They have been instantiated by opening the before the render
    2) a recent corrupt render has already been done and is cached.

    So for the current test is to make sure GB is at the song browser window before shutting down, otherwise it will simply reopen the project (and plugins as soon as you relaunch it )

    There could be more issues though. I think the basic issue is that certain plugin are silently crashing during render.

  • I don't have an effect plugin to test with right now, but in my experience one of the main causes of failing offline renders has to do with the timestamps that are passed to the plugin: if there is even a tiny discontinuity in the timestamps, CoreAudio will start throwing timeout errors and ignores the plugin. Perhaps GB is passing invalid timestamps to the effects plugins in offline render mode (e.g. timestamps that should be used for realtime rendering)?

    Doing a hard reset possibly resets the timer too, and doing an offline render before any realtime rendering has taken place may explain why the timestamps are not corrupted yet? Just doing some really wild guessing here.

Sign In or Register to comment.