Our great sponsors
-
It has been about 2 years since I started developing Glicol. You can try it here:
Recently I added support for VST, Bela and responsive design for mobile devices. It would be great if you can try and give me some feedback here or in the GitHub repo:
https://github.com/chaosprint/glicol
Thanks!
-
Thanks for sharing! Look forward to your Ugen as well. It's great to see that many languages have supported sample-level control, including the Pd and Max you mentioned. There was a discussion on Faust repo before that might be interesting for you too: https://github.com/grame-cncm/faust/issues/685
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
vst-rs
Discontinued VST 2.4 API implementation in rust. Create plugins or hosts. Previously rust-vst on the RustDSP group.
If you want your own vst (with your name on the author and you can sell),you can start with vst-rs:
https://github.com/RustAudio/vst-rs
Wanna some GUI, here is a template:
-
https://github.com/DGriffin91/egui_baseview_test_vst2
In writing the vst, you may need some rust audio lib, you can search dasp, fundsp, or wait for glicol_synth published as a Rust crate (like pip or npm)
-
> In Glicol, you can use different node directly as UGens and you can also define your own `meta` node in real-time,
That's cool!
FWIW, Mads has been working on a Faust UGen that can compile Faust code on the fly: https://github.com/madskjeldgaard/faustgen-supercollider
Also, there is an open-source implementation of Reaper's JSFX language: https://github.com/asb2m10/jsusfx. The Repo already contains Max and Pd objects. I have been thinking of contributing a SuperCollider UGen, but there are so many other things on my list :-)
-
> In Glicol, you can use different node directly as UGens and you can also define your own `meta` node in real-time,
That's cool!
FWIW, Mads has been working on a Faust UGen that can compile Faust code on the fly: https://github.com/madskjeldgaard/faustgen-supercollider
Also, there is an open-source implementation of Reaper's JSFX language: https://github.com/asb2m10/jsusfx. The Repo already contains Max and Pd objects. I have been thinking of contributing a SuperCollider UGen, but there are so many other things on my list :-)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
I guess it depends on what you want to do. For typical Algorave-style music, I would agree that sclang doesn't offer the right high-level abstractions. However, it's possible to implement live coding dialects on top of sclang, e.g.: https://github.com/jamshark70/ddwChucklib-livecode
-
-
pure-data
Pure Data - tracking Miller's SourceForge git repository (also used by libpd) (by Spacechild1)
FWIW, Pd and Max/MSP always had sample-level control in the sense that subpatches can be reblocked. For example, if you put a [block~ 1] object in a Pd subpatch, the process function will be called for every sample, so you can have single-sample feedback paths. Pd also has the [fexpr~] object which allows users to write FIR and IIR filters in a simple expression-syntax. Finally, Max/MSP offers the very powerful [gen~] object. You can check it out for inspiration (if you haven't already).
Pd (and Max/MSP) also allow to upsample/resample subpatches, which is important for minimizing aliasing (caused by certain kinds of processing, such as distortion).
Pd also uses the reblocking mechanism to implement FFT processing. The output of [rfft~] is just an ordinary signal that can be manipulated by the usual signal objects. You can also write the output to a table, manipulate it in the control domain with [bang~], and then read it back in the next DSP tick. IMO, this is a very powerful and elegant approach. SuperCollider, on the other hand, only supports a single global blocksize and samplerate which prevents temporary upsampling + anti-aliasing, severly limits single-sample feedback and leads to a rather awkward FFT implementation (you need dedicated PV_* objects for the most basic operations, such as addition and multiplication).
Another thing to think about is multi-threaded DSP. With Supernova, Tim Blechmann miraculously managed to retrofit multi-threading onto scsynth. Max/MSP offers some support for multi-threading (IIRC, top level patches and poly~ instances run in parallel). Recently, I have been working on adding multi-threading to Pd (it's working, but still very much experimental): https://github.com/Spacechild1/pure-data/tree/multi-threadin.... If you design an audio engine in 2022, multi-threading should be considered from the start; you don't have to implement it yet, but at least leave the door open to do it at a later stage.
---
I'm not sure how far you want to go with Glicol. I guess for the typical Algorave live coder all these things are probably not important. But if you want Glicol to be a flexible modern audio engine/library, you will have to think about FFT, upsampling, single-sample feedback, multi-processing etc. at some point. My advice is to not leave these things as an afterthought; you should at least think about it from the start while designing your engine - if you want to avoid some of the mistakes that other existing audio engines made. This is just a word of "warning" from someone having spent countless of hours in Pd and SuperCollider source code :-)
