4 ms·

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 m

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 https://github.com/grame-cncm/faust/issues/685

spacechild1 5y ago
> It's great to see that many languages have supported sample-level control, including the Pd and Max you mentioned 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-threading 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. Finally, every audio engine needs a plugin interface :-) That's where the problems really start, because for all of the things mentioned above, you have to offer proper abstractions to plugin clients. --- 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 :-) If you come to the conclusion "I won't ever need any of this" - that's fine, of course! --- That being said, Glicol looks very promising. Keep up the good work!
- chaosprint 5y ago
  That's really insightful feedback. I will keep those in mind. Thank you!
spacechild1 5y ago
> There was a discussion on Faust repo before that might be interesting for you too: https://github.com/grame-cncm/faust/issues/685 https://github.com/grame-cncm/faust/issues/685 That thread actually ends with a link to Mads' Faust UGen :-)

spacechild1 5y ago

> It's great to see that many languages have supported sample-level control, including the Pd and Max you mentioned 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-threading 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. Finally, every audio engine needs a plugin interface :-) That's where the problems really start, because for all of the things mentioned above, you have to offer proper abstractions to plugin clients. --- 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 :-) If you come to the conclusion "I won't ever need any of this" - that's fine, of course! --- That being said, Glicol looks very promising. Keep up the good work!

chaosprint 5y ago
That's really insightful feedback. I will keep those in mind. Thank you!

spacechild1 5y ago

> There was a discussion on Faust repo before that might be interesting for you too: https://github.com/grame-cncm/faust/issues/685 https://github.com/grame-cncm/faust/issues/685 That thread actually ends with a link to Mads' Faust UGen :-)