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.

About Atom, Audioveek, where we are and what's next

Hey friends,

How have you been?

It's a while now since I've been active on the forum. I'm not glad about that either. Been working on some demanding things over at Mozilla, and since I'm pretty bad when it comes to context switching, I can only focus on one thing at a time. But hey, you folks are helping me get better at it!

My lovechild Audioveek is being taken care of. I still have all the post-its with all your feature requests. And I still enjoy making music and working on Atom.

I'm looking at that top-right messages icon on this forum, and the red badge scares me. But I'll do right by you and make sure I reply to all of your messages. There's a few recurring themes that I've also been answering on the Audioveek support website, so by now I've got some answers ready!

Here's some technical context for the delays: After the last release, Apple screwed me over a bit (though I suppose it's maybe equally my fault). I've been using (abusing) Swift, the programming language in which Atom's UI is written, in various ways which weren't publicly supported[1]. For science! And of course, speed and efficiency. But with the recent versions of Xcode and Swift, I'm unable to build and submit Atom to the App Store, since the latest Xcode literally cannot compile my code[2]. I've noticed this issue around late May, and tried to work around it for a few weeks after that. However, moving forward, I'm uneasy with this situation and using too old versions of Xcode, so I've decided to rewrite Atom from scratch.

That... that is going to take a bit of time to finish. But I've already started. And I'm pretty far along.

If there's one thing that impresses me in all of this, is your patience. I'm putting a lot of love into Audioveek and Atom, and I see the fruits of that reflected on this forum.

Thanks!

[1] For devs: this isn't about using undocumented APIs. This is about using function initialization via lazy vars, combined with partial key paths for makeshift reflection on Swift classes. Doing those things helped me implement something like React props propagation (top-down single store application state) on CA layers, which gave me debouncing and caching for "free". This meant that the UI never updated when it didn't have to.

[2] The compiler crashes while compiling. Yes Apple knows about it. Yes Apple isn't prioritising fixing it because it's always been a hack and a technically unsupported aspect of the syntax.

«1

Comments

  • edited September 18

    Glad to see you alive and well buddy.

    Looking forward to catching up soon :)

  • respect for the openness! Sounds like a very difficult situation and it all makes sense now.

  • Great to see you are ok and still working on making music dreams come try.

  • Good luck, Veek. Atom has become one of the most important apps in the arsenal. It's literally indispensible.
    Keep at it!

  • Nice one, @blueveek! Mozilla do great work. Good to know you’re involved.

  • Sounds like a lot my man! We are patient mostly haha especially when the deff behind an app is responsive and cool... You're in good hands haha, best of luck dude

  • edited September 18

    Good to hear from you, glad you responded to my message on your website.

    Good luck with recoding Atom, it's worth it.

  • Thanks for all the great work with Mozilla; only one I use!❤️😌☝️

    One step at a time and we’ll get there🤪☝️😳❤️❤️❤️

  • @blueveek said:
    Hey friends,

    How have you been?

    It's a while now since I've been active on the forum. I'm not glad about that either. Been working on some demanding things over at Mozilla, and since I'm pretty bad when it comes to context switching, I can only focus on one thing at a time. But hey, you folks are helping me get better at it!

    My lovechild Audioveek is being taken care of. I still have all the post-its with all your feature requests. And I still enjoy making music and working on Atom.

    I'm looking at that top-right messages icon on this forum, and the red badge scares me. But I'll do right by you and make sure I reply to all of your messages. There's a few recurring themes that I've also been answering on the Audioveek support website, so by now I've got some answers ready!

    Here's some technical context for the delays: After the last release, Apple screwed me over a bit (though I suppose it's maybe equally my fault). I've been using (abusing) Swift, the programming language in which Atom's UI is written, in various ways which weren't publicly supported[1]. For science! And of course, speed and efficiency. But with the recent versions of Xcode and Swift, I'm unable to build and submit Atom to the App Store, since the latest Xcode literally cannot compile my code[2]. I've noticed this issue around late May, and tried to work around it for a few weeks after that. However, moving forward, I'm uneasy with this situation and using too old versions of Xcode, so I've decided to rewrite Atom from scratch.

    That... that is going to take a bit of time to finish. But I've already started. And I'm pretty far along.

    If there's one thing that impresses me in all of this, is your patience. I'm putting a lot of love into Audioveek and Atom, and I see the fruits of that reflected on this forum.

    Thanks!

    [1] For devs: this isn't about using undocumented APIs. This is about using function initialization via lazy vars, combined with partial key paths for makeshift reflection on Swift classes. Doing those things helped me implement something like React props propagation (top-down single store application state) on CA layers, which gave me debouncing and caching for "free". This meant that the UI never updated when it didn't have to.

    [2] The compiler crashes while compiling. Yes Apple knows about it. Yes Apple isn't prioritising fixing it because it's always been a hack and a technically unsupported aspect of the syntax.

    I wonder how much fun iOS development is today. There must be ways to write future-proof code but how in the world do you learn to do it?

  • edited September 18

    @rs2000 said:

    I wonder how much fun iOS development is today. There must be ways to write future-proof code but how in the world do you learn to do it?

    Generally, it's pretty safe if you stick to well known standards. The iOS world is a bit of a wild west, but Apple's usually pretty good with backwards compatibility. It's when APIs get deprecated that things can maybe start to hurt, but even then you usually have quite a lot of time to rewrite and adapt. But only when developers are "naughty" is when things really start to hurt, and sudden breakage can happen unannounced :)

    If you're (or anyone else is) considering working on iOS apps, please don't let situations like these discourage you.

  • @blueveek said:
    Hey friends,

    How have you been?

    It's a while now since I've been active on the forum. I'm not glad about that either. Been working on some demanding things over at Mozilla, and since I'm pretty bad when it comes to context switching, I can only focus on one thing at a time. But hey, you folks are helping me get better at it!

    My lovechild Audioveek is being taken care of. I still have all the post-its with all your feature requests. And I still enjoy making music and working on Atom.

    I'm looking at that top-right messages icon on this forum, and the red badge scares me. But I'll do right by you and make sure I reply to all of your messages. There's a few recurring themes that I've also been answering on the Audioveek support website, so by now I've got some answers ready!

    Here's some technical context for the delays: After the last release, Apple screwed me over a bit (though I suppose it's maybe equally my fault). I've been using (abusing) Swift, the programming language in which Atom's UI is written, in various ways which weren't publicly supported[1]. For science! And of course, speed and efficiency. But with the recent versions of Xcode and Swift, I'm unable to build and submit Atom to the App Store, since the latest Xcode literally cannot compile my code[2]. I've noticed this issue around late May, and tried to work around it for a few weeks after that. However, moving forward, I'm uneasy with this situation and using too old versions of Xcode, so I've decided to rewrite Atom from scratch.

    That... that is going to take a bit of time to finish. But I've already started. And I'm pretty far along.

    If there's one thing that impresses me in all of this, is your patience. I'm putting a lot of love into Audioveek and Atom, and I see the fruits of that reflected on this forum.

    Thanks!

    [1] For devs: this isn't about using undocumented APIs. This is about using function initialization via lazy vars, combined with partial key paths for makeshift reflection on Swift classes. Doing those things helped me implement something like React props propagation (top-down single store application state) on CA layers, which gave me debouncing and caching for "free". This meant that the UI never updated when it didn't have to.

    [2] The compiler crashes while compiling. Yes Apple knows about it. Yes Apple isn't prioritising fixing it because it's always been a hack and a technically unsupported aspect of the syntax.

    Tx for the update.

    You probably know this, but if not, the AudioKit Pro folks pioneered using Swift for audio/MIDI apps... I wonder if they would have knowledge to share that might be helpful.

  • I am always curious how the sausage is made so I find this disclosure interesting. It humanizes the process of making these apps. I'm sure there are as many stories as there are apps. Your's is even more interesting when you approach us with candor.

  • Blessed to have you man! Thanks for the update.

  • Good to see you here, @blueveek.
    We missed you.
    :)

  • edited September 18

    All the best blueveek...
    Not that much into programming but, can we get just midi import/export out of this build.. I think that should hold us off a few..

  • Uh.
    That does not sound good.
    And it means that other developers will run into the same problems.
    And sure not all of them will be willing to rewrite from scratch.

    Apple still does not understand, that nobody is interested in "Apple" or "iOS" at all, the people are interested in the Apps!
    And it is not good that Apple keeps killing Apps!

    They killed all the 32 bit Apps.
    Now they changed Xcode in some incompatible ways and kill Apps.
    And next the are preventing any update to Apps that are not compiled with the newest version, killing the next Apps.

    They just constantly kill Apps!
    The worst thing that is possible.

  • @tja said:
    Uh.
    That does not sound good.
    And it means that other developers will run into the same problems.
    And sure not all of them will be willing to rewrite from scratch.

    Apple still does not understand, that nobody is interested in "Apple" or "iOS" at all, the people are interested in the Apps!
    And it is not good that Apple keeps killing Apps!

    They killed all the 32 bit Apps.
    Now they changed Xcode in some incompatible ways and kill Apps.
    And next the are preventing any update to Apps that are not compiled with the newest version, killing the next Apps.

    They just constantly kill Apps!
    The worst thing that is possible.

    I think you are misinterpreting what he wrote. He knowingly took a chance by using unsupported techniques. Apple didn’t cut the legs out from under him.

    Apple didn’t suddenly kill 32-bit apps. There was lots of advanced lead time and there were good reasons to eliminate support for them. On the Mac side, Apple gave like 10 years of warning. On iOS, there was less lead time, but developers knew it was coming a long time in advance.

  • @espiegel123 said:

    @tja said:
    Uh.
    That does not sound good.
    And it means that other developers will run into the same problems.
    And sure not all of them will be willing to rewrite from scratch.

    Apple still does not understand, that nobody is interested in "Apple" or "iOS" at all, the people are interested in the Apps!
    And it is not good that Apple keeps killing Apps!

    They killed all the 32 bit Apps.
    Now they changed Xcode in some incompatible ways and kill Apps.
    And next the are preventing any update to Apps that are not compiled with the newest version, killing the next Apps.

    They just constantly kill Apps!
    The worst thing that is possible.

    I think you are misinterpreting what he wrote. He knowingly took a chance by using unsupported techniques. Apple didn’t cut the legs out from under him.

    Apple didn’t suddenly kill 32-bit apps. There was lots of advanced lead time and there were good reasons to eliminate support for them. On the Mac side, Apple gave like 10 years of warning. On iOS, there was less lead time, but developers knew it was coming a long time in advance.

    The Apps are still killed, with or without "warning" or "time".

    And any "fix" requires an active and capable developer.

    Lots of App just "exist" and could be used for 10 years longer or more, even without an existing developer anymore.

    On MS, I think I can still use any App, the developers may long be dead already.

    Anyway....

  • Thank you, @blueveek, for logging in to generously give us details on what you've been up to and where you are headed. <3

  • @tja said:

    @espiegel123 said:

    @tja said:
    Uh.
    That does not sound good.
    And it means that other developers will run into the same problems.
    And sure not all of them will be willing to rewrite from scratch.

    Apple still does not understand, that nobody is interested in "Apple" or "iOS" at all, the people are interested in the Apps!
    And it is not good that Apple keeps killing Apps!

    They killed all the 32 bit Apps.
    Now they changed Xcode in some incompatible ways and kill Apps.
    And next the are preventing any update to Apps that are not compiled with the newest version, killing the next Apps.

    They just constantly kill Apps!
    The worst thing that is possible.

    I think you are misinterpreting what he wrote. He knowingly took a chance by using unsupported techniques. Apple didn’t cut the legs out from under him.

    Apple didn’t suddenly kill 32-bit apps. There was lots of advanced lead time and there were good reasons to eliminate support for them. On the Mac side, Apple gave like 10 years of warning. On iOS, there was less lead time, but developers knew it was coming a long time in advance.

    The Apps are still killed, with or without "warning" or "time".

    And any "fix" requires an active and capable developer.

    Lots of App just "exist" and could be used for 10 years longer or more, even without an existing developer anymore.

    On MS, I think I can still use any App, the developers may long be dead already.

    Anyway....

    I am sorry tja, but I disagree with your take on this issues. It isn't really possible for an OS to support all apps from all old generations. It isn't technically feasible. Really. Apple didn't kill those 32-bit apps. In order for any OS to move forward and allow new capabilities and support new hardware that makes new capabilities possible, it is necessary at some point to pull the plug on supporting ancient technologies. And if people want to keep using apps that a developer no longer supports, I think it really is the user's responsibility to keep legacy hardware around for that purpose. Many people (me included), keep some old machines around because we have abandoned apps that we want to use that don't work with newer OS versions or new hardware.

    You can't expect Apple (or any other OS developer) to be able to support all apps ever developed for any version of the platform.

    You also can't expect an OS to work around developer hacks (particularly from marginal market sectors).

    Apple sometimes has made boneheaded moves that adversely affect developers, but I don't think these are examples of them.

  • @espiegel123 For MS, that works.

    Apple could just add the required libraries for 32 bit Apps, even maybe as an additional download.
    And all old Apps could still run.

    If Apple would at least allow backup and restore, including the OS... but they don't.
    This makes things even worse.

    But let's stop, cannot change things anyway

  • edited September 18

    @blueveek I’m very happy to have news from you, and sorry for you about the Atom rewriting issues. You’re courageous!!!!! Many thanks for your dedication. I love and use all the time Atom for what it is today as it already fills the gap in dawless music production, and for your ideas about its future evolution. Don’t hesitate to charge us with iaps, most of us will give you this money with joy!! :)

  • Correct me if i'm wrong..... @tja and @espiegel123 I remember a quote from @brambos about @blueveek using 'illegal' code. Maybe not the exact words but something like that.

  • If @blueveek has to re-write the app(s) from scratch we should let him focus and be patient.
    As I recall he was really good and rapid app updates in response to user feedback so that would be a nice approach. Let him re-code the functionality and add enhancements when we all have app(s) in hand.

    Until then the apps we own still work, right?

    This is like waiting for any anticipated app release or promised enhancement (NS2 audio or iPhone releases). It's smart to let the developer go deep into the coding mindset.

    Changing apps from Swift to anything else is not a trivial conversion... consider the AudioKit Synth One stories. Matthew Fecher handed off his baby to the C++ (or Objective C, Apple's Enhanced C Language) coders to deliver the best possible performance.

    If @blueveek is a coder on the Mozilla project he's already got the language skills I'd bet so this might happen quickly if he has the extra time for this side-job.

  • Keep up the good work, blueveek!
    I love Atom and use it in pretty much everything I do...

  • Just to echo what has already been said multiple times on here, good luck, @blueveek. Many thanks for the heads-up.

  • edited September 18

    @Pierre118 said:
    Correct me if i'm wrong..... @tja and @espiegel123 I remember a quote from @brambos about @blueveek using 'illegal' code. Maybe not the exact words but something like that.

    Not so much illegal, more like unofficial/undocumented. Which means that there is a risk that Apple breaks it at some point or it simply stops working. Apple are pretty good at detecting illegal things, and they'll simply reject your app for it. So you won't find many apps live in the App Store containing truly illegal system calls or features. :)

    By the way, I'm using the same functionality in Mozaic (for the Globals) with huge caution-remarks in the manual. It's a use-at-your-own-risk deal.

  • Atom is one of my favourite apps! Good to know your well 😺🐬🌈

  • To be clear, me and Bram did indeed take a calculated risk when we decided to create inter-plugin instance communication the way we did, but that's not what I'm currently facing with Atom.

    The problem in this specific situation is very different technically, albeit similarly "risky" in terms of deciding to use unofficial/undocumented features, this time in regards to the language used (Swift). More details in the footnotes [1] and [2] of the OP. AFAIK this isn't a widespread issue in the AUv3 world, so I wouldn't be too worried about your favorite AUs needing a rewrite... for now :)

  • edited September 19

    .deleted, just boring moaning about swift was here. :trollface:

Sign In or Register to comment.