Using Faust programs in Csound/Cabbage

[nymano]

Hi,

One of my current projects involves modeling a linear circuit, and thanks to Faust’s WDF filter it can be done easily in Faust. There is a way to use Faust code in Csound thanks to the faust plugin.

Before going further I have two questions:

• Are they ways to use the UI parameters (knobs, sliders…) in the Faust code?
  Based on my understanding of the code below, the faust code would need to be re-compiled everytime we’d like to pass a new parameter. And I’m not really sure the syntax allow us to add a variable in the faust code. https://csound.com/docs/manual/faustaudio.html
• Is it realistic to ship the Faust plugin (opcodes) with my VST? There are no compiled binaries so I would need to do it myself for each architecture. I think it is as straightforward as installing Csound but maybe I’m missing something…

If it’s something that wouldn’t be performant and too hard to implement I’ll skip this project, but I wanted to check if someone tried it first and if it was potentially feasible.

Thanks!

Julien

[rorywalsh]

I don’t think you can update parameters in realtime but I’m awaiting confirmation from the author. You can output your faust code to c++. In which case you could build your own opcode, or I can look into doing it for you if you like. I think that would be the simplest, and then I could embed that opcode into your pro build so you don’t need to worry about including dlls and what not.

[rorywalsh]

You can control parameters using faustctl. And you can also output Csound opcode code from Faust directly. I think that might be the best approach.

[nymano]

Thanks Rory!

I’ll take a look at faustctl, I totally missed it while doing my research. And I’ll see if I can output a Csound opcode, it can definitely be a great way to implement it!

I’ll keep you updated. FYI I’m trying to implement features of the Pultec EQP-1A passive EQ and doing it in Csound only looks very hard, which is why I’m trying to use Faust.

I’ll post the code here once I manage to make it work.

Julien

[nymano]

Hi @rorywalsh,

Thanks for your help, here is a guide and a working example:

This is how you can use the “osc.dsp” example from Faust in Cabbage. The controls can be done with Cabbage, and control the freq and gain parameters in Faust.

1/ Go here: https://faustide.grame.fr/

2/ Export your Faust code as an opcode:

3/ Import the opcode in Cabbage and use it

<Cabbage>
form caption("Faust Opcode") size(400, 300), guiMode("queue") pluginId("def1") colour(0,0,0)
rslider bounds(30, 98, 75, 72), channel("opcodegain"), range(-96, 0, 0, 1, 0.01), text("OpcodeGain")
rslider  bounds(32, 16, 70, 70), channel("opcodefreq"), text("OpcodeFreq"), range(20, 20000, 1000, 0.333)
rslider bounds(266, 178, 100, 100), channel("gain"), range(0, 1, 0, 1, 0.01), text("Gain")

</Cabbage>
<CsoundSynthesizer>

<CsOptions>
-n -d --opcode-lib=full_path_to_opcode/osc.dylib
</CsOptions>

<CsInstruments>
; Initialize the global variables. 
ksmps = 32
nchnls = 2
0dbfs = 1

instr 1
kGain cabbageGetValue "gain"
kOpcodeGain cabbageGetValue "opcodegain"
kOpcodeFreq cabbageGetValue "opcodefreq"

; Generate osc with custom opcode 
asig   osc  kOpcodeFreq, kOpcodeGain
outs asig*kGain, asig*kGain
endin

</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
;starts instrument 1 and runs it for a week
i1 0 [60*60*24*7] 
</CsScore>
</CsoundSynthesizer>

And that’s it!

I still need to figure out a few things:

• Loading the .dylib file wasn’t working because of security issues. I codesigned the file but the error was the same. I had to manually open the dylib to be able to load the file in Cabbage
• You need one export per platform (osx, windows…). I’m not sure this is compatible with Intel and ARMS macs for example. I need to test it.

But is is encouraging! Next step for me: convert and use the Pultec .dsp code.

[rorywalsh]

Wow, I didn’t think it would compile it for you too. That’s neat. The simplest way around the signing issues is for me to build the opcode into your pro build of Cabbage. Then you don’t have to worry about compiling for different platforms. At least that’s how I would approach it.

[nymano]

I agree, this is impressive!

@rorywalsh

The simplest way around the signing issues is for me to build the opcode into your pro build of Cabbage.

I’m worried about the maintenance cost/time it would imply. It means that everytime the opcode needs to be updated, I would need to send it to you and it would be time consuming for you (even though I imagine these opcodes would be rarely updated…)

I will first test the Pultec code and see if I want to release it as a VST and get back to you if needed! Maybe I could also try to build it in my Azure Pipeline so I can do it on my own. I never did that so I don’t know how hard it is though.

I would just need to understand how to use faust2csound in my pipeline: https://faustdoc.grame.fr/manual/tools/

Thank you very much for your help!

[rorywalsh]

@nymano

I’m worried about the maintenance cost/time it would imply. It means that everytime the opcode needs to be updated, I would need to send it to you and it would be time consuming for you (even though I imagine these opcodes would be rarely updated…)

I wouldn’t imagine that I would not have to build them in until you are almost ready to release your plugin and by that stage the opcode will be pretty much finished? Anyway, keep me posted on your progress, it’s definitely a cool way of harnessing the power of FAUST in a plugin.

[Bryan_T]

I’m working through Lazarini’s 2017 book, which incorporates Faust, Csound, and Python. Faust is new to me and looks interesting.

That said, I’d like to better understand the pros/cons of incorporating Faust into a project.

Programmer’s time - probably depends on the user. The Faust syntax looks pretty wild at first glance. But it looks particularly tailored to some tasks, making it efficient.

Performance - I have no idea. I’d love to understand how to benchmark performance for the same task being handled by Faust vs a UDO in Csound vs “normal” Csound.

Usability/distribution - It sounds like Faust adds a layer to this. It might not be a big deal. But it is another thing to maintain.

I’m really just dipping my toes into this stuff, so I’d love to hear opinions.

[rorywalsh]

I’ve never used Faust, but it’s well respected in the audio developer community. Using the faust opcodes does come with some overhead, I’m not sure about performance, but the opcodes themselves are quite large, and distributing them could be troublesome. As @nymano has shown, it’s quite simple to create a Csound opcodes from your faust code, and then include that. For me this is a better option, as you end up with a smaller opcode binary. Distributing this will not be without its challenges either, but should be possible. As for performance, I’d expect that a compiled plugin opcode will always out perform a UDO, or a Csound instrument. Csound code generally runs about a 3rd of the speed of natively compiled code, but that’s quite a generalisation.

p.s. I have no hard evidence of this, it’s just something I’ve heard anecdotally from Csound devs over the years

[Bryan_T]

Thanks for the insights.

What I’m going back and forth on is how to handle the dry signal in my looper plug-in. If I open that audio up, then I have to deal with the latency issues that arise. A justification for opening it up would be to do things like filter it, which then leads me down the path of deciding what the most efficient way to filter would be (csound opcode, my own csound code, my own UDO, Faust DSP, something else I don’t know about, …).

For filters on the loops the performance isn’t a big deal. But I’m trying to minimize latency on the (mostly) dry audio.

[rorywalsh]

Cabbage plugins use PDC ( plugin delay compensation ) that will match the ksmps, so latency shouldn’t be that huge a deal. If you really want 0 latency, use latency(-1) in your form declaration. It will cause Cabbage to do processing in place, but it may cause your plugin to perform poorly in terms of CPU cycles. It’s a constant battle

[nymano]

I made a plugin with a lot of latency, and as Rory said with PDC it shouldn’t be a problem for most users, unless the latency is too high for live performance.

Based on a soundonsound article I read recently, Soothe 2 has a ~45ms latency, if it can help you feel better about that…

[Bryan_T]

It is the live use that will make/break it for me. Right now, I’m bussing the audio to the plug-in and keeping it 100% wet. Things that make it feel less like a physical instrument (audio latency, control latency) are genuine concerns for me.