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.

Mozaic: a sneak-peek at my new project

12467

Comments

  • edited March 2019

    I look forward to this new direction Bram. That I will buy in is purely a given.

  • @brambos said:
    Mozaic is like any other AUv3 MIDI plugin on iOS. Either they all work, or they all stop working :)

    As long as they keep midi events list in an AUv3 render call I'm happy - but not sure if Apple are supporting midi effects AUs, so might have to swap to audio effects....

  • I think I must have some Dutch ancestry. 😅

  • @midiSequencer said:

    @brambos said:
    Mozaic is like any other AUv3 MIDI plugin on iOS. Either they all work, or they all stop working :)

    As long as they keep midi events list in an AUv3 render call I'm happy - but not sure if Apple are supporting midi effects AUs,

    That’s even supported in Garageband, so that should count as ‘supported’ ;)

  • The language does seem quite accessible so far, for the likely user base. Seems like a good design decision.

  • edited March 2019

    It already looks like something I could learn to use and I hate scripting (even though I have to use it in various other mediums like animation/design etc). Anything with actual logical english helps so much. (for english speakers) :)

  • edited March 2019

    @NoonienS said:

    @brambos said:

    @SpookyZoo said:
    @brambos
    Does your warning on the AudioVeek thread apply to Mozaic?

    @brambos said:

    @jonmoore said:
    Ghost notes are particularly impressive considering these are standalone AU instances. This is really shaping up nicely.

    I think it's good to warn that being able to share data between AU instances is a neat side-effect of all AUs running inside the same process. However, it's not an official feature offered by Apple, which means that they can take it away at any moment.

    And that's not even unlikely to happen, because if they listen to our other big request: "please remove the memory limit of xxx Mb per AU" they may very well put all AU instances in their own process - making this feature impossible. :#

    So enjoy it while it's there B)

    No, that risk doesn’t exist here. I’ve considered the concept of ‘Metavariables’ which live in the scope of all plugin instances, but I decided against it for several reasons (mostly conceptual, rather than technical tough).

    Could you be convinced ro reconsider? That’s a quite useful feature in StreamByter (global variables) that I take advantage of in scripts used to identify a chord played in one stream and let it affect the midi played out in another. StreamByter is a pain to work with though (even though I have a lot of programming experience) and the lack of GUI is limiting. Another example would be AudioVeeks Midi tools which also takes great advantage of such capability.

    I've put them back in. You can now have up to 1000 global 'meta' variables/arrays shared across all instances. I'll put a big warning in the user manual about the risks involved in using these (nothing destructive, but you will have a hard time debugging your script when another script is messing up your global variables in the background B) )

  • edited March 2019

    @Carnbot said:
    Anything with actual logical english helps so much. (for english speakers) :)

    We should be in luck as @brambos loves writing documentation and the Dutch are famed for their direct communication style. :)

  • I look forward to the tsunami of scripts people far smarter than me will be sharing.

  • That looks real cool Bram!

  • @brambos said:
    I even enjoy writing the manual! B)

  • This is what it looks like when Bram has had it with all of our feature requests. :+1: :heart:

  • @brambos said:
    I also think that when people get to see the script language in more detail, the benefits over Streambyter will be very clear: it will be a lot more readable and a whole lot more flexible and feature-rich (in my humble, slightly biased opinion) :)

    Immediate impression (and partially hope): Streambyter is to Perl as Mosiac is to Python. (Or maybe Javascript :: jQuery?)

    Both Perl and Python are powerful AF but one is considerably more pleasant to spend an afternoon (or year) with. Particularly when it comes to understanding other people's code (or coming back to your own code 6 months later)... perl can inspire you to consider hurting puppies.

  • @brambos said:

    @_ki said:
    :) Nice

    On your medium page you already mentioned nested loops and arrays, - are user defined functions also in the scope of the language ?

    No user functions for now, but lots of different events to tap into.

    Also compound conditional statements:

    if (HostRunning and HostBeat = 0) or HostTempo < 80
      SetKnobValue 4, 64
    else if HostBar > 0
      FlashPad (Random 0, 3)
    endif
    

    So plenty of possibilities for structured code.

    Perhaps (some day) custom events would fit the syntax model a little better than custom functions?

    if (HostRunning and HostBeat = 0) or HostTempo < 80
      SetKnobValue 4, 64
    else if HostBar > 0
      Trigger @MyCustomEvent
    endif
    
    @OnMyCustomEvent
      FlashPad (Random 0, 3)
      // Do other stuff
    @end
    
  • @syrupcore said:

    @brambos said:

    @_ki said:
    :) Nice

    On your medium page you already mentioned nested loops and arrays, - are user defined functions also in the scope of the language ?

    No user functions for now, but lots of different events to tap into.

    Also compound conditional statements:

    if (HostRunning and HostBeat = 0) or HostTempo < 80
      SetKnobValue 4, 64
    else if HostBar > 0
      FlashPad (Random 0, 3)
    endif
    

    So plenty of possibilities for structured code.

    Perhaps (some day) custom events would fit the syntax model a little better than custom functions?

    if (HostRunning and HostBeat = 0) or HostTempo < 80
      SetKnobValue 4, 64
    else if HostBar > 0
      Trigger @MyCustomEvent
    endif
    
    @OnMyCustomEvent
      FlashPad (Random 0, 3)
      // Do other stuff
    @end
    

    Yes, indeed! But not for 1.0 ;)

  • Two questions that came to mind:

    • Will the value ranges be settable? Would that include string values? An example would be if a knob is used to select a Scale. In the code it could be represented as a number for sure, but wouldn’t be so intuitive for the user.
    • Will there be any radio buttons or similar that can be programmed to represent some mode of operation? Using a knob to just represent a binary value seems a bit of an overkill..
  • @brambos said:

    The bluntness of the Dutch style of communication is legendary all over the world. To describe it as "direct" is probably an understatement. I try to be conscious of it when speaking in an international audience, but sometimes a hint of it may trickle through in how I articulate things ;)

    http://www.bbc.com/travel/story/20180131-where-dutch-directness-comes-from

    I think I need to move to Holland. How's your asylum laws? :) I'm a musical refugee!

  • I have a feeling this tread is going to end up blowing the Drambo one out of the water for size/growth if The Bram Bros don't pop this baby out soon! :)

  • I just recently stumbled upon this big news, it's a combo that promises incredibly exciting future: Brambos - one of the heroes of iOS music app scene, endless flexibility with real programming and Audio units standard.
    Only I was a little sad about your attitude towards GUI controls. Yes, you can route the signal to any MIDI AU or app, but it's not really the same (not to mention, many MIDI AUs don't receive MIDI, only send). Here you'd have the ability to e.g. put labels on knobs (programatically). This is not possible via raw MIDI. I can also imagine much more creative options, e.g. control RGB of pads. You could program a step sequencer with position indicator if you have a row of e.g. 16 buttons and control over RGB. But with only 4 buttons, I don't see much use. Honestly, I don't see much use of only 4 pads at all...
    I would even pay for extra IAP (or maybe a separate apps?) to have only knobs, only pads and maybe also only XY. This way you can be more modular, in AUM you can resize the window and hide as much controls as you need for a specific instance.
    The other option would be to show more rows of the same GUI (4 x pads, knobs and XY) while having AU window maximised. Also we would need a button to hide the code editor and that would reveal maybe two more rows of the same controls. This is only according to your screenshot, which is in portrait mode. In landscape, there is only option of having them in multiple columns (and maybe 2 rows? So 2x2?) I am not sure where the code editor would be on landscape, but if it would be on left/right, this is a viable design.

    Nevertheless, I am super-excited about this, even if you'll stay opinionated. Crossing fingers it'll be a smooth ride a we'll get this in our hands as soon as possible!

  • @skrat said:
    I just recently stumbled upon this big news, it's a combo that promises incredibly exciting future: Brambos - one of the heroes of iOS music app scene, endless flexibility with real programming and Audio units standard.
    Only I was a little sad about your attitude towards GUI controls. Yes, you can route the signal to any MIDI AU or app, but it's not really the same (not to mention, many MIDI AUs don't receive MIDI, only send). Here you'd have the ability to e.g. put labels on knobs (programatically). This is not possible via raw MIDI. I can also imagine much more creative options, e.g. control RGB of pads. You could program a step sequencer with position indicator if you have a row of e.g. 16 buttons and control over RGB. But with only 4 buttons, I don't see much use. Honestly, I don't see much use of only 4 pads at all...
    I would even pay for extra IAP (or maybe a separate apps?) to have only knobs, only pads and maybe also only XY. This way you can be more modular, in AUM you can resize the window and hide as much controls as you need for a specific instance.
    The other option would be to show more rows of the same GUI (4 x pads, knobs and XY) while having AU window maximised. Also we would need a button to hide the code editor and that would reveal maybe two more rows of the same controls. This is only according to your screenshot, which is in portrait mode. In landscape, there is only option of having them in multiple columns (and maybe 2 rows? So 2x2?) I am not sure where the code editor would be on landscape, but if it would be on left/right, this is a viable design.

    Nevertheless, I am super-excited about this, even if you'll stay opinionated. Crossing fingers it'll be a smooth ride a we'll get this in our hands as soon as possible!

    Point taken, and taken on board. Many things are still in consideration. B)

    However, what I'm hoping with Mozaic is that instead of worrying about things that may not be possible (yes, limitations will always exist - with every usable product) we can also wonder about all the things that are now suddenly possible.

    Every other app released since 2016 has a UI with boring 4x4 pad controls. Perhaps we don't need more plugins with a vanilla MPC layout, but stuff that is a bit more left-field :) You can use those 4 pads in conjunction with the XY controller to create something a little bit more original perhaps, something that does not yet exist? Limitations breed creativity.. and I will show examples with the factory scripts B)

    Perhaps I will still decide to offer a limited set of different control layouts, if I can think of an elegant way to integrate it. If anything, I want to stay far-far-away from WYSIWYG layout editors ;)

  • I can see the advantage of offering a modular ui, add 3 sets of xy pads instead of dials etc, etc. But in case that won't happen, in theory it would be possible to use a hardware controller however you wanted? i think I can see me using it more this way. Or as much anyway :)

  • I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

  • Great news :)

  • @brambos said:
    I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

    Just one word: drooling.

  • @brambos said:
    I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

    That was the sneakiest of peaks!

  • @gusgranite said:

    @brambos said:
    I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

    That was the sneakiest of peaks!

    Yes, but the beginnings of much more. Now implementing a boring 16-pad layout B)

  • @brambos said:

    @gusgranite said:

    @brambos said:
    I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

    That was the sneakiest of peaks!

    Yes, but the beginnings of much more. Now implementing a boring 16-pad layout B)

    I think this is most excellent!

  • @brambos said:
    I have decided there will be a limited set of different layouts, which can be selected programmatically through the script...

    Nice. And don't forget pad and knob labels ;)

Sign In or Register to comment.