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.

What do you want for next FAC Maxima waveform viewer ? Defining YOUR needs.

So as reading your comments on the previous post I felt your needs to push Maxima waveform viewer to the next level, and one of you also suggested to add a threshold line :) I need to be sure about what you need exactly.

So bring your ideas here - we will define your needs together and then I'll plan the modifications and deliver an update!
Pictures, drafts, examples... anything is welcomed :)

We have made the same for Fac Chorus and you have now the BBD and Thick mode :)

For new users here you have the link App Store

Thank you for your contribution :)

«1

Comments

  • ...and yes I offer a promo code to the first 2 answers from someone that don't have Maxima already... yes I'm happy so I share :)

  • options are good :)

  • LUFS metering, if it doesn't have it already. Preferably in a nice, big, easy to read meter.

  • edited March 2018

    I also agree the more options the better!
    Especially for advanced users willing to tweak the app more! But for me, just having a stable rock solid Maxima is the top choice! :) <3

  • If you wanted it to be really versatile, like FabFilter Pro L, you could offer several metering options: Peak, RMS, the K system and LUFS.

  • @nick @richardyot new or existing users ?

  • Great ideas! Just hopefully it doesn’t get overly complicated since it already been praised for simplicity and amazing sonic power!

    @richardyot said:
    If you wanted it to be really versatile, like FabFilter Pro L, you could offer several metering options: Peak, RMS, the K system and LUFS.

  • @FredAntonCorvest said:

    @nick @richardyot new or existing users ?

    new

  • @nick said:
    @FredAntonCorvest said:

    @nick @richardyot new or existing users ?

    new

    Please PM me :)

  • I don’t have Maxima yet but I love FAC Chorus!

    I agree that several options for metering would be great!

    Are the two waveforms a stereo file? A Before/After effect view? Perhaps a difference view?

  • @noisefan said:
    I don’t have Maxima yet but I love FAC Chorus!

    I agree that several options for metering would be great!

    Are the two waveforms a stereo file? A Before/After effect view? Perhaps a difference view?

    Yes stereo - mirrored - and input on front and ouptput (maximised) behind.

  • @FredAntonCorvest said:
    @nick @richardyot new or existing users ?

    New :)

    PM sent.

  • Really looking forward to trying this someday when I can... I’ve only just found it. It looks super cool and I’m really happy you’re keeping in touch with the community. I really like developers who get involved. Thank you!

  • Mono/stereo waveform viewer and more accuracy for Maxima oscilloscope )
    And yes threshold line.
    Maybe Gain Reduction for metering but ...

  • edited March 2018

    The other thread had a post concerning the smoothing of the waveform and how it affects the display of transients ->

    “I may consider having an option giving the magnitude scaling but I have to be sure that most users have the same feelings...”

    I vote for a magnitude scaling option. And as a very minor suggestion, change the Threshold dial label from TRSH to THRS. The former reads like TRASH, which made me think distortion effect, at first look.

  • To FAC Maxima already looks pretty sweet!

    What it'd love to see is an oscilloscope, spectrum analyser and additional meters as an AUv3.
    This is something that is missing on iOS.

    To keep things simple a window could include one type of meter and if more views/meters are needed just start another instance of the plug-in :)

  • Thanks to you Fred I have this fab & brilliant app. But as your asking, I wouldn't mind seeing an Analog VU meter for nostalgia reasons. I use these on the PC when monitoring on the master actually. I prefer the old school ways. ;)

  • Wow analog VUs would give this amazing app another special touch :)

  • I’m with @richardyot here. We need some metering options mate.

  • edited March 2018

    .

  • Large view in AUM?

  • Yes please make the ui scale. Great apps :)

  • @Empolo said:
    ... And as a very minor suggestion, change the Threshold dial label from TRSH to THRS. The former reads like TRASH, which made me think distortion effect, at first look.

    Good point!

  • edited March 2018

    So focussing on the improvement of the existing waveform viewer only I've highlighted the following suggestions you made:

    • Having metering options: Peak, RMS, the K system and LUFS, Mono/stereo, != scales
    • Threshold line

    I've also taken notes of your global suggestions and future needs :)

    Anything else guys ?

    ps: I've expressed my position about small vs large view in other post - today my position is being compliant to Apple API view configuration management. Let see how AuV3 hosts evolve, now GB is for sure compliant and I'm sure others will follow.

  • edited March 2018

    @FredAntonCorvest said:
    So focussing on the improvement of the existing waveform viewer only I've highlighted the following suggestions you made:

    • Having metering options: Peak, RMS, the K system and LUFS, Mono/stereo, != scales
    • Threshold line

    I've also taken notes of your global suggestions and future needs :)

    Anything else guys ?

    ps: I've expressed my position about small vs large view in other post - today my position is being compliant to Apple API view configuration management. Let see how AuV3 hosts evolve, now GB is for sure compliant and I'm sure others will follow.

    To be honest I still thinks AUMs resizable implementation is better than Garagebands. Would it be so hard to do both the GB implementation and how @brambos does it ? Coz I genuinely cannot get myself to use Garageband at all.

  • @gonekrazy3000 said:

    To be honest I still thinks AUMs resizable implementation is better than Garagebands. Would it be so hard to do both the GB implementation and how @brambos does it ? Coz I genuinely cannot get myself to use Garageband at all.

    Perhaps AUM will also be getting the official iOS 11 implementation? I’ll check...

    Also If I had to guess I’d think when Cubasis gets around to doing scaling they might elect to do it the iOS 11 way.

  • edited March 2018

    The AUM way of scaling is already 100% compliant with the official API. It just doesn't require any additional negotiation. It simply gives the plugin a UIView of a size chosen by the user (and when the size changes the system automatically informs the plugin). The plugin gets to decide how to use that space. Couldn't be easier. But you never know if Apple start enforcing their GB method at some point. :D

  • @brambos said:
    The AUM way of scaling is already 100% compliant with the official API. It just doesn't require any additional negotiation. It simply gives the plugin a UIView of a size chosen by the user (and when the size changes the system automatically informs the plugin). The plugin gets to decide how to use that space. Couldn't be easier. But you never know if Apple start enforcing their GB method at some point. :D

    That’s what I’m thinking, AU is too fragile to start splintering on things. It’s all we’ve got on iOS. I think the best way forward is to follow the spec as closely as possible, to protect the future.

  • edited March 2018

    @realdavidai said:

    @brambos said:
    The AUM way of scaling is already 100% compliant with the official API. It just doesn't require any additional negotiation. It simply gives the plugin a UIView of a size chosen by the user (and when the size changes the system automatically informs the plugin). The plugin gets to decide how to use that space. Couldn't be easier. But you never know if Apple start enforcing their GB method at some point. :D

    That’s what I’m thinking, AU is too fragile to start splintering on things. It’s all we’ve got on iOS. I think the best way forward is to follow the spec as closely as possible, to protect the future.

    Not if the ‘spec’ is just there for Garageband and is nothing more than a burden for the rest of the developer community. Then it should just be ignored and go away. Especially since a hassle-free workable alternative already exists. But enough about this.. I don’t want to hijack this thread (apologies to my esteemed colleague for doing so). :)

    Edit: that came out a bit harsher than I intended. My stance is: there are several real issues with the AUv3 standard that could have been tackled while they were amending the standard. Instead they chose to ignore the practical knowledge, experience and feedback of the developer community and just add a feature to GB they happened to need - and did it in a clumsy way. They solved a problem that didn't exist in a way that's just annoying. They could have put that brainpower in solving the user preset issues we still have. :)

  • @brambos said:

    @realdavidai said:

    @brambos said:
    The AUM way of scaling is already 100% compliant with the official API. It just doesn't require any additional negotiation. It simply gives the plugin a UIView of a size chosen by the user (and when the size changes the system automatically informs the plugin). The plugin gets to decide how to use that space. Couldn't be easier. But you never know if Apple start enforcing their GB method at some point. :D

    That’s what I’m thinking, AU is too fragile to start splintering on things. It’s all we’ve got on iOS. I think the best way forward is to follow the spec as closely as possible, to protect the future.

    My stance is: there are several real issues with the AUv3 standard that could have been tackled while they were amending the standard. Instead they chose to ignore the practical knowledge, experience and feedback of the developer community and just add a feature to GB they happened to need - and did it in a clumsy way. They solved a problem that didn't exist in a way that's just annoying. They could have put that brainpower in solving the user preset issues we still have. :)

    For me the good news here is that at least there is some level of communication between developers and the AU team. I’ll take that as a hopeful indicator that there is still an effort to keep plugins/low latency etc going on mobile platforms at Apple. Android has been very disappointing in this regard.

Sign In or Register to comment.