Noob: looking for details on using SynthDesc

Questions
1

In this post, @dkmayer mentions using makeGui to create a GUI for metadata specs in a SynthDef. While this automatic GUI creation is very conventient for me, I am missing some information about how to use it. I read the help on SynthDescLib, SynthDesc and ControlSpec, but am still not clear about the following:

  • How can I specify a lag time to a control in its metadata?
  • How can I change the length of the sliders in the GUI (with the goal to get a higher resolution)? Changing the window width just makes the window wider, while the sliders stick at the original length.
  • Is there a way to temporarily engage a “fine” control when interacting with a slider, to achieve a higher resolution?

Thanks much in advance, have a happy holiday season/merry christmas/fröhliche Weihnachten!

2

How can I specify a lag time to a control in its metadata?

A ControlSpec only specifies the range/curve/step size/label of a control’s corresponding GUI element. If you want to specify a lag time, you have to do that on the SynthDef level. SynthDef.new has a rates argument which expects an array of rate specifications:

(
SynthDef(\ratesTest, { |out, freq=440|
	Out.ar(out, SinOsc.ar(freq) * Env.perc.ar(2));
}, rates: [0, 4] // lag freq (second arg) by 4 seconds
).add;
)

If you use NamedControls in your SynthDefs, you can set a lag time directly upon instantiation (it’s the second argument, after the default value):

(
SynthDef(\ratesTest, { |out|
	Out.ar(out, SinOsc.ar(\freq.kr(440, 4)) * Env.perc.ar(2));
}).add;
)

Or just use one of the simple UGen wrapper methods directly in the UGen graph function: .lag, .lag2, .lag3, .lagud, lag2ud, lag3ud, .varlag.

  • How can I specify a lag time to a control in its metadata?
  • Is there a way to temporarily engage a “fine” control when interacting with a slider, to achieve a higher resolution?

I can’t think of an easy way to do this without modifying .makeGui’s implementation - it would have to be rewritten using layout management classes (HLayout/VLayout) to enable stretching the sliders to arbitrary widths, and I don’t know any slider class with a fine control feature. I agree this would be great to have, though!

Edit: Forgot to mention, you can do relatively fine adjustments by selecting a slider and pressing up/down arrow (or left/right, does the same thing) - this increments or decrements the slider value by the amount specified by the Slider’s step instance variable. Pressing “r” randomizes the slider value. See here.

1 Like
3

Thank you, this makes things a lot clearer for me, especially reading about the rates argument!

I tried using the up/down or left/right buttons, but from what I can tell these use the same decrements/increments steps as the fader. What is puzzling is that step values <1 don’t seem to make a difference in slider resolution. Is this intentional?

P.S. One side question: Is there any easier way to get the “direct” URL of a page’s content (e.g. to this one) than looking into the page’s source code, find its href “#-defaultKeyDownAction” and paste it after the page’s URL?

4

The wrench icon below posts has a “link” button that will give you a perma-link.

Sadly, makeGui is about 15 years old, and has been limping along through a few generations of UI implementations in SuperCollider. I’m honestly surprised it works at all (a testament to the backwards compatibility of sclang I guess…), but it definitely isn’t built in a way that matches the UI infrastructure now. It probably needs to be rewritten before it will have things like dynamic resizing.

1 Like
5

If you’re referring the the sccode.org docs, what I usually do is find the relevant part in the table of contents (shown on the top right of the page), then click on it - you should then see the relevant bit appended in the URL bar.

1 Like
6

Thank you – believe it or not, up until now I did not even knew that a table of content existed there, I simply overlooked it all the time!

Thanks for the clarification, I am grateful it exists at all, and even with its shortcomings I wish I would have learned about it earlier :slight_smile:

7

Just out of curiosity (as I am not a developer and have only the most rudimentary knowledge about programming): If I file an enhancement request in GitHub for adding a fine control feature to the Slider class, and somebody would be so kind to implement it, would this mean that also the sliders used by makeGui will also have this new fine control?

8

For what it’s worth, I had the same experience when I was starting out :slight_smile:

Hm, I can’t think of any reason why that wouldn’t be the case if someone did add that feature to the Slider class without breaking compatibility… However, I think the Slider class is just a sort of wrapper around a slider element in Qt and can’t really be easily extended with new features like that. It’s certainly not impossible - I know some people have written their own GUI classes by drawing everything manually using Pen inside of a View, for example EnvScaleView - but the code look pretty daunting to me :grimacing: (note, this is way out of my depth and maybe more experienced GUI devs could chime in here)

Edit: A (maybe overly) simple solution for your use case: if you need separate “coarse” and “fine” controls for, say, an oscillator frequency, why not make two separate controls? Something like

// inside graph func
SinOsc.ar(\coarseFreq.kr(440) + \fineFreq.kr(0))

// later:
Spec.add(\coarseFreq, [-20, 20, \lin, 0, 0, " Hz"]);
Spec.add(\fineFreq, [20, 20000, \exp, 0, 440, " Hz"]);