What would be a best practice to integrate FAUST-generated Plugins?

[florian-grond]

Given that FAUST is getting ever more popular and will be a great codebase that can contribute to the SC3-plugins, how should we define best practices:

Some issues:

1. Naming convention: FAUST plugins have Faust as a prefix
2. How can we include or refer to the Faust sources
3. should Faust generated SC code (the .sc representation of the UGen) be modified or not.

[telephon]

Is there a possibility to change anything about 1. and 3.? That is, could we propose improvements to the faust to supercollider code generation?

[LFSaw]

this is an issue emerging from #147 and #143 .

[LFSaw]

@telephon, the FAUST developers are very active and responsive, so yes, possibly so.

[telephon]

Should we work out a kind of optimal idea from the sc side and then suggest this to the FAUST developers?

[florian-grond]

My experience from the ambitools implementation from Pierre Lecomte (which is complex and therefore a good example, I think) and compiling it for SC is the following:

1. Big FAUST projects can come with their own non-standard libraries to organize code better, this is one reason why there is not necessarily a simple FAUST source -> cpp file relationship (in a sense that this source can be easily compiled without running into dependency issues)
   However if while compiling these sources get assembled at some point this is what we might want to catch as sources to be included with the plugin code. No idea if this is feasible.

2. It would be awesome if the faust2supercollider script could also generate an SC helpfile.
   Even cooler if code comments in FAUST, e.g. for the in and out busses could be translated into this helpfile. This helpfile could then feature prominently that this UGen was compiled with FAUST with all sorts of version and author info, the later extracted from the .dsp file.
   Then the FAUST prefix for the UGen could possibly be dropped and FAUST leaves its traces.

3. FAUST code is a bit cryptic for the beginner (and continues to be cryptic for me), the autogenerated cpp file is pretty much unreadable. But FAUST can make fantastic svg graphics of the signal flow, this would be great to include in the helpfile which would add didactic value of what this UGen is actually doing. maybe this cann all be done through the faust2supercollider script.
   I believe this would be a real incentive to use FAUST and SC in teaching contexts.

4. In general, I'm wondering if there are mechanisms to carry over data structures from the dsp file into the SC class. To give an example, Ambisonics decoders necessarily need the info about speaker positions which is important information for generating the decoding matrix. So it would be cool to have those positions in the dsp file somewhere and then translate them into say a class variable of the SC class file so that they can be later accessed when building monitoring GUIs that visualize the speakers etc.

[telephon]

These are really good ideas, @florian-grond. Let's see what can be done. I certainly can offer to help thinking through of the sc-class file generation.

[florian-grond]

I believe most of the ideas above need to be implemented on the FAUST side. @LFSaw, I'm sure you would have a wishlist yourself ;-)
I would suspect that FAUST developers might be inclined to put effort into this if the potential impact is beyond SC.
Defining best practices to document code in FAUST and translating this documentation into other platforms might be such a thing.

[florian-grond]

I was just reading up on code documentation options in FAUST:
see section 9 in this doc:
http://faust.grame.fr/images/faust-quick-reference.pdf

There is plenty of stuff addressing many of the points from above.
Any thoughts on how to best translate that into SC helpfiles?

@LFSaw Just looking at the info you have compiled here:
sc3-plugins/source/DEINDUGens/faust_src/README.md

if you have a moment to read the section 9 in the link to the FAUST documentation from above, the command faust2mathdoc, in fact, addresses many of the ideas discussed here already, just that it produces a PDF and would like to have a SC helpfile.

One point that I think we could discuss with the FAUST devs is how to best document in and out busses. This could potentially translate into many other platforms (PD, MaxMSP, etc.) where the function of in and outlets also needs to be documented.

[telephon]

@florian-grond so you mean this section?

9.4 Automatic documentation

By default, when no tag can be found in the input FAUST file, the -mdoc option automatically generates a LATEX file with four sections:

1. ”Equations of process”, gathering all formulas needed for process,
2. ”Block-diagram schema of process”, showing the top-level block-diagram of
   process,
3. ”Notice of this documentation”, summing up generation and conventions
   information,
4. ”Complete listing of the input code”, listing all needed input files (including libraries).

So the main point would be to convert that LaTeX-file into schelp?

[florian-grond]

yes, this is the section I mean, and yes, this would be the main point: translating the LaTeX-file into schelp.
I am wondering though if we could extract from this a proper description of the audio in and out busses for the schelp file. So I thought we might want to enquire for this with the FAUST devs, how they think this should be properly documented in the FAUST file, and then find out how to translate this into the schelp file.

[telephon]

yes, this sounds good. In FAUST, all arguments of a unit are single channel streams of floats, right? So the regrouping for supercollider is a thing that probably we could take care of separately. In general, all inputs that have numbers, like a1, a2 etc. should probably be grouped to an array.

[florian-grond]

Yes, the regrouping we could take care of separately, we just need to find out how to properly document inputs (outputs) in FAUST. I think this should be of general interest, while less necessary for plugins with a GUI, platforms like MaxMSP and PureData also need to document their inlets and outlets. I'll enquire with the FAUST devs ...

[jamshark70]

I'm not sure if I should mention it here as a side note, or open a separate issue for it, but -- if we're discussing FAUST integration, I'd like to suggest removing the plug-in load messages from the default verbosity level:

booting server 'localhost' on address: 127.0.0.1:57110
Faust: supercollider.cpp: sc_api_version = 2
Faust: FaustJPverbRaw numControls=11
Faust: supercollider.cpp: sc_api_version = 2
Faust: FaustGreyholeRaw numControls=7
Found 370 LADSPA plugins
JackDriver: client name is 'SuperCollider' ... etc

The four Faust lines are not necessary. During normal usage, sc_api_version and numControls are totally, 100% irrelevant to anything that users care about. They are relevant only to be sure SC is picking up the Faust definition properly.

Currently there are just two Faust plug-ins, so it's not too much output -- it is irritating but not overwhelming. But if "FAUST is getting ever more popular and will be a great codebase that can contribute to the SC3-plugins" and eventually we have more Faust-generated plug-ins, the extra output may well become a burden.

I think we could safely remove it completely. But, if some people feel it would be useful for debugging new plug-ins, then I would suggest adding a new verbosity level 1 (debug level) and print these messages only for that level.

[florian-grond]

This output is showing in the postwindow only if the plugins are compiled from the cpp source which usually don't set the -NDEBUG flag. If compiled with the faust2supercollider script this message doesn't show. I agree, we should suppress this. On Jul 18, 2017 11:32 AM, "H. James Harkins" <notifications@github.com> wrote: I'm not sure if I should mention it here as a side note, or open a separate issue for it, but -- if we're discussing FAUST integration, I'd like to suggest removing the plug-in load messages from the default verbosity level: booting server 'localhost' on address: 127.0.0.1:57110 Faust: supercollider.cpp: sc_api_version = 2 Faust: FaustJPverbRaw numControls=11 Faust: supercollider.cpp: sc_api_version = 2 Faust: FaustGreyholeRaw numControls=7 Found 370 LADSPA plugins JackDriver: client name is 'SuperCollider' ... etc The four Faust lines are not necessary. During normal usage, sc_api_version and numControls are totally, 100% irrelevant to anything that users care about. They are relevant only to be sure SC is picking up the Faust definition properly. Currently there are just two Faust plug-ins, so it's not too much output -- it is irritating but not overwhelming. But if "FAUST is getting ever more popular and will be a great codebase that can contribute to the SC3-plugins" and eventually we have more Faust-generated plug-ins, the extra output may well become a burden. I think we could safely remove it completely. But, if some people feel it would be useful for debugging new plug-ins, then I would suggest adding a new verbosity level 1 (debug level) and print these messages only for that level. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#147 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVJxvnH3frxYCQi0Ia-1zIA1QHMFNCzks5sPM_CgaJpZM4NweUs> .