Porting quarks from SuperCollider

[cianoc]

I'm going to start porting some quark functionality from SuperCollider that I find useful, and create libraries for them. These won't be exact ports, but will provide lispy and strongly opinionated versions of them.

Current candidates are the following:

• a rough port of James Harkin's ddwmixer, to provide an easy way to setup tracks/routing akin to a DAW (bus tracks, sends, effects channels, etc). In the background it manages groups, node ordering and channels for you. Incredibly useful.
• Feedback. This provides an easy way to setup feedback chains within a synthgen (it uses a buffer in the background)
• Fb1 from the Miscellaneous quark. This is a hack for single sample feedback. More useful for experimentation/prototyping purposes, as it's quite resource heavy.

Happy to consider any other quarks that people think are useful.

[defaultxr]

Just to avoid possible duplication of work, I wanted to mention I've been working on functionality that will dump UGens from the current SuperCollider installation, by way of an sclang script that outputs defugen forms. Since it will dump all UGens that sclang is aware of, it will include all UGens, even third party ones--as long as they're subclasses of UGen, but I don't think it will be able to port "pseudo-ugens", i.e. UGens that are defined only as sclang code rather than binary UGens (so it would not work for the Feedback quark, for example, however, I did create an implementation of that myself which I will paste below). It's nearing completion by this point, I just need to clean it up and then submit the PR. I may submit it as a draft PR if you'd like to take a look at it.

Here's what I have currently for an implementation of FbNode from Feedback:

;;; fbnode

(defclass fbnode () ; (sc::ugen)
  ((num-channels :initarg :num-channels :initform 1)
   (frames :initarg :frames :initform 1024)
   (phase :initarg :phase :initform nil)
   (max-delay-time :initarg :max-delay-time :initform nil)
   (local-buf :initarg :local-buf :initform nil)
   (interpolation :initarg :interpolation :initform 2)))

(defmethod cl-collider::floatfy ((fbn fbnode))
  (buf-rd.ar (slot-value fbn 'num-channels)
             (slot-value fbn 'local-buf)
             (sc::-~ (slot-value fbn 'phase) (sc::server-options-block-size (sc::server-options *s*)))
             1
             (slot-value fbn 'interpolation)))

(defun fbn (&optional (num-channels 1) max-delay-time (interpolation 2))
  (let* ((sample-rate 44100)
         (block-size (sc::server-options-block-size (sc::server-options *s*)))
         (max-delay-time (or max-delay-time (/ block-size sample-rate)))
         (frames (+ (* max-delay-time sample-rate) block-size))
         (fbn (make-instance 'fbnode
                             :num-channels num-channels
                             :frames frames
                             :phase (phasor.ar 0 1 0 frames)
                             :max-delay-time max-delay-time
                             :local-buf (local-buf frames num-channels)
                             :interpolation interpolation
                             )))
    (clear-buf (slot-value fbn 'local-buf))
    fbn))

(export 'fbn)

(defun fbn-read (fbn &optional (delay (slot-value fbn 'max-delay-time)))
  "Read from FBN at a time DELAY seconds from its input. DELAY defaults to the fbn's max delay time."
  (let* (;; (delay (or delay ))
         (block-size (sc::server-options-block-size (sc::server-options *s*)))
         (sample-rate 44100)
         (offset (sc::min~ (sc::max~ (sc::*~ delay sample-rate) block-size)
                           (sc::-~ (slot-value fbn 'frames) block-size))))
    (buf-rd.ar (slot-value fbn 'num-channels)
               (slot-value fbn 'local-buf)
               (sc::-~ (slot-value fbn 'phase) offset)
               1
               (slot-value fbn 'interpolation))))

(export 'fbn-read)

(defun fbn-write (fbn input)
  "Write INPUT to FBN."
  (buf-wr.ar input
             (slot-value fbn 'local-buf)
             (slot-value fbn 'phase))
  input)

(export 'fbn-write)

I didn't submit it yet because it still needs to be cleaned up and fixed/improved in a few ways.

Example usage:

(proxy :feedback
       (let* ((freq (mouse-y.kr 20 20000 :exp))
              (feed (mouse-x.kr 0 100 :lin))
              (fbn (fbn 1 0.1))
              (sig (sin-osc.ar freq (* feed (fbn-read fbn 0.1))))
              (_ (fbn-write fbn sig)))
         (pan2.ar sig)))

Personally, I am of the opinion that it would be nicer to have UGens like Feedback/FbNode/Fb1 together as part of cl-collider itself rather than as separate libraries. But for the more "opinionated" ones like ddwMixer that present a way of working that is different from standard SC, a separate library might make more sense. But again, that is just my opinion.

[cianoc]

Oh cool. Anything that reduces busywork sounds good. You'll still have to check the defugen forms as some ugens do slightly more complex stuff to wrap them on the supercollider side, but that will certainly do most of the work.

Which ugens should be ported is another question. There are quite a few of questionable quality in sc-extensions, or which have been superseded.

Feedback as part of the main library would make sense to me. I think providing it with an anaphoric macro could possibly result in something a little nicer to work with - at least for the general case. What I had in mind was an interface that looked something like this:

(defsynth bloody-stupid-filter (in)
  (feedback (:max-size 1024)
    (+ (* 0.5 in) (* (fb-out :delay 72) 0.5)))

Obviously a little be more thought would be required to think through more complex types of feedback - and it might not be worth defining a macro for those - but this would at least simplify common usage.

[ntrocado]

functionality that will dump UGens from the current SuperCollider installation, by way of an sclang script that outputs defugen forms

This would be fantastic!

Personally, I am of the opinion that it would be nicer to have UGens like Feedback/FbNode/Fb1 together as part of cl-collider itself rather than as separate libraries. But for the more "opinionated" ones like ddwMixer that present a way of working that is different from standard SC, a separate library might make more sense. But again, that is just my opinion.

FWIW, I agree.

[defaultxr]

You'll still have to check the defugen forms as some ugens do slightly more complex stuff to wrap them on the supercollider side, but that will certainly do most of the work.

Absolutely. I have an "ignore list" in the script which prevents it from generating defugen forms for specific UGens such as DynKlank but it probably should be something configurable by the user rather than hardcoded, as it's possible that 3rd party UGens exist that would have a similar issue.

Which ugens should be ported is another question. There are quite a few of questionable quality in sc-extensions, or which have been superseded.

Any that have been superseded could maybe be ignored rather than ported, as there likely isn't any code in the wild that would be using them, and thus backwards compatibility would not be an issue (if someone has implemented them themselves in their own code outside of cl-collider then nothing stops them from continuing to use their own version, of course). I guess the only concern is if someone wants to port code to cl-collider from sclang or another environment where they are implemented. But maybe it's best to cross that bridge only if/when we come to it (IMO).

Feedback as part of the main library would make sense to me. I think providing it with an anaphoric macro could possibly result in something a little nicer to work with - at least for the general case. What I had in mind was an interface that looked something like this:

That's a good idea! Shortcuts to speed up situations like live-coding is something I am very much in favor of.

Another thing I wanted to do for the "dump ugens" sclang script is to just dump them as s-expressions rather than defugens directly; that way, the list of UGens to ignore (and other similar parameters) can be configured on the Lisp side, without having to pass additional data to the sclang script. So I will likely make that change as well before it's ready for inclusion in cl-collider.

Also, thinking about it now, it might be good to manually implement ugens in cl-collider anyway, in case someone doesn't have sclang installed and/or working on their system. So the dump-ugens script could just be used to "fill in the gaps" or update any already-defined ugens with new information (i.e. docstrings or similar).

[kflak]

I am going to start working on porting the most basic functionality of the CuePlayer quark (https://github.com/dathinaios/CuePlayer/tree/master) over to cl. I use this all the time for structuring our performances, so it is kind of essential for me if I am ever going to make the switch over to lisp from sclang... I will definitely need a bit of help for this one, but I will shout out as the issues arise. I'd start out with a non-gui version, just evaluating code from emacs or the repl, but as it develops I would't mind a bit of gui bling as well.

[kflak]

OK, first question: What is the cl-collider equivalent of SystemClock.sched? I'm trying this kind of stuff:

(sc:at (+ 2 (sc:now) (print "hello")))
(sc:callback (+ 2 (sc:now) (lambda () (print "hi"))))

but I'm getting a complaint that the function should return a number. So, the question is, how to schedule arbitrary code to be executed at n seconds into the future (in absolute time, that is, not musical time)?

[kflak]

I've done some preliminary work on the qp library now, my take on the CuePlayer quark. The basic functionality is in place: adding cues to a cuelist, triggering the next cue in the list, or triggering arbitrary cues. Each cue consists of a function that is evaluated once on launch, a timeline that takes a plist of time values and functions to execute, and an information field that is printed to stout. I still didn't get around to testing it with sounds, but will do as soon as I get a bit more time. I would also like to create a simple gui, but that's not a big priority right now. I'm relying on sbcl and the timer library for now, but would love to find a more portable solution...

Here's the code: https://codeberg.org/kflak/qp

Any feedback is much appreciated!