Similarly, it's theoretically possible to write an AudioUnit in Objective C, but you'd need to be an expert on the language to avoid non-real-time aspects (it's possible to force the method address lookup in a non-real-time context so that there's no problem in the real-time callbacks, but that's not to be taken lightly). I'd again suggest that you avoid trying to write an AudioUnit in any language but C++.
I much prefer ObjC to C++, but I still write all AudioUnits in C++. In fact, I tend to start projects in plain C and then nearly always find myself converting to ObjC at some point when the design complexity reaches a certain level. That said, I still haven't ever used anything but C++ in any of the dozens of AudioUnits I've written. I mention this only as a way to stress that you're not going to find it easy to write an AudioUnit in plain C or ObjC or especially Swift (I don't even think the latter is possible).
Keep in mind that writing an AudioUnit is quite different from writing an audio application that hosts AudioUnits, even though the interface is shared.
When you're writing an audio application, you can use any language you like, and there are already established methods for using the existing AudioUnits from those languages. If you're writing an application in Swift, the way you host AudioUnits is the same, whether you're using Apple's built-in AudioUnits or your own AudioUnits. In that respect, I'd look for Swift examples that host AudioUnits to see how it's done. I'm sure someone has published such an example. If you really need to write your own AudioUnit, it will be hosted in your Swift application just the same as any of Apple's AudioUnits.
When you're writing a new AudioUnit, forget about Swift, ObjC, and even plain C. AudioUnit development is a bit harder than normal application development, so you'll need to wrap your head around some concepts that are probably a bit more difficult than the basic C++ design patterns in the AudioUnit examples. Just take it for granted that you need a basic understanding of C++ objects, inheritance, member variables and member functions before you can successfully create a new AudioUnit.
I think it's good that you're looking for learning exercises, but I predict that writing an AudioUnit as a way to learn how to properly host an AudioUnit is the long road. Further, trying to write an AudioUnit in any language but C++ is probably an unending road. I suggest that you look for more AudioUnit hosting examples, and keep plugging at it until you understand. Most custom AudioUnits can be hosted by any application, but I've had to write my own AU host to handle hexaphonic guitar plugins that I created. The skill set needed to write the plugins is different enough from the skill set needed to write the host that I think you're just creating more work for yourself (unless you actually do need to write a custom AU). Of course, there is a lot of conceptual overlap between the AU and host, but there are enough differences - particularly difficult aspects - that jumping to the other side of the fence is not really going to help. That said, I encourage you to eventually take on the task of learning AU development (once you've finished understanding hosting).
Brian Willoughby Sound Consulting
On Jan 31, 2016, at 2:34 PM, Charles Constant < email@hidden> wrote: > What do you think you're trying to avoid?
My main worries about C++ are (a) It's currently not possible to call C++ code directly from Swift. I imagine that'll cost me a few days right there, learning the right way to wrap C++ functions/objects so I can get at them from Swift (b) I have much less experience with C++ than with C or Obj-C. I'm not keen on copying a bunch of someone else's C++ code wholesale. I'd prefer to use it to get an idea of how to do it, and write my own version. My own attempt might be worse, but if it works at least I know I understand it :)
> You cannot do this in any sensible way.
Shucks :( I'm partly hoping to do this to wrap my head around the whole process. I'm not sure of the best way to apply third party AudioUnits to an arbitrary number of tracks (my app has a bunch of buffers soon tracks that are panned/attenuated, and I'm still shaky with how AudioChannelLayout works). I figure if I write my own AU, I'll get a better sense of what I need to do. Since I don't normally use C++, it's distracting for me to try to learn what's going on with C++ code.
I guess I could try, purely as a learning exercise, to port AUBase.cpp to Obj-C, with which I'm more familiar. I gather Obj-C is borderline dicey for RealTime audio, but it gives me a way to figure out how to do this. Porting working code later on from Obj-C back to C++ will be easier for me.
|