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 StoreAudiobus is the app that makes the rest of your setup better.
Comments
Yeah, this talk is brilliant. My sides ached after watching it.
https://benhoyt.com/writings/count-words/
Found an interesting page.
They compared performance across various languages by solving a counting-words-problem respectively.
And Swift's performance is not very good.
Is Go capable of doing the Dsp thing? I heard it's much easier to learn than to learn Rust, but Go seems like focusing on the web&server stuff.
This is one of the most interesting articles that I read since years.
Many many thanks!
It also includes lots of links to other articles, which I will have a look at.
Sadly, Objective C is not listed.
I seem to remember some similar article, where a device driver or something was written in different languages. I will see if I can find it again.
Sorted by optimized speed, the contest looks like this:
Orange, where optimized speed is more than 4 times the C version and red, when more than double again.
And comparing the average between the simple and the optimized versions represents the potential:
Here I used orange for the same as red above and used red when this was doubled again.
Yes, Swift does not seem to have any potential in regards of speed
And this was the network driver programming I mentioned above:
https://arxiv.org/pdf/1909.06344.pdf
https://github.com/ixy-languages/ixy-languages
There are an infinite number of these types of articles. I never see the point. If you are handed this task and Awk is one of the options, you are pretty much nuts not to use Awk. You use the tool for the task. Swift is the tool for writing iOS/macOS UI centric programs in. And just to clarify something, most of the Swift library you use is written in either C or Objective-C. (This is probably not the case for much of SwiftUI.)
About Go and DSP. No. It suffers from the same issues as Objective-C and Swift for DSP. You are not going to use it in the real-time audio thread because you don't have control of all of the system calls that the language runtime might make. You can't control the timing and you can't be sure it won't block. There is some research being done about garbage collection and other memory management systems to use in RT settings, but I don't know of any that have been implemented in a language shipping yet.
Rust is one of the interesting choices for doing audio work in because it is one of the few languages that can handle the RT part and yet provides some structure that would help on bigger projects (the one thing C kinda misses) and it isn't C++.
Zig and Nim are also intriguing in the same way and I actually like both of them better than Rust. They don't have as much mindshare at the moment though. Personally, I'll try to see what I can do with D. If D had multiple inheritance, I'd use it. It does have the issue that you have to avoid much of the D runtime to use it in an RT setting, so it might not be worth it.
Yes, it is. Check out Dylan Meeus' series on audio programming in Go, starting with this post: https://dylanmeeus.github.io/posts/audio-from-scratch-pt1/
Except that the garbage collection may bite you in a real-time context. But for rendering, should be fine.
While there certainly must be many more on-premise build systems than hosted, the trend seems to be shifting towards cloud-based build systems like Amazon CodePipeline, Travis CI, CircleCI, GitLab etc. That goes in lockstep with the general move away from on-prem systems. Technically, I don't see the Rust build system as that much different than Maven or CMake. As for macOS / iOS, for a quick test project it was easy to add the Rust compilation step as a project build phase.
This is so true. Especially with Node/npm the risk of a package manage injection attack is real, but also with other such systems. Now npm has started to warn about vulnerabilities, and also GitHub nags about dependencies (thankfully only the repo owner can see the warnings). It pays to be careful with what you depend on.
I'm going to float another idea here: as you may know, KORG have an SDK for their 'logue synths. Those have an ARM Cortex inside, and they have a C++ toolchain to produce the correct binaries. Well, why not do that in Rust instead of C++? I think the pieces are there, if someone who knows their stuff had the time to put them together. User oscillators and effects for 'logues in Rust? That would be interesting.
Thanks for the detailed reply. You are always very inspiring.
Now I know every language has its strength and limitation.
I'm still learning Swift with struggling. That's my limitation.
But at least Swift's syntax is very tidy.
Didn't want to spend 10 bucks on some apps.
So I bought a Mac to learn Swift, and thought 'Such simple features, I can do it myself! '
Now I'm waiting for those apps to be on sale.
The article actually mentioned that Python and AWK are good fot text processing.
It's just fun for rookie like me to watch veterans gathering and doing things, even though I understand nearly 0% of what they're doing.
So cool.
Many thanks. Learnt something new.
Korg Nu:Tekt NTS-1 has the same feature and is much cheaper. Can also do customization with it.
https://korginc.github.io/nts-1-customizations/
If you are wanting to program plugins for your own use check out Faust (https://faust.grame.fr). It is very slick and is a really nice way to program plugins. For doing plugins that you want to use for your own projects, it's pretty much ideal. Everyone should learn it.
The UI's it generates aren't going to work for shipping products, but you can generate C and C++ from it that you can embed into a Swift or Objective-C based AU that you could use. There are tools to do this for many plugin formats and languages choices in the Faust system. It is really very cool.
I didn't know that. That's very interesting. I'll take a look.
Have you seen the Daisy from Electrosmith? I've been side tracked from it for some time now, but last time I looked around the Daisy forum people were looking into programming it with Rust.
I cloned the git repository for the Korg SDK and have been going through it. Pretty cool stuff!
I see one possible snag with using Rust with the SDK that is going to cause a bit of pain. There may already be workarounds for this though. The SDK uses the GNU compiler toolchain. This is the official compiler/toolchain for doing dev for the ARM MCU's, so it makes sense for Korg to be using it. But, Rust doesn't do the gcc toolchain. I know there is a Rust compiler frontend being developed for gcc. This may be far enough along to allow using it with the Korg SDK. The other thing is that ARM has a port in progress for using LLVM for doing ARM MCU dev. This may be good enough to try to use too.
The other outside chance path is using LLVM's cross compilation support. This works to do ARM MCU dev and I've used it in the past. But, the Korg SDK looks to use the ARM CMSIS support and I don't know if this is ready for use with LLVM yet. In the projects I played with, I didn't use CMSIS to configure the MCU support as I had all the direct mappings I needed.
All of this is solvable, but it may make it more difficult to use Rust -- at least until the Rust gcc port is complete.
The Korg SDK is still really interesting. Even just using C++ would be pretty fun with it. The demo oscillator project they included is using controlled C++ and should be reasonable to read through and learn from.
Yeah the build system and package manager stuff don't seem like serious issues with Rust. If you don't like the build system, build your own. The reason it became dominant in Rust is because it works really well and is pretty flexible. If you want to use Cargo in CMake, or whatever, it's pretty straightforward. I was assuming that there were some weird edge cases I wasn't aware of, but NIH syndrome seems a little weak (I too have used weird hand-crafted make systems built with Bash, TCL and Perl, but therapy has helped me repress most of the details).
As for the package system... Then don't use it? You can use private crates, or repos - or limit yourself to hand-audited packages. There are even moves within the Rust community to audit 'key' crates.
There are issues with Rust, that I hope get addressed, that could limit adoption (it's reliance on llvm being a big one), I just don't really see these as significant issues.
>
For me the key thing about Rust is that it's been stable for 6 years, it has a sizable community developing good libraries and I can do useful things with it. Zig and Nim may become useful in the future, but I don't live in the future.
Thanks, that was new information for me. I searched a bit, and found something that looks interesting: https://interrupt.memfault.com/blog/arm-cortexm-with-llvm-clang
I'm a dilettante with MCUs but it seems that there is some effort in that space: https://github.com/ARM-software/CMSIS_5/issues/790
Yes, I spent some time with it last year and tried to make an additive synth user oscillator. I didn't really know what I was doing, so when it glitched badly I put it aside. I hope to get back to it when I retire or win the lottery, whichever comes first.