Why do you think that? Pd only has the most basic synthesis primitives and is still doing fine. As I said, everything else can be built on top of that or written as extensions. If you want better oscillators or effects, just go ahead and build them and share them with the community! (Have I mentioned that we need a package manager for Server plugins?)
1 Like
Iâd say that reblocking and SR scaling is a major change. That has never existed in scsynth before, and introducing it would bring within reach many many operations that are currently out of reach in scsynth.
If we wanted gen~ in scsynth, youâd need either to load object code at runtime (which IIUC we canât doâŚ? maybe a UGen could in the NRT thread but itâs a potential security risk I guess, running arbitrary object code) or⌠had a bit wild thought reading this thread⌠what if thereâs a virtual-machine UGen that implements a gen~ like set of operators (all the math stuff, history, delays, buffer peek/poke) and you load a graph of these operators into a Buffer, and the VM UGen processes these sample-by-sample? Youâd lose the speed benefits of LLVM inlining but youâd get âsoftâ UGen internals. Actually the function call overhead is probably too heavy, just speculating out loud.
In any case, a Gen.ar UGen in SC would be a massive engineering effort (see James McCartneyâs keynote), whereas thereâs an existing POC on the table to get single-sample blocks and up/down-sampling. The latter is looking more attractive for practical reasons.
hjh
1 Like
One question in my initial Post was, if people are happy with the Selection of ugens available in SC. Maybe we could make a Poll. If Most of the people are happy with what is available, then there is no need to develop additional things. From the positive Feedback I get for some of my Synthesis Posts in some threads or via dm I would assume that people would be generally interested in new ugens.
The reason for my personal opinion is:
- There are barely any new ugens and the few exceptions are Ports from a Limited amount of available libraries and often Times there are bugs which remain unsolved (scaling of Filters inside PortedPlugins) or general misalignments with SC (miUgens).
- This is Not about one Person developing something. There is no group of people Sharing notes, discussing and developing new ugens. On the other Side you have a large m4l community where you have people coming up with well thought out new Plugins, where alot are based on current papers and research, on a Daily Basis with capabilities unavailable in SC.
I would be more then happy if I could Export my gen things via RNBO to sc, if this would be possible then I could assume more people would use that. But I think everything about that RNBO Export has already been said in another thread.
I cant see the Future of sc beeing based on ugens developed in c++. Thats a Model which at least hasnt worked very well in the last 25 years imo.
Again, you really need to watch James McCartneyâs keynote address from the symposium (once the videos are up). Itâs very much relevant to the concerns here (though itâs a whole new thing, not a SC add-on). The gist (massively oversimplifying) is that everything is gen, at the SynthDef level: UGens emit lower-level code and the whole ball of a SynthDef gets compiled to one thing. No plugins.
Early development but just pointing out that youâre not the only person thinking about it.
hjh
1 Like
I may be the exception here but when I first played with a big Buchla in school it was heaven - I was just using sine/saw/pulsewidth oscilation - it seemed like anything was achievable. In SC things like Gendy are happy additions - and anti-aliasing plus some more filters would be great. But I donât see this as a huge problem - we can make things move and exactly which things are moving seems less important to me!
âŚand we have VSTPlugin if you need to use a mastering plugin or such
on the other hand @Spacechild1 made some excellent points at the forum about the workflow for FFT being awkward and I do think that if there were some clever way to let us act on the FFT stream more generally as can be done in Pd that would be fantastic. I find myself simply not bothering sometimes rather than searching for the right combo of UgensâŚ
Embedding jsfx is a brilliant idea and might help spread the word about SC to the much larger REAPER community as well - so there are nice synergies there - really quite an interesting solution!
3 Likes
I donât really get this comment - all DSP is written in C/C++ and IMO it has worked very well for the last 25 years - it is simply a domain where performance is crucial.
To quote the wonderful Kai Lentit: What software is written in C? What software isnât written in C?!
IMO I donât see a real lack in interesting ways to generate sound within SC - the concerts at the symposium showed that there are a variety of interesting ways to generate sound: sounds that are fresh, unique, nuanced and expressive. I found the Ableton stuff interesting, but as soon as new stuff gets released I get tired of listening the same effects and presets on every record all the time (like Decapitator is awesome but soooo overused) - and while max msp has some interesting takes, is out of the question for me b/c I donât want to tie my creative work on proprietary software (anymore) and instead want to contribute to an alternative where people come together to create something nice with friends and like-minded people within a community.
If you want to get some inspiration you can take a look at the wonderful https://github.com/dkmayer/miSCellaneous_lib which managed to overcome Single Sample Feedback restrictions by applying some clever tricks by stacking Synths through Pseudo-UGens and much more.
And SuperCollider does not consist only of scsynth/supernova, there is also sclang which allows you to control the DSP graph in ways which are plainly not possible in pd/max/faust/âŚ
With the addition of oversampling and native single sample feedback I canât think of much which would be possible in gen~ but not possible in scsynth (well, hardsync OSCs, we really need those^^). But this feature alone allows for so much new ways of generating sound which I am really looking forward to.
I really doubt that the lack of synthesis possibilities within SC is the greatest danger to this project.
The future of SC is probably not as bright as it could be, but IMO this is mostly caused by a lack of governance/organization, maintainer burnout and lacking awareness on social issues.
E.g. reading comments like these are somehow a bummer as a dev: the dev team is spending a lot of effort and personal free-time trying to make this a nice piece of software for everyone and while things for sure arenât perfect Iâd appreciate a more pro-active, supportive and positive community than a negative and demanding one.
In the end: If you think there should be something done about it: Start doing something about it.
This is a community project and you can be part of the project - I think anybody appreciates contributions to this project, be it as part of the SuperCollider distribution, by creating custom UGens (e.g. those awesome oversampling Oscillators, thx or those!), new language interfaces for scsynth or by sharing inspiring snippets on the forum.
I really love the ideas expressed by Christof - you could try to implement those.
I was told you are living in the same city as I do - when I am back we can meet if you are interested in learning how to contribute to SC - DM me for this.
In the meantime: I wrote an Example UGen, I think writing UGens isnât tooo hard if you have some programming experience: GitHub - capital-G/ExampleUGen: A very basic UGen for SuperCollider which acts as a getting-started guide
Just had a talk with James McCartney about this: according to him these are not necessary anymore, so we could actually start removing them - this could probably be automated as they are simply macros?
We should probably verify this with godbolt just to be sure though.
3 Likes
I would like to answer some of your questions or comment on your statements. But i think this thread has gone sideways pretty fast and i will probably dont find the right words, so i leave them unanswered.
The idea of the initial thread was to find out what people think of the current state of ugens, i think thats pretty clear now.
I just want to comment on one thing which really hurts me deeply:
I have created several threads here on the forum over the last years, where im sharing SynthDefs, complete libraries with well thought through functions and discussing in very detail alot of nitty gritty dsp things which have never been discussed before in this community and come back to these threads from time to time to update the initial posts, when i discover something new or more refined. I dont understand in what way this doesnt count for contribution. Sure we can meet, but im having a hard time to read this offer in the way it was phrased differently then as a demonstration of power.
1 Like
thanks, i will watch it as soon it is available 
AFAICS the recent move is toward using higher level objects to compile to LLVM. Thatâs what gen in Max is doing. Pd has the heavy compiler; it has limitations (many objects arenât supported) but I did give it a spin once, and made a ring modulator VST in a few minutes. (Actually Iâm not completely sure hvcc is doing full inline code emission.)
Actually, JMc was working on a code-emission SC prior to scsynth (maybe there are still some references online to sc3d5) but he was 20(?) or more(?) years too early â he abandoned that version because compilers werenât fast enough in the 00s. (And that keynote was about returning to this idea, after computing infrastructure has caught up with his imagination 
)
I think dietcv isnât saying that UGens shouldnât be written in C, but rather that the idea of calling precompiled functions and only this corpus of functions is no longer cutting edge. I think thatâs objectively true. However as semiquaver hinted, analog modular isnât cutting edge either, but there are thriving meetups all over the world (even Guangzhou has a DAWless hardware jam group).
Itâs a big engineering effort thoughâŚ
hjh
PS Also⌠Iâm fundamentally a composer/improviser and realized awhile ago that Iâm not a cutting edge synthesist. Of Max, Pd and SC server, the best at polyphonic note playing is SC, easily, no contest (poly~? 
), and this suits my goals hand-in-glove. This isnât to say that a new architecture shouldnât be developed, rather that the choice of SC is, for some or many of us, not a compromise. If a newer tool has an analogue to âcompile a SynthDef to a dynamically loaded thingâ and you can instantiate that thing polyphonically, then it meets in the middle.
Sorry, I personally really enjoy your posts and am a big fan of them. I am sorry if this came off as wrong - I tried to implicitly mention your contributions in my post:
I thought more that if you want to improve the UGen situation we could maybe team up and see ways on how to get a more JIT-compiled approach into scsynth (if possible).
I know, but LLVM and a wrapper for such is/would be also written in C++
1 Like
Erm⌠I did say: âI think dietcv isnât saying that UGens shouldnât be written in C, but rather that the idea of calling precompiled functions and only this corpus of functions is no longer cutting edgeâŚâ â thatâs the important bit.
hjh
1 Like
Why not trying to finish FaustGen: [WIP] FaustGen - a UGen for interpreting Faust code ?
Faust + LLVM JIT, lot of already written DSP :
- https://faustlibraries.grame.fr
- Faust examples by category - Faust Documentation
- Powered By Faust - Faust Programming Language
I can possibly help 
! (I have a fork here: GitHub - sletz/faustgen-supercollider: Livecode Faust in SuperCollider using an embedded Faust compiler.)
8 Likes
My desire for a future SC is a smaller, not larger distribution. This sentiment particularly applies to the UGen library. (Iâd prefer the core UGens to just be classic Music-N.)
This future SC should then also be extendable and easily reconfigurable giving users the convenience of deploying SC for specific and focused tasks.
A more vernacular way of saying this⌠donât make SC messier. Make it cleaner, and give the opportunity for individual users to make their own messes. (Some users may prefer dairy free, for instance. 
)
3 Likes
Some thoughts:
First of all, I agree with dietcv here. I think the solution might be a new SC plugins repository rather than having all these plugins spread everywhere. SC Plugins was locked over a decade ago, so there needs to be a new one.
I think dietâs remarks were confused. They are trying to rally development, not criticize. I say yes to this!
For Compressors, we can always use VSTs. Compressors, reverbs, EQs seem like VST land for me
What about Roar canât be achieved with ShaperOS2? I think it is just a variable waveshaper
JSFX is available as a VST, so it can be loaded with VST Plugin! But it would be great to have it as a UGen as well. There are a ton of people using and developing JSFX.
As Lucille pointed out at the symposium, writing C++ plugins is a pain in the ass. I think this has more to do with the structure of SC UGen code rather than C++. If you look at LibDaisy or other DSP libraries, they are so much easier to implement. AND you can plug them together in C++. Making a new structure for an SC plugin would be very helpful. Most c++ libraries just have .process and you get the next sample.
Sam
4 Likes
I totally agree, except for this one:
I think large monorepos are simply not maintainable on the long term. You have mentioned yourself that sc3-plugins have been essentially locked down. Why wouldnât the same thing happen again with a new repo?
With a good package manager (with search, category tags and âmeta packagesâ) I donât really see any advantages of monorepos over distributed development. For example, if I want to make a bug fix release for VSTPlugin, I can do that anytime and immediately provide new packages. In a monorepo you need to coordinate with possibly dozens of other plugin authors. Iâm not even sure how semantic versioning would work in such an environmentâŚ
I really wanted to address package management in my keynote (comparing Quarks with Pdâs Deken and suggesting further improvements) but I ran out of time⌠
2 Likes
i think an updated and not maintained version would still be better as an old not maintained version.
dont worry, lets meet. Im happy to figure out where i can support.
That pretty much lines up with how i use these tools. Im using Live 12 for everything which is post processing, everything else is SC.
i was wondering about dynamic waveshaping latetely (in parts that was something i have tried to address with my collection of unit shapers, which we agreed on that i will release it as a quark). Im currently following everything which is posted on anti-derivative anti-aliasing https://apulsoft.ch/blog/tanh-antiderivatives/ and looking forward to the next go book with some cheap, linear phase, state of the art anti-aliasing and oversampling attempts.
The general problem is that you want to have:
- basic building blocks which are state of the art
- and the oportunity to put these single units together with single-sample feedback to create a device
i think an updated and not maintained version would still be better as an old not maintained version.
And I think distributed development + a plugin package manager would be a much better solution. That is essentially what happend in Pd. When Pd-extended became unmaintained about 10 years ago, IOhannes created the Deken package manager. One of the first things he did was uploading all externals in Pd-extended as individual packages. Then individual developers took over maintainance of certain packages to make bugfix and feature releases. Of course, people also started to create entirely new externals and libraries. At this point, Deken lists 257 libraries, some of which contain dozens or even hundreds of objects in turn! See Deken - Pure Data externals Database This kind of ecosystem wouldnât have been possible without a (binary) package manager. (To be fair, Deken is missing category tags and âmeta packagesâ, and search could be better, so discoverability isnât as great as it could be.)
Ideally, the community would make lists of high-quality extensions and release them as âmeta packagesâ. There could even be an option in the SC installer to automatically download some of these. This way you would get SC with âbatteries includedâ, but without the associated maintainance burden.
If people eventually decide to go for a new monorepo, thatâs fine with me. I just wanted to point out some alternatives and put up some warning signs.
1 Like
+1 for this! Not making it harder to have the features you want, rather making it easier/possible to have a bare minimum vanilla install
(Maybe off topic but I wonder how crazy it would be to allow GUI plugins somehow⌠years ago I hacked together a code view widget in Qt with syntax highlighting, but it requires a full fork of the entire SuperCollider project so I barely use it now, and probably nobody else does either. If GUI plugins were a thing, the vanilla SC install could even be GUI-less!)
Also since this thread is asking for user sentiment, +1 for reblocking/resampling, better FFT workflow, some gen~ alternative (I agree from a user perspective, running into some limitation and having to write a c++ plugin to solve it has always been a downer), and (pipe dream) 64 bit float samples on the server