Create a faust2dpf

[SpotlightKid]

I know, this is probably not exactly what this ticket is about, but a while ago, I created a cookiecutter project template to easily create DPF plugin projects using faustpp:

https://github.com/SpotlightKid/cookiecutter-dpf-faust

I used it to create several plugin projects from simple to medium-complex FAUST source files:

• https://github.com/SpotlightKid/dfzitarev1
• https://github.com/SpotlightKid/sendmixer
• https://github.com/SpotlightKid/stereocrossdelay

I hope it's ok to plug this here :)

[falkTX]

I am going to put this on myself to do. Looking around to understand how faustpp works, seems quite similar to a few other templating tools, so it looks doable to have it directly output dpf compatible files.

I keep seeing a separation of core dsp and more high level implementation, is there a reason for this? seems to me the templating can skip generating 2 sets of files (core and high level) and just do 1 with both combined.

to be clear, my idea is to generate mostly-complete dpf C++ files, but still leaving room to customize it further, because I expect a few details to just not be there in the faust side (like description and lv2 plugin uri). or can we arbitrarily define new properties in the faust dsp file and faustpp will read those custom props?

[jpcima]

I am going to put this on myself to do.

I think it personally as a waste of time. There are some ubiquitous things that faust can't do by self, until the future ondemand feature opens such possibilities. That is, no true bypass, no oversampling. Hence, I have no interest in writing any faust-only plugins. It seems more useful to go with the faust wrapper class, like iPlug2 has.

I keep seeing a separation of core dsp and more high level implementation, is there a reason for this?

faust generates its dsp inlined in a single header. Isolated inside the .cpp file, the compilation time is reduced.

Beside, this allows to designed the interface how dsp is interacted with by code. That of faust dsp is unlikable in some aspects; eg. one should be careful against doing init() in response to sample rate changed, this also resets parameter values to defaults, which is never wanted in a plugin.

or can we arbitrarily define new properties in the faust dsp file and faustpp will read those custom props?

There can be custom props at file or function level.

[falkTX]

I am going to put this on myself to do.

I think it personally as a waste of time. There are some ubiquitous things that faust can't do by self, until the future ondemand feature opens such possibilities. That is, no true bypass, no oversampling. Hence, I have no interest in writing any faust-only plugins. It seems more useful to go with the faust wrapper class, like iPlug2 has.

I am not sure what you mean here.

You find direct faust-to-plugin/frameworks a bit useless? can you please describe how iPlug2 does it different that seems to be much better?

for the case of bypass, seems to me in my naive little knowledge of faust that we can just have a regular slider-like control and assign it as the bypass/enabled control, which then dpf could easily map it.

as I see it, faust to plugin c++ file can be quite handy for a quick start of projects. my idea here is to only have it do the dsp side, with everything else from project setup (makefile etc) to UI being handled separately.

you obviously have more experience with faust than me, so any extra feedback on these topics is welcome.

[jpcima]

You find direct faust-to-plugin/frameworks a bit useless?

At the risk of being brutally honest, yes; until faust does ondemand, there exist need to complete the plugin with c++ code.

can you please describe how iPlug2 does it different that seems to be much better?

It's a generic wrapper. Not reliant on template tools like this one. This was presented at IFC before, you should check: https://www.youtube.com/watch?v=SLHGxBYeID4

for the case of bypass, seems to me in my naive little knowledge of faust that we can just have a regular slider-like control and assign it as the bypass/enabled control, which then dpf could easily map it.

It's true, but this is the catch: There's no expression such as "if Thing; then This; else That" It computes all the branches and there's no skipping it. That is, even if it results like a bypass, it still burns the cpu cycles.

Precisely, that's what the "ondemand" feature is supposed to solve.

as I see it, faust to plugin c++ file can be quite handy for a quick start of projects.

No doubt, but more so if there exists room around the faust source to implement these side features, like resampling/bypass.

IIRC, you can have a IPlug2 wrapped faust effect, and make it export the faust parameters into plugin parameters. That means, it's your choice how to integrate in the plugin, or make it part of a larger assembly, of multiple faust and c++ elements.

[falkTX]

that is very helpful, thanks.

the bypass case is a good one for extending the provided code, dealing with tempo sync might be another.

still seems possible to me to have a template file that deals with such advanced things automatically, because we can pass arbitrary arguments to the generation of the file. it can increase the complexity of the template, but this is a static file that only needs to be done once, devs using the template likely wont even see its internals. so for example bypass can be enabled as a template feature, which is then implemented on the plugin side instead of faust side. similarly to time-based FX, we can have the template allowing to map 1 slider value to a tempo related value (say, bpm or ppq pos).

there needs to be a way to report latency too. I am not sure if we can extract such info from faust files, if yes it could be a passive-like control output that is mapped to latency reporting. or worst case have it as metadata if we know it is a static/fixed value, we just need to define it in time/seconds and have the dpf plugin side convert it to frames.

I will watch that video next.

[jpcima]

there needs to be a way to report latency too

Yes, faust has the equivalent of output parameters. These are generated by bargraph primitives. (normally intented for value displays) See: https://faustdoc.grame.fr/manual/syntax/#hbargraph-primitive

[falkTX]

just watched the video, it does not have many implementation details, but the part of integrating something with JIT was quite nice to see. just for that feature it seems worth to keep faust stuff on its dedicated block, at least the part that does processing.

an initial version can still work with compiled files, then extend the dpf plugin class to provide a custom run that does JIT. so it is up to the developer which processing method to use, and easy to switch by compiling different files.

will start on this later today or tomorrow, for simple dpf template first

[falkTX]

I have setup a project where I will be doing experiments with faustpp and dpf at https://github.com/DISTRHO/Fadeli Early results are very good, I copied some faust demo/example files and tried a few, works quite well.

I am doing the LV2 ttl export directly with faustpp as well, instead of relying on DPF for that. This way we do not need to run the generated binaries in order to have the LV2 ttl stuff generated. faustpp can be built for the host platform/system, while the plugins are then cross-compiled for something else entirely.

For the moment I am not bothering with UI stuff, that typically is best handled on a case-by-case basis with a custom implementation anyhow.