Hi-hi,
This might be a dumb question, but anyway.
So I wanted to get a better understanding of the structure used in the Ugens
that come with the 3.12.0 build for Windows.
Browsing through the Supercollider program files from the install led me to
c:/Program files/Supercollider 3.12.0/plugins
All of these files look like files for the Ugens but they’re all SCX files.
I’ve never encountered that file extension so I looked it up and apparently the best
guess I have is that they are Visual FoxPro files. Do these files contain the actual DSP code for the Ugens or are they for something else? How do I open them? I don’t trust any sites selling
Visual FoxPro 9 since it is no longer supported or being developed. I did find this link
to Microsoft’s OLE DB Provider for FoxPro 8: https://www.microsoft.com/en-us/download/details.aspx?id=32602
But I don’t know how you would use it to open and view the SCX files.
When I open the SCX file for OSCUgens in notepad I get a ton of non-ascii characters and the whole file (except for some comment lines) look like gibberish.
This is awesome! Thank you!
I’ve been looking for this for a while and could never find any clear answers.
I admit, I was expecting the OSC Ugen to be like tops 300 lines of code. This whole OSC Ugen is
well over 3000 lines of code. This should be fun going through it and figuring it out though!
Cheers!
I cannot find scx files in my linux system though.
The thing with that cpp file is that it contains not just Osc, but a whole bunch of other osc based ugens. It may be that the code to just run through the wavetable is about 300 lines instead of 3000 lines, makes sense doesn’t it?
It could be fun to have an official tutorial on how to write a ugen. On the other hand, there’s the Faust project, where you can do an ascii graph of an audio flow and have that transpile into c++ supercollider code. Maybe that can generate more insights.
The OscUGens.cpp file (and the corresponding .scx file) actually a lot of different UGens - check the PluginLoad function at the bottom. This registers each ugen in this particular plugin - you can search for the names in that file to find the source code. You can search for PluginLoad in the entire SuperCollider codebase to find all of the places where UGens are defined.
In general, UGens (especially “core” ugens like oscillators) may have a more opaque or verbose definition than one mighty expect. One of the advantages of SuperCollider’s architecture is that individual UGens can be highly optimized for efficiency (this can be difficult / specialized work and can often leave the source code very difficult to understand), but are usable via a simple interface in a high-level language like sclang.
I think they have a different name on linux, for reason that could maybe be explained by someone that’s more of a Linux pro (this has always been a source of confusion / minor problems).
Faust can be a great way to try out building SuperCollider UGens.
I would say - if someone has general experience with imperative programming (even something like sclang or javascript), it might be easier to experiment with writing UGen’s in C++ (using e.g. the cookiecutter template). There’s a small jump required to understand some C+±isms if you don’t know them already, but your actual DSP code ends up being pretty straightforward to write.
If someone’s coming from a less programming-intensive background - or is more comfortable thinking about things through a math / signal processing lens - Faust is probably a better option. It’s unquestionably a better way to represent signal processing (vs. imperative C++ code), but I think can be counterintuitive for someone who just wants to write a for loop where they do some math.
Finally - writing UGens is a great exercise to learn DSP-related programming things, and there are SOME kinds of processing that are hard to do in SuperCollider unless you write them into a UGen (e.g. IIR filters or processing that involves processing very short delay lines). But, it’s a common misconception that something written as a UGen will be faster/better than something you build in sclang as a SynthDef. This isn’t true - most of the core UGens are highly optimized, which means that unless you’re ready to dive deep into hand-optimizing C++ code, using normal math operators in a SynthDef will be faster than the (non-optimized) equivalent in C++.
It’s also worth mentioning the file with all the buffer related ugens in and it’s use of unsafe macros, which has nothing to do with the performance, yet decrease readability drastically.
Good point, lots of ugly code isn’t ugly for performance reasons - though I think that much of it approaches “best-practice” code for the language it was written in (C++98) and for the time period when it was written.
). You’ll have no luck opening them, but you can see their source code here: