I am interested in using Mojo for use in audio development with CLAP. The point of interest to me is this line specifically:
“The KISS (keep it simple, silly) mantra belongs to CLAP. From the C-only ABI, which allows binding to any programming language, to the transparent client-server model between host and plug-in, the robustness and clarity of the threading model, and the single event queue for all kinds of parameter changes, timing and MIDI. Despite being so comprehensive, everything in CLAP is easy to find and easy to implement.”
After further discussions in the CLAP forum it was determined that Mojo would need a couple of features in order to interface with CLAP:
call and export a c signature function with c types
has enough memory control to make a c structure equivalent
Hey RF is the CLAP community heavy into audio engineering? I’m a big music head myself. Afaik this framework is feasible with Mojo. The ecosystem is still maturing. I was wondering about this the other day how Mojo can be built out in audio engineering applications. Really cool!
Hello, @rcmpge. Thank you for the reply. It is indeed very interesting to potentially use Mojo for developing audio applications. When you mention mojo potentially being compatible with CLAP, are you familiar with using mojo to accomplish any of the three “features” outlined above?
A little. I cook in Mojo when I’m not busy with school. Mojo’s interfacing features are being ironed out. There is a sys package with ffi module for foreign function interface. The stdlib itself is very versatile I have only made time to learn Mojo fundamentals during my spare time
Mojo has an external_call function which can be used to call a C API. Structs right now are mostly C ABI if you keep them as C structs, and we should get an explicit @abi("C") or similar before that changes.
Threading is a bit more messy, since Mojo is still working out threading safety. If you want real time for audio, a separate process and shared memory IPC may be easiest.
I’ve been looking more into external_call with this repo that discusses different ways to link / interact this C libraries. I might be outdated by now, but I haven’t made it that far yet.
In terms of threading, what does the current mojo documentation look like?
That repo is ancient. mojo -l$LIBRARY foo.mojo should do static linking.
As far as threading, the current supported way to do it inside of mojo is to use parallelize with an @parameter if to dispatch tasks. fork(2) also works.
@RandomForest is CLAP for mainly professional music production equipment? like studio equipment synthesizers and stuffs. What about production software or for car audio applications like amplifiers, capacitors, speakers, subwoofers, to the car dash.
Thanks for the update on static linking. For context, it may helpful for me to share the threading model of CLAP. After further discussion, it seems that having an audio application utilize only the audio thread at this time is my best bet. Utilizing both the audio and main thread may be challenging in mojo at this point?
Regarding CLAP I’ll refer to their website which outlines the following:
CLAP stands for CLever Audio Plug-in. It is an audio plug-in ABI which defines a standard for Digital Audio Workstations and audio plug-ins (synthesizers, audio effects, …) to work together.
So I think the production software you outlined for car audio applications may be out of scope. However, I have not worked with CLAP enough to feel comfortable giving a more definitive answer than that .
is the CLAP community heavy into audio engineering? I’m a big music head myself. Afaik this framework is feasible with Mojo. The ecosystem is still maturing. I was wondering about this the other day how Mojo can be built out in audio engineering applications. Really cool! 
too!
.