Thanks Paul and Brian, I’ll look further into the build integration.

Cheers,
Igor

> On 2 Apr 2018, at 02:34, Paul Davis <[email protected]> wrote:
> 
> for the record, again, Ardour utilizes a completely cross-platform build tool 
> (waf) that runs on macOS, Windows and Linux. Once upon a time, we used to 
> keep an XCode project up to date with the state of things, but we abandoned 
> that years ago because XCode (as a platform specific environment) offered us 
> nothing. There's nothing special about what waf does compared to make (other 
> than that it is about 2000% smarter), and there's no reason why you should 
> not be able to build with a makefile. The actual invoked programs are still 
> roughly the same as on any *nix system (waf knows about the differences; 
> apple's make might already know them too).
> 
>> On Sun, Apr 1, 2018 at 6:40 AM, Igor Clark <[email protected]> wrote:
>> Thanks Brian, that's really helpful.
>> 
>> I'm trying to establish whether I can avoid Xcode because I'm working with a 
>> very specific toolchain which handles Makefiles & build pipeline 
>> automatically, completely independent from Xcode. My usual process for 
>> building this kind of lib is to find out whether I can do what I want as a 
>> straight C/Makefile proof-of-concept first, then implement that into my main 
>> project and have the toolchain manage the build for me.
>> 
>> As for the MIDI send/receive, on reflection I think I'll be able to use 
>> normal MIDI I/O. I just need to establish what other outputs I can get from 
>> the plugins via the AU API, which is obviously going to be dependent on 
>> individual plugins.
>> 
>> Thanks again!
>> 
>> 
>>> On 01/04/2018 04:19, Brian Willoughby wrote:
>>> You can host an AU in Standard C. Just because AudioUnits are written in 
>>> C++ doesn’t mean that the host must be written in C++. In fact, I tend to 
>>> prefer to avoid C++ in favor of Standard C and Objective C. About the only 
>>> time I use C++ for CoreAudio is when creating an AudioUnit (but not when 
>>> hosting one).
>>> 
>>> I would recommend using AUGraph if you want to host multiple AUs. If your 
>>> connections are simpler then you can just host the AU(s) directly without 
>>> an AUGraph. Your choice may be influenced by whether you need live audio 
>>> output during your processing, or just offline. Obviously, offline 
>>> processing is quite easy in a command line program - the biggest challenge 
>>> is not terminating before the audio is complete.
>>> 
>>> Writing a command line program is very much supported. I do it all the 
>>> time. It’s typically more difficult to weave the Objective C User Interface 
>>> with the Standard C CoreAudio API, but even that isn’t difficult. You 
>>> should find it even easier to access CoreAudio and AudioUnits in a CLI 
>>> program written in Standard C.
>>> 
>>> As for Xcode, the tool supports command line programs just as easily as GUI 
>>> programs. I write a large number of CLU programs and I always use Xcode 
>>> because it is familiar. It presents no hurdles for CLI development. Are you 
>>> trying to avoid Xcode because you have specific issues? I’ve certainly 
>>> written a few projects with a simple Makefile and command-line make, but I 
>>> tend to get weary of manually managing the Makefile(s). Xcode makes this 
>>> work with much less effort, and it supports all kinds of development: GUI 
>>> apps, CLI programs, plugins, etc.
>>> 
>>> About the only question I don’t have an answer for off-the-cuff is how to 
>>> send MIDI events to an AU. If I needed to do that, I’d get the basic 
>>> structure of the AU loading and processing audio first, then look for some 
>>> documentation or examples that send MIDI events. I have done CLI programs 
>>> that send and receive MIDI, but those always communicated with external 
>>> devices. I’m not quite sure how to target an AU. As Paul suggested, it 
>>> might be possible to look through Ardour to find a hint, but you should get 
>>> everything else working first before diving into Ardour sources.
>>> 
>>> Brian
>>> 
>>> 
>>>> On Mar 30, 2018, at 6:10 AM, Igor Clark <[email protected]> wrote:
>>>> Hi all,
>>>> 
>>>> Is it possible to load an existing AudioUnit MIDI plugin and interact it 
>>>> with it from a CLI program written in C? I'd like to be able to use 
>>>> commercial plug-ins in my MIDI processing app.
>>>> 
>>>> I'm comfortable with how to communicate between C & C++ using 'extern' 
>>>> etc, so that's not the main issue. Rather, I'm wondering whether it's 
>>>> possible to have a C CLI app that loads the AU and sends MIDI passages to 
>>>> it, so that the AU processes the data (ideally async) and then returns its 
>>>> result back to the C app. I guess it's effectively writing an AU host app, 
>>>> but does that all have to be done in Xcode, or is it possible to do it as 
>>>> a straight C/C++ program using clang/llvm at the shell?
>>>> 
>>>> Also, the AU Hosting Guide docs talk about I/O, Mixer and Effect units - 
>>>> is there any other material that focuses on how to do MIDI in AU? Or is a 
>>>> adaptor/translator layer necessary?
>>>> 
>>>> Thanks for any pointers,
>>>> Igor
>> 
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list      ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/coreaudio-api/paul%40linuxaudiosystems.com
>> 
>> This email sent to [email protected]
> 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to