FAUST Ugen Arguments In Alphabetical Order

Development Faust
1

I wanted to import FAUST jpverb into SC, so I exported this as osx → supercollider in the web IDE (as I normally would):

import("stdfaust.lib");

decay = vslider("decay", 1, 0.1, 60, 0.1);
damp = vslider("damp", 0.5, 0, 1, 0.01);
size = vslider("size", 2, 0.5, 5, 0.01);
earlyDiff = vslider("earlyDiff", 0.707, 0, 1, 0.001);
modDepth = vslider("modDepth", 0, 0, 1, 0.001);
modFreq = vslider("modFreq", 0, 0, 10, 0.001);
low = vslider("low", 0, 0, 1, 0.001);
mid = vslider("mid", 0, 0, 1, 0.001);
high = vslider("high", 0, 0, 1, 0.001);
lowCut = vslider("lowCut", 2000, 100, 6000, 1);
highCut =vslider("highCut", 10000, 1000, 10000, 1);

process = _,_:re.jpverb(decay, damp, size, earlyDiff, modDepth, modFreq, low, mid, high, lowCut, highCut):_,_;

Note the order of the arguments.

When I add the files to SC, all of the arguments except for in1 and in2 are now inexplicably in ALPHABETICAL ORDER, and I’m at a loss as to what they now represent.

JPVerb : MultiOutUGen
{
  *ar { | in1, in2, damp(0.5), decay(1.0), earlydiff(0.707), high(0.0), highcut(10000.0), low(0.0), lowcut(2000.0), mid(0.0), moddepth(0.0), modfreq(0.0), size(2.0) |
      ^this.multiNew('audio', in1, in2, damp, decay, earlydiff, high, highcut, low, lowcut, mid, moddepth, modfreq, size)
  }

  checkInputs {
    if (rate == 'audio', {
      2.do({|i|
        if (inputs.at(i).rate != 'audio', {
          ^(" input at index " + i + "(" + inputs.at(i) +
            ") is not audio rate");
        });
      });
    });
    ^this.checkValidInputs
  }

  init { | ... theInputs |
      inputs = theInputs
      ^this.initOutputs(2, rate)
  }

  name { ^"JPVerb" }


  info { ^"Generated with Faust" }
}

How did this happen, how can I fix it, and are the arguments now reordered or are the argument names just wrong? I haven’t noticed this before because all I had were filters with in, freq, and q or resonance arguments, which would stay in that order regardless.

2

Hi Josiah. This happens in the Ruby script that the IDE uses to compile the plugin. The Ruby script will use the slider names as arguments in the class. Why don’t you think they aren’t correlated to the names of the sliders?

3

If you want them in the order you put them, I think you just need to comment out the sliders. Then the arguments won’t have names (it will just be in0, in1, in2, etc) in the sc file, but they should be in the order you listed. I have no idea why they are alphabetized, btw. Seems like a funny choice.

If you want to give them names in the SC file, you have to edit the file after it is autogenerated by faust.

Sam

4

I’m just wondering whether the order of the arguments is the same or the names of the arguments are the same.
That would determine whether I should rename the arguments in the SC file or keep them how they are.
In other words the question is “are the index values for the argument array the same (with the addition of the inputs at the beginning) or is the ‘damp’ argument always the reverb high frequency dampening even though it’s now the first argument after the inputs?”
The former seems more likely but I’m not sure…
I think the fact that the default values were moved along with the argument names bothers me.