Faust2sc.py - A python rewrite of the faust to supercollider tools

Hello all

There are some bugs and inconsistencies in the current faust tools for converting to supercollider plugins. As a fix for these and as a way to add new features, I’ve rewritten all of the tools as one python based script that converts the faust file to help files, class files and server objects and has additional nice little features.

This will eventually be submitted as a PR to faust itself, but I would appreciate if others would like to test it before then.

5 Likes

Great work! As far as I know, the Faust devs are mostly focusing their efforts on the online IDE these days, so this rewrite will be very useful for maintenance in the future. Does the scsynth object file compilation work on Windows?

That’s something I would like someone to test. I don’t use Windows so I have no clue but the tool is written using OS agnostic paths so hopefully that part of it works but I have no idea until someone tests it out

Thanks a lot! I will test this.

1 Like

I have some spare time next week to help with testing on Windows/macOS

1 Like

Awesome to hear !!

Also, another advantage of this rewrite is that it is easier to maintain so if you have feature requests feel free to add them as issues on GitHub.

2 Likes

Tested with turning a few things from the Faust libraries into simple classes - everything works flawlessly so far here on Arch!

Mads,

An observation and a question:

  1. Just got an M1pro Mac. on my machine, running:
python3 /Users/spluta1/Documents/faust/faust2sc.py-main/faust2sc.py MoogLadderB.dsp -p /Users/spluta1/Documents/SC/SuperColliderBuild/supercollider-develop 

I get:

c++ -O3 -DNO_LIBSNDFILE -DSC_LINUX -shared -fPIC -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider-develop/include/plugin_interface -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider-develop/include/common -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider-develop/include/server -I/opt/homebrew/Cellar/faust/2.37.3/include
 -I/Users/spluta1/Documents/faust/CompiledPlugins/MoogLadder -std=c++11 -Ofast -Dmydsp="FaustMoogLadderB" -o /var/folders/xv/87l9xsnj5_v143786vzmb4m5qd0yd7/T/faust.owjrtpvm/FaustMoogLadderB.so MoogLadderB.cpp

and it spits out a .so linux file. I put a “print (systemType)” in there to see if it was confused, but it spits out Darwin, so it at least has that correct

  1. being that this is an M1 machine, what is the best way to get this script to spit out a .scx file that will work on my machine? I was planning to stick to Rosetta for the time being.

Thanks for your work!

Sam

1 Like

Thanks for testing !! first tlooks like a system detection bug. Will look into that.

The other is actually something thatltivated me here as well. We can do this by allowing arbirtrtary C++ compiler flags being input and/or a separate command line flag for forcing either Rosetta or native arm builds for macOS.i think the letter is easiest to use but the former is probably nice as alternative for the hardcore compiler people. What do you think of something like --macos rosetta to enforce Rosetta builds on M1?

That sounds like a nice solution. Easy peesy. I was a bit bummed today when the Faust stuff wasn’t working. Everything else seems fine. But I can test that out if you make it work that way.

Actually, it is somehow running both the systemType==‘Darwin’ and systemType!=‘Darwin’
If I comment out the stuff under: if systemType != ‘DARWIN’:
it compiles.

BTW - would you be amenable to making the default behavior so it doesn’t put the ‘Faust’ prefix? Or I could just check the flag. Either way.

Thanks again.

Sam

edit: it compiles, but SC tells me the architecture is incompatible
edit 2: the .sc files that are created have funny commas at the end of the argument list and multiNew call that mess with the compiler on Mac. Not sure about linux, etc:

 *ar{|in0, in1, in2,|
      ^this.multiNew('audio', in0, in1, in2,)
    }
1 Like

Thanks for the report!

I’ll fix the M1 stuff today. It was something really annoying with the original as well and I’ve used a modified version of the original that makes it possible to enforce rosetta compilation actually. Anyway, will add the flag here :slight_smile:

Changed some things now so you can test again:

The non darwin build stuff was caused by a typo but should be fixd now.

The trailing comma is also fixed.

The noprefix is default.

I added a --macosarch flag that I haven’t tested because I’m not on a M1 now but if you could test that that would be great

1 Like

Tested it on one plugin and it seems to work great. Thanks so much Mads. This really saves me.

Two features I would want (and I can try to implement these after this weekend):

  1. name the input arguments in accordance with the arguments in the faust code (rather than just in1, in2, etc)

  2. create a flag that automatically adds A2K UGens in the .ar class method, like:

if(riseDur.rate != 'audio', {riseDur = K2A.ar(riseDur)});

I know how to do the second one. Not sure about the first, since the info isn’t in the json file. As I said, this is already a lifesaver, so I could try { to do this next week }.

Sam

1 Like

That’s great Sam. If you feel like doing a PR for #2 then feel free!

Regarding the first. I don’t either see how it’s possible with the json file. One could do this in the python code though and let the user set the input name of input 3 for example and then when the python function that iterates over the inputs to create the argument names hits that index, it could insert the name requested by the user. This is were the inputs are named:

Also, sidenote but one can import this script as a module in python by running import faust2sc from the same folder and experiment with some of the functions for example :slight_smile:

I mention this as a possibility but I’m not sure how feasible it is in practice with a command line interface, but perhaps it could work somehow? Open for ideas!

A couple of observations:

  1. The Faust generated json file actually does label the arguments correctly when the Faust code uses ui elements. So, a faust slider will create a correctly named argument AND the argument will not be required to be audio rate. It just works. I guess I could request that the Faust devs address this in the json generator (to use process() argument names as well), but it is probably low on their priority list.

  2. I think there may not be a solution to this. I would love to store all my Faust stuff in one folder in the Extensions directory. BUT, I don’t think you can compile to sc from there, since on MacOs, that directory is inside the “Application Support” directory, and the c++ compiler can’t deal with the space in the directory name. The c++ compiler tries to compile:

c++ -O3 -DNO_LIBSNDFILE -DSC_DARWIN -bundle -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider/include/plugin_interface -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider/include/common -I/Users/spluta1/Documents/SC/SuperColliderBuild/supercollider/include/server -I/opt/homebrew/Cellar/faust/2.37.3/include -I/Users/spluta1/Library/Application Support/SuperCollider/Extensions/faust_plugins/T3_12AX7 -std=c++11 -Ofast -arch x86_64 -Dmydsp="T312AX7" -o /var/folders/xv/87l9xsnj5_v143786vzmb4m5qd0yd7/T/faust._wpbubuy/T312AX7.scx T3_12AX7.cpp

but the space messes it up. I can’t seem to find any way to make this compilable. I thought “Application\ Support” would work, but it doesn’t. Anyone know a solution?

My “solution” is to make a directory in my Documents folder and add that to my Interpreter preferences and ugenPluginsPath. This allows me to keep all things in one place.

Sam

yep I keep all my SC stuff elsewhere and symlink the Extensions folder, startup and json files to the stupid Application Support folder.

I wonder if there isn’t a python function that can help with the path with a space in it ? Some kind of shell escape or something. Hmm

Hello everyone. Thanks so much for the contributions and feedback. I think we’re fairly ready to submit this as a PR into mainline faust in the not so distant future.

Did you have some things you wanted to add before then @Sam_Pluta ?

I think I will suggest to the faust devs to keep this tool alongside the old ones (for a while at least) so we don’t have to worry about backwards compatibility.

Again, thanks everyone for the PR’s and feedback. Let me know if there is more to be done

1 Like

I saw that, it happened to me too. I guess you can surround the paths with quotes (single inside double or vice versa), like: f'-I"{path}"' (and you could use that very nice f string too, which is >=3.6).