Clojurians Log v2
overtone
@pfeodrippe can you show an example of what you would use the compile-time? flag for? trying to explain in the CHANGELOG what this does
Thanks and sorry o/ I will update the CHANGELOG in any future PR (or enforce that it’s changed for every commit, but not sure if it’s too much). The flag is used in defsynth-load so it can work at runtime as the arguments and such may not be known at compile time. So we set it to false in this case.
defsynth-load reads from a file, for example, and generates a synth definition with args and such
There was a quoting issue that was preventing the docs, for example, of being shown correctly for synths generated from defsynth-load
Perfect ❤️ thanks!
also can someone explain what defunk does, exactly? I see some changes related to it, but it's not documented, and not used directly (only defunk-env)
Probably me, I don't know what it's for. I just fixed the go-to-definition for defunk vars as I was trying to answer the same question.
It sounds cool! I bet it's for particularly funky synths.
ok I think I get it, looks like it just creates a regular function, but one which uses a similar syntax as defsynth/definst with key-value defaults
(defunk my-fn "" [x 1 y 2]
(+ x y))
(my-fn)
;; => 3
(my-fn 2)
;; => 4
(my-fn :y 3)
;; => 4it's not part of overtone.api/overtone.live, so you need to explicitly require it.
And the docstring is not optional.
Overtone 0.16.3331 is out! Lots of good stuff, even though it's only been three weeks or so since the last release ❤️
[overtone/overtone "0.16.3331"]
{overtone/overtone {:mvn/version "0.16.3331"}}The big new thing is obviously the sclang stuff by @pfeodrippe, which I hope to get a chance to play with a bit more in the coming weeks. But there are a whole slate of other improvements in there as well.
I want to interact with the data in overtone while it's being processed and from clojure, so I've created a small plugin in C++ (from a SC template) from where I start a JVM using JNI and we can then use the REPL normally (in the video I have 2 JVMs, one for the plugin that's rendering Clerk and another from a usual JVM where this plugin is called from). Dev (in WIP) is happening in https://github.com/pfeodrippe/vybesc (plugin) and https://github.com/pfeodrippe/vybe (develop) branch. It's good to have direct access to the raw data as we can do anything... but real-time processing in Clojure. I guess I will solve this by compiling C code on demand with gcc and loading it from the plugin dynamically (dlopen) so we can have everything as REPLable as possible from the synthdefs all the way down to to the ugen).
So this runs a JVM inside a ugen?? That is wild
Yes ahahahaha the JVM folks enable us to do anything ahahahah. I’m using the new FFI (Panama) API in Java 22, it’s very easy now to deal with native code
Wow never heard of Panama. I have a soft spot for JNI but that's very exciting.
No reason to use JNI anymore if you can avoid it ehuaehuehueh (at least for shared libs from the JVM), Panama is much better structured, https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/doc/panama_ffi.md. In Java 22, it's not in preview anymore
For completeness, https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md is what makes using Panama really conveninent, the generated bindings have the metadata you need to create your own clj-wrappers (or just use the generated classes directly), e.g. https://github.com/pfeodrippe/vybe/blob/main/src/vybe/jolt.clj#L308
Thanks, Diego! \o
Ok, no need for a JVM really, shared memory (using shm_open and mmap) works fine for retrieving raw data from the plugin
That does seem altogether more sensible. UDP or a Unix socket would probably do as well for most use cases
Opened my first PR for supercollider https://github.com/supercollider/supercollider/pull/6528
Nice!!! While the PR is open, you can push a commit adding JNI_CreateJavaVM so we can use it from CLJ in the future lol
Turns out I found a genuine bug, not just a logging issue.