Clojurians Log v2

One of the reasons is that SC has the concept of ugens that you can mix however you like (like building blocks) and there are tons of it https://doc.sccode.org/Guides/Tour_of_UGens.html. There are also lots of plugins for new ugens in the wild. I have never used Java Sound, but it seems like a lower-level API in which you would have to implement these concepts on top of it to have it ready for live performances and even to create some sound you would like.

In other words, you don’t need to be an audio engineer or have DSP knowledge to make sounds with SC. And if you happen to have this kind of knowledge, you can build your own stuff and integrate with SC, so it seems to be a usable tool for everyone, novices, experts and libraries like overtone.

Many of the ugens seem pretty straightforward. It's fairly simple to send sine waves and such to the java sound API. I guess I just don't have a sense of which super collider operators are both useful and hard to implement.

I don't think it's straightforward to make things performant enough with such flexibility (ugens is just a part of it, check the entire SC ecosystem, SC for overtone is a client (overtone) + a server (scsynth)), but I don't have DSP experience though, I just talk from a higher level of abstraction. The code for the plugins (the ugens) are in https://github.com/supercollider/supercollider/tree/develop/server/plugins, they don't appear to be straightforward. But yeah, if someone would have the time to try to re-create these in Java sound, I would absolutely love it as it would make it more REPL-friendly o/ One good test could be recreating one of synthdefs in sonic-pi (its creator, Sam, is also the creator (or one of) of overtone), e.g. https://github.com/sonic-pi-net/sonic-pi/blob/dev/etc/synthdefs/designs/supercollider/organ_tonewheel.scd, it would be a fun project for sure.

https://www.youtube.com/@elifieldsteel/featured is a good SC resource if you would like to check out some stuff (he also has a SC book, published this year)

A lot of this stuff looks like basic array programming that would be a lot less code in a higher level lang. I know audio is typically played at 44100hz which doesn't seem like a hard target to hit. I'm not sure if synthesized sound uses a higher sampling rate.

It's not only about synthesis only, but also control, you can create triggers, control-rate parameters, combine things very easily. I guess this is also why overtone went with SC (the main thing that eases this is that you can communicate using OSC with the server, so it's very language-agnostic)

Right, but clojure is very good at those things (ie. control and asynchrony).

Yes, this is why overtone so well

As you were saying in your other post, there are also benefits to being able run code in-process.

My experience in the past is that super collider also adds a lot of incidental complexity.

Yes yes, I get what you are saying, I just don't think it's straightforward to create the basic infrastructure for it. If you already have a plan and expertise (e.g. your sound effects figured out, controls etc), then yes, a hardcoded algorithm may work and be performant, but it won't be flexible.

Yeah, I agree with the incidental complexity part

But we have to choose our battles haeuehuehu

> I just don't think it's straightforward to create the basic infrastructure for it. What is "it"?

Doing what SC provides (or part of it) using Java sound or some other lower level API like that, it's possible, sure, just not easy nor I know if it's worth it o/

The SC lang itself is "REPLable", so it was one more point in the decision of using SC, I guess, it's really really cool

Kind of the reason I ask is that I've already done some work to use the Java sound API for various projects. The reason I use the sound API is that it makes distribution much easier (it's built in). I'll probably continue to do work in that space. I was curious how much work super collider was doing.

Nice! Let me know if you have some OSS project, would love to see what people are doing with Java Sound, I wasn't considering it until your message

Clojure is already good at async, interactive programming. If super collider was only doing basic array programming. Maybe it would be interesting to experimentally implement some of the tools super collider offers to see how it feels.

Re: distribution, I am able to ship it with my game (WIP), but one of the issues is that SC is GLP, not a problem for overtone directly for sure, just for its clients. So Java Sound is better for commercial products and non-GPL stuff for sure

All of these examples need to be cleaned up, but it wasn't too bad (on Mac OSX, I haven't tried linux): • https://github.com/phronmophobic/clj-media/blob/5dae8ad0665d2951660a36343e38d676b7d0730d/src/com/phronemophobic/clj_media/impl/audio.clj#L188 • recording audio: https://github.com/phronmophobic/whisper.clj/blob/ce739a7113c823ec36086555369dac9a88c8cf90/src/com/phronemophobic/whisper.clj#L107 • https://github.com/phronmophobic/clj-libretro/blob/3b6daebd0995e6b4a6f622b72869811524435e7c/src/com/phronemophobic/clj_libretro/ui.clj#L130 As the examples show, I've also been working ffmpeg.

Awesome, thanks!

Essentially, after you set things up, it's just about sending samples. The annoying part is typically synchronizing playback so that you're not too far ahead of the the output.

Got it

That's not really that important for playing an mp3 file, but would be required for something like overtone or a game that wants to be able to produce the sound as close as possible to when it gets played.

Maybe not the prettiest example, but here's how to play a 440hz sine wave. Obviously, could be refactored to be more loosely coupled, but I thought it might be helpful to have one example that does the simplest task:

(import '(javax.sound.sampled 
          AudioFormat
          AudioSystem
          AudioFormat$Encoding
          DataLine$Info
          SourceDataLine)
        '(java.nio ByteBuffer
                   ByteOrder))

(let [sample-rate 44100
      sample-size-in-bits 16
      channels 1
      frame-size (* channels (/ sample-size-in-bits 8))

      frame-rate 44100
      big-endian? false
      audio-format (AudioFormat. AudioFormat$Encoding/PCM_SIGNED
                                 sample-rate
                                 sample-size-in-bits
                                 channels
                                 frame-size
                                 frame-rate
                                 big-endian?)



      buf-size (* frame-size frame-rate)
      buf (byte-array buf-size)
      bb (doto (ByteBuffer/wrap buf)
           (.order (ByteOrder/nativeOrder)))
      ;; note freq - A
      tone-hz 440
      ;; Max is Short/MAX_VALUE (ie. 32767)
      amplitude 500

      info (DataLine$Info. SourceDataLine
                           audio-format)
      source-data-line (^SourceDataLine AudioSystem/getLine info)
      source-data-line (doto ^SourceDataLine source-data-line
                         (.open audio-format)
                         (.start))]
  (try
    (loop [frame 0]
      (when (< frame
               ;; play for 5 seconds
               (* frame-rate 5))
        
        (.rewind bb)
        (doseq [i (range frame-rate)]
          (let [x (/ (+ i frame)
                     frame-rate)
                s (short (* amplitude (Math/sin (* (* tone-hz (* 2 Math/PI))
                                                   x))))]
            (.putShort bb s)))
        (.write source-data-line buf 0 (alength buf))
        (recur (+ frame frame-rate))))
    (finally
      (.drain source-data-line)
      (.close source-data-line))))

Nice, thanks o/

Sure, you could reimplement supercollider in Java. There's stuff like jmax that goes in that direction. Supercollider is just a very mature and complete synthesis engine that we can build on. Not everything is as trivial as generating a sine wave. Even the sine wave ugen is more complex in sc because it uses wavetable synthesis for petformance. Look at stuff like freeverb/gverb or moog-ff. You're looking at man-years of work to port all of that over. It would be great to see someone do a Clojure based synthesis engine, but I don't see it as a goal for overtone.

Right. I wasn't trying to suggest any changes to overtone. I was just trying to understand the role of Supercollider. Thanks for the info!

Nice!! Is it https://github.com/supercollider/supercollider/pull/5571? I’ve thought it was still ongoing, but it seems they will integrate it into the next version already, it will be pretty awesome. I’m just sad that I won’t be able to create a JVM from a plugin there ahahahaha lol

I also had bb in the back of my mind when learning overtone https://github.com/babashka/babashka/issues/1748

The STM stuff was still very much in vogue when Overtone was written, and there are quite a few refs in the code base (and even a few agents)... there are also a number of defrecord/deftypes, and if those implement Java interfaces then they will likely never work with babashka.

Good point. I think bb is ok with agents and refs right? maybe there's a few tricks we can pull for the deftype's with reader conditionals and partial support for some things. the big roadblock I saw was the dependency on jmdns.

which is relevant to a cljc version of overtone I guess. maybe there's a design that works for all.

I though jmdns was essential for osc communication but it seems to just be for Bonjour. so I take that back.

maybe we can even remove that once I fix https://github.com/supercollider/supercollider/pull/6528

yeah I don't think that's really a core dependency, might be a worthwhile goal to try to better separate the core supercollider stuff from everything around it, so we have a smaller initial target for porting to cljs or bb