Development of contemporary Ugens for SC

[Stephane_Letz]

@jamshark70

If the precise question is “how can SC have something like gen~” I think an honest answer is, it’s a very hard engineering push, and realistically I think it could happen only if we have a couple really genius developers who are willing to hack at this in, like, all of their spare time for a few years.

This is exactly why I’m somewhat pushing for a much more practical approach: find some interested SC developers to finish something like the FaustGen WIP, which should take like a few days…

[dietcv]

This is a practical solution if you either apply post fx processing independent from your synthesis model or if you want to use an existing VST for synthesis. There are alot of devices out there where also some cool ones are for free, so thats a good option to have.

This is quite specific to my use case, a bit beyond the scope of the initial thread and you might find that completely uninteresting or irrelevant, but in the case of a universal model for granular synthesis with a focus on extended modulation capabilities, which i would like to implement for SC, there is no VST or other device available with what i have already figured out and what i still want to implement and do further investigations on.

For some of its basic features we need single-sample feedback, anti-aliasing and oversampling:

• distribution of overlapping grains of unequal length (resulting from modulation of the trigger frequency and overlap) with detection if a current channel is busy or not
• accumulation of ramps with f(t) = f(t-1) + m instead of f(t) = m * x(t), which would enable FM instead of just PM (PM is fine, however modulational indices for PM are very sensitive in terms of modulation, these either have to be latched to zero crossings of the carrier waveform (undesirable) or smoothed over time, but just using a OnePole filter here is not enough). In some of its details in this specific case FM is also a bit more user friendly then PM.
• cross PM/FM synthesis of different grain chains
• yet some others…

Probably all of these could be handled via your PoC implementation for reblocking and up/downsampling of whole UGen graphs and the addition of the oversampling oscilators with the tradeoff of modularity vs. efficiency. I find modularity very important, one might like to add another non-linearity into the feedback path or something else. With my testings when setting the blocksize to 1 with this specific implementation the CPU is about 40-50% on my computer, mostly because of the multichannel expansion for overlapping the grains in combination with the oversampling, so i would like to figure out what parts should be outsourced for the heavy lifting and know which environment i should use for that, beside programming the whole thing in c++ which im currently still not able to do.
It seems I should start using Faust instead of gen~.

[Sam_Pluta]

It seems I should start using Faust instead of gen~.

I believe you are going to love faust. It thinks the way you think.

find some interested SC developers to finish something like the FaustGen WIP

This would be very smart. faust is awesome. Could be our native gen.

Sam

[jordan]

Given large repos of ugens is hard to maintain (sc3-plugins), we don’t have a package manager, and their is clearly an appetite for ‘ugen’ development that is both easy to share and slots into current usage, might it be worth considering having a faust2sc ugen (when complete - it seems like a great idea!!) distributed with the core plugins? This would allow people to use the existing quark system to distribute their ‘ugen’ code today. When/if we get a ugen package manager, we could make one swift breaking change to remove it again (along with other ugens).

---

I’m wouldn’t mind helping out in any way with Faust ugen, but I’ve got too many prs on the go right now that need a little work. If it is still under development in 6 months or so, I’ll lend a hand where ever I can.

[Spacechild1]

@Stephane_Letz I’m also happy to help again

[Stephane_Letz]

For static ugen production we already have:

• faust2supercollider started in 2010… as a bash script, currently working
• Faust2sc.py started in 2021 by @madskjeldgaard. I don’t know the exact status since I’m not really using it
• Faust.quark

And for dynamic compilation (that is editing/compiling Faust code on the fly), we have FaustGen stated in 2021, but never finished. The idea would put some effort to finish it.

[Sam_Pluta]

Stephane,

Do you know if there is any plan for the online faust compiler to make arm builds of sc plugins (and other osx executables)? This seems long overdue.

Sam

[Stephane_Letz]

We use an old docker with a kind of hack for macOS cross compilation (done by my ex-colleague). I still don’t know how to do ARM cross-compilation, any expertise here ?

[dietcv]

Cool ad:

Entanglement - Quantum Wavefunction Synth

[asher]

faustGen in supercollider would be great!! Regardless if reblocking is implemented at some point in the future it would be useful to have anyway (same with the JSFX suggestion).

[dietcv]

https://youtu.be/n3TCeLG-Yw0?si=UXU3lfsbNoACO74i There is alot Going on in SC Development Right now DynGen for example, I just Keep posting These for Inspiration

[Thor_Madsen]

That is really impressive, are you able to speculate as to the overlap of K-Accumulator and your approach for your suite of plugins?

[dietcv]

Looking at the brief description available via fancysynthesis i can spot some concepts im familiar with and some others im not. Will test the unit and read the manual when its available and look for some nice inspiration. Graham is probably also sharing some interesting insights on the gen~ discord, really looking forward to that

[thresholdpeople]

Can you share an invite to the gen~ discord?

[smoge]

@jamshark70

So I suspect that a more realistic alternative is to leverage an existing toolchain, e.g. FAUST or… is there something else? Our own homegrown solution would feel more integrated from the user’s point of view, but I have doubts about its feasibility.

What if SC objects formed a graph and emitted Faust code, and the server could dynamically load plugins based on that? Let Faust do the really hard stuff.

I agree.

Maybe we are halfway there, starting with FAUST

Compiling the entire SynthDef using UGens’ C++ code (or an intermediary stage) would not yield significant performance improvements.

To achieve this, I understand that you need an intermediary representation that “understands” DSP. The C++ compiler has no idea about that.

A typed IR for DSP (and its compiler, which can be written in Rust or Haskell, for example) is what makes this thing make sense. The possibilities and optimizations are high. Imagine fusing many UGens in the same loop, in the same DSP compiled kernel, no need for buffer, because our little compiler will know when it can be done safely! It will know what it can fuse, or never (at the type level, ofc)

Also, you instead of optimize, you can create things that the “UGen border” does not allow.

I believe FAUST works along those lines. And integrate those two projects would be something significant.

EDIT: and, as I understand, C++20 has features that will even facilitate. Good time to experiments on the side for that.

[jamshark70]

Meanwhile dscheiba leveraged Eelscript to implement DynGen, while people such as myself were whining about how hard it would be

hjh

[smoge]

@dietcv Your granular requirements are the kind of thing that falls awkwardly between “UGen graph” and “write it all in C++.” Good case.

single-sample feedback, FM instead of PM, cross-modulation between grain chains, busy channel detection**

. Maybe we should look deeper into Faust, since it does not expose its type IR (which I believe it is the foundation of the compiler). And we start from FAUST and work on what is necessary.

[dietcv]

I have written the initial post when I had no clue about c++ and it was kind of a hot take because I got a bit frustrated after all the research and prototyping ive done and the inability to move forward with proper implementations of what I was imagining, so im sorry about that

After spending some time with c++ I have accepted that this might be the way to go and have to figure out most of the stuff on my own.

I like to spend my time on creating new UGens but not so much on figuring out a specific workflow, because i think i dont have too much to say about that. But you are right that all whats in the library is at the intersection of UGen graph and c++ Plugins. Im still trying to make the most modular version of what could be possible with this server side attempt.

[smoge]

@dietcv

I have written the initial post when I had no clue about c++ and it was kind of a hot take because I got a bit frustrated after all the research and prototyping ive done and the inability to move forward with proper implementations of what I was imagining, so im sorry about that

I have to thank you; you consistently show ideas without censoring yourself regarding what SC was initially designed for. I’m in the same boat as you. I only have prototypes in C++. And I went down the rabbit hole of thinking about a typed IR that takes into account the convergence of parametric polymorphism (in this case, C++20 mirroring type classes in Haskell). It seems sensible to say that the “way forward” is not to rewrite anything, but to think of something “alongside.”

I said “good case” as a compliment. Don’t take me wrong, homie.

[dietcv]

Hey, Im pretty sure we can figure out what to do next because we all want to improve SC