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.

Comments

  • Good catch, loops useful. AUv3 and free, top banana!

  • What a gift! Being able to see MIDI is an AU is great.

  • Looks great! There’s no better way to suss out midi problems than a monitor.

  • Awesome! I can see this being really useful in combo with Streambyter AU to monitor that scripts are working as intended.

  • edited January 2019

    Bummer... when in slide over mode (the floating window), which seems to be a pretty useful mode to use this, you can’t scroll the display and those world-record holding for their ENORMOUS size buttons take most of the display...

    It also would be super useful if it displayed note name not just midi number.

    Think I’ll stick with the also free, but better, Midi Scope.

  • @SpookyZoo said:
    Awesome! I can see this being really useful in combo with Streambyter AU to monitor that scripts are working as intended.

    Boom.

  • wonderful!

  • _ki_ki
    edited January 2019

    @SpookyZoo and @syrupcore
    The latest Streambyter AU update added an internal midi monitor that shows incoming and outgoing midi messages in separate rows including timestamps and note names. And a view to show the streambyter manual.

    .

    Nevertheless, the new free midi monitor AU is a very nice gift from Kai Aras ( @ka010 ) , thanks a lot :)

  • @_ki said:
    @SpookyZoo and @syrupcore
    The latest Streambyter AU update added an internal midi monitor that shows incoming and outgoing midi messages in separate rows including timestamps and note names. And a view to show the streambyter manual.

    Ah, my bad!

    Hadn’t used StreamByter over the holidays. Cool to know, thanks. Just hooked it up and works well on iPhone too.

    Nevertheless, the new free midi monitor AU is a very nice gift from Kai Aras ( @ka010 ) , thanks a lot :)

    Definitely. Thanks Kai.

  • Nice treat to wake up to this morning :) Thanks @ka010 very generous !!

  • You're welcome :)

    @MonkeyDrummer said:
    Bummer... when in slide over mode (the floating window), which seems to be a pretty useful mode to use this, you can’t scroll the display and those world-record holding for their ENORMOUS size buttons take most of the display...

    It also would be super useful if it displayed note name not just midi number.

    Think I’ll stick with the also free, but better, Midi Scope.

    Fixed in 1.0.1 already, should be out sometime next week.

  • it's not keen on a lot of very short midi notes arriving at the same time - I've had a couple of crashes testing my new app......

  • @pagefall said:
    it's not keen on a lot of very short midi notes arriving at the same time - I've had a couple of crashes testing my new app......

    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

  • @ka010 said:

    @pagefall said:
    it's not keen on a lot of very short midi notes arriving at the same time - I've had a couple of crashes testing my new app......

    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    Is it text specifically that is taxing on CPU or UI in general...would using maybe some kind of graphic like different coloured dots for each message type make the UI updates quicker ? Of course you'd still need text for the actual details, but not having to write NOTE or CC everytime may help if it is text that is slow. ?

  • @SpookyZoo said:

    @_ki said:
    @SpookyZoo and @syrupcore
    The latest Streambyter AU update added an internal midi monitor that shows incoming and outgoing midi messages in separate rows including timestamps and note names. And a view to show the streambyter manual.

    Ah, my bad!

    Hadn’t used StreamByter over the holidays. Cool to know, thanks. Just hooked it up and works well on iPhone too.

    Ah, that's sweet. Thanks.

    Nevertheless, the new free midi monitor AU is a very nice gift from Kai Aras ( @ka010 ) , thanks a lot :)

    Definitely. Thanks Kai.

    Very this! Quite handsome to boot.

  • @AndyPlankton said:

    @ka010 said:
    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    Is it text specifically that is taxing on CPU or UI in general...would using maybe some kind of graphic like different coloured dots for each message type make the UI updates quicker ? Of course you'd still need text for the actual details, but not having to write NOTE or CC everytime may help if it is text that is slow. ?

    I'd be interested to understand this as well just out of nerdy curiosity. My guess would be that it's not the text itself but the speed at which it needs to be written to the screen when there's a ton of events and then all of the other messages scrolled.

  • @syrupcore said:

    @AndyPlankton said:

    @ka010 said:
    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    Is it text specifically that is taxing on CPU or UI in general...would using maybe some kind of graphic like different coloured dots for each message type make the UI updates quicker ? Of course you'd still need text for the actual details, but not having to write NOTE or CC everytime may help if it is text that is slow. ?

    I'd be interested to understand this as well just out of nerdy curiosity. My guess would be that it's not the text itself but the speed at which it needs to be written to the screen when there's a ton of events and then all of the other messages scrolled.

    I wonder if this is why the Streambyter version fills the AU window size then subsequent messages can only be viewed by scrolling.

    So possibly the data is all received and stored in memory and only written to screen when being scrolled down.

  • @SpookyZoo said:

    @syrupcore said:

    @AndyPlankton said:

    @ka010 said:
    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    Is it text specifically that is taxing on CPU or UI in general...would using maybe some kind of graphic like different coloured dots for each message type make the UI updates quicker ? Of course you'd still need text for the actual details, but not having to write NOTE or CC everytime may help if it is text that is slow. ?

    I'd be interested to understand this as well just out of nerdy curiosity. My guess would be that it's not the text itself but the speed at which it needs to be written to the screen when there's a ton of events and then all of the other messages scrolled.

    I wonder if this is why the Streambyter version fills the AU window size then subsequent messages can only be viewed by scrolling.

    So possibly the data is all received and stored in memory and only written to screen when being scrolled down.

    I've definitely seen monitors do similar stuff. Indeed, I think Nic's old MIDI Monitor app (can't remember the exact name) did rate limiting so that it would write a bunch of messages to the screen at once with timestamps in place if there were too many coming in at once.

  • @syrupcore said:

    @SpookyZoo said:

    @syrupcore said:

    @AndyPlankton said:

    @ka010 said:
    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    Is it text specifically that is taxing on CPU or UI in general...would using maybe some kind of graphic like different coloured dots for each message type make the UI updates quicker ? Of course you'd still need text for the actual details, but not having to write NOTE or CC everytime may help if it is text that is slow. ?

    I'd be interested to understand this as well just out of nerdy curiosity. My guess would be that it's not the text itself but the speed at which it needs to be written to the screen when there's a ton of events and then all of the other messages scrolled.

    I wonder if this is why the Streambyter version fills the AU window size then subsequent messages can only be viewed by scrolling.

    So possibly the data is all received and stored in memory and only written to screen when being scrolled down.

    I've definitely seen monitors do similar stuff. Indeed, I think Nic's old MIDI Monitor app (can't remember the exact name) did rate limiting so that it would write a bunch of messages to the screen at once with timestamps in place if there were too many coming in at once.

    Yeah, that was MidiVision I think.

    His other newer apps MidiFire and StreamByter seem to follow the same ethos.

  • @ka010 said:

    @pagefall said:
    it's not keen on a lot of very short midi notes arriving at the same time - I've had a couple of crashes testing my new app......

    yes, writing out all that text is incredibly heavy on the CPU. Already tried to optimize but seems like theres not much more I can do other than to throttle the display refreshes. Next version will most likely add a slider for that.

    @ka010 Have you tried using UIWebView and html tags for formatting?
    Also, refreshing at a rate of 20Hz should be sufficient for a MIDI monitor.

  • The v1.0.1 update should be available now, here's whats included:

    • Added an option to clear the display
    • Optimised text drawing and layout
    • Fixed layout issues when using the app in split-screen or slide-over mode
    • Fixed an issue where tempo and transport related events would not be logged
    • Improved overall performance

    @syrupcore said:
    I'd be interested to understand this as well just out of nerdy curiosity. My guess would be that it's not the text itself but the speed at which it needs to be written to the screen when there's a ton of events and then all of the other messages scrolled.

    It's a combination of multiple things, I/O in general is an expensive thing that comes with a certain overheard, when doing things at high rates the overhead eventually becomes an issue. That said, all of this was greatly exaggerated by a threading bug which is fixed in the latest update.

    @rs2000 said:
    @ka010 Have you tried using UIWebView and html tags for formatting?
    Also, refreshing at a rate of 20Hz should be sufficient for a MIDI monitor.

    I have not, interesting idea tho! I wonder what the difference in performance is.
    The latest version is now running at 15hz which works rather well I think. As mentioned above, most of the CPU overhead was due to a threading bug not the text rendering itself.

  • edited January 2019

    @ka010 said:

    @rs2000 said:
    @ka010 Have you tried using UIWebView and html tags for formatting?
    Also, refreshing at a rate of 20Hz should be sufficient for a MIDI monitor.

    I have not, interesting idea tho! I wonder what the difference in performance is.
    The latest version is now running at 15hz which works rather well I think. As mentioned above, most of the CPU overhead was due to a threading bug not the text rendering itself.

    I've heard other developers complain about the low performance of formatted text views and read that using an html-formatted view by means of UIWebView would bring noteworthy performance improvements.
    I'm not an iOS developer myself so I can only repeat what I've heard ;)

    BTW, I don't see any clock messages no matter if the "Clock" button is activated.

  • @rs2000 said:

    @ka010 said:

    @rs2000 said:
    @ka010 Have you tried using UIWebView and html tags for formatting?
    Also, refreshing at a rate of 20Hz should be sufficient for a MIDI monitor.

    I have not, interesting idea tho! I wonder what the difference in performance is.
    The latest version is now running at 15hz which works rather well I think. As mentioned above, most of the CPU overhead was due to a threading bug not the text rendering itself.

    I've heard other developers complain about the low performance of formatted text views and read that using an html-formatted view by means of UIWebView would bring noteworthy performance improvements.
    I'm not an iOS developer myself so I can only repeat what I've heard ;)

    BTW, I don't see any clock messages no matter if the "Clock" button is activated.

    Clock messages including start/stop/continue didn't work in 1.0, they should work in 1.0.1 tho. If you're still not seeing them please let me know.

  • @ka010 said:

    @rs2000 said:

    @ka010 said:

    @rs2000 said:
    @ka010 Have you tried using UIWebView and html tags for formatting?
    Also, refreshing at a rate of 20Hz should be sufficient for a MIDI monitor.

    I have not, interesting idea tho! I wonder what the difference in performance is.
    The latest version is now running at 15hz which works rather well I think. As mentioned above, most of the CPU overhead was due to a threading bug not the text rendering itself.

    I've heard other developers complain about the low performance of formatted text views and read that using an html-formatted view by means of UIWebView would bring noteworthy performance improvements.
    I'm not an iOS developer myself so I can only repeat what I've heard ;)

    BTW, I don't see any clock messages no matter if the "Clock" button is activated.

    Clock messages including start/stop/continue didn't work in 1.0, they should work in 1.0.1 tho. If you're still not seeing them please let me know.

    OK thanks, it works now. No timestamps but at least some "CLOCK" type messages.
    Guess I'll have to use a different monitor to measure clock instabilities...

  • @rs2000 said:
    OK thanks, it works now. No timestamps but at least some "CLOCK" type messages.
    Guess I'll have to use a different monitor to measure clock instabilities...

    So far it's only good for verifying clock messages are being transmitted. However, I'm planning to add some measurement modes for things like stability, drift and jitter. No ETA yet tho I'm afraid.

  • edited January 2019

    @ka010 said:

    @rs2000 said:
    OK thanks, it works now. No timestamps but at least some "CLOCK" type messages.
    Guess I'll have to use a different monitor to measure clock instabilities...

    So far it's only good for verifying clock messages are being transmitted. However, I'm planning to add some measurement modes for things like stability, drift and jitter. No ETA yet tho I'm afraid.

    Wow, cool! That's great to hear. Contact me if you want someone for testing or discussing :)

  • How much is a Gratis App in Turkish Lira?

Sign In or Register to comment.