• Official channel: #C053Q1QSG • Mailing list: https://groups.google.com/g/overtone

CHANGELOG • Fix overtone.music.pitch/dec-last (#437) • Return notes in ascending order in overtone.music.pitch/chord • Fix printing of huge map when calling instruments with Cider (#432) • Fix size checks to multichannel buffer writes (#338) • Add clj-kondo support (#493) • Fix broken version comparison in args/SC-ARG-INFO (#449) • OSC: use #getHostScript to fallback on hostname string (#450) • Upgrade dependencies (#456) • Add support for the grain-buf ugen (#470) • use canonical URL for freesound API (#479) • Fix window paths to allow downloading samples (#487) • Removed obsolete JVM option CMSConcurrentMTEnabled (#488) • Read synthdef files correctly (#489) • Fix buffer reading (#490) • Add clj-kondo support (see overtone.linter) (#493) • Qualify the overtone ns in lein example (#495) Contributors: Andréas Kündig, dvc, Hlöðver Sigurðsson, Lee Araneta, Markku Rontu, Matt Kelly, Nada Amin, Paulo Rafael Feodrippe, Perry Fraser, Phillip Mates, Wesley Merkel

Go forth and create beautiful things!

Wow! Thank you so much, Arne!!! This is so great

Will it work with clojure 1.11?

Yes.

Wow, that's awesome

Bravo 👏:skin-tone-2:

Hey, this is not a project or library update 😛

Lots of project and library updates, tho! 😃

Oops, put it in the wrong place, sorry!

I guess overtone will be in the next one 🙂

Yep

This looks great.

that is very kind, thank you

I love the group ID -- so appropriate 🙂

using clojure.asm is pretty wild. What made you decide to go that route instead of "normal" clojure? did you see performance benefits?

the generated bytecode causes exceptions that are thrown by go to jump right to where the label is, which you can't do with clojure

that's very clever

Is this for those who long for the days of BASIC?

I might be in the target audience

there are ways you could emulate it in clojure, using a try/catch around a loop over a case, similar to what core.async's go macro does, but I wanted to use the capabilities the jvm exposes as directly as possible, without emulating features of the jvm that aren't exposed in clojure using features of clojure

lmao. nice

jvm bytecode is very strange. i gotta read up on it to get why/how it all works

I think the bytecode pattern it uses isn't even representable in java either

Have you tried java-decompiling the generated bytecode? I'm curious what it makes of it... 🙂

I have not, just javap

I highly recommend adding a new throwable type for this so that you can elide stacktrace creation

This looks really cool though!

It generates a new throwable subtype for every label, I don't have it eliding stacktrace construction, but it creates all the instances once up front and just rethrows the same instances as needed

Oh that's good to know, I hadn't quite realized that it would rethrow the same throwable each time

Wait, didn't you flame Joshua for using Errors for flow control in his library? I am confused now.

As I recall I was defending my practice of catching Throwable

Yes, you were, I remember now. And that would not be an issue here because these gotos are local to a single stackframe, right?

Oh, no it totally could be an issue, it throws throwables, and exposes those throwables for throwing in the dynamic extent of tagbody

Anything using throwables for jumps has potential issues when composed with other code

reading through this, the limitation for 255 forms comes from using a function for each form right? If that was changed to group all the forms into a single function between labels would the limitation jump to 255 labels?

the limitation is because each form is wrapped in a function, and then each function is passed as an argument to a static method, and that static method runs each function in turn with the exception handlers and what not set up

the jvm has a limit of 255 method parameters

and it becomes 254 because I tack on an extra nil form at the end for reasons

right. that’s what i was wondering if all of the bodies between labels were accumulated into a single function then the limit would be the number of labels (ie form groups instead of forms)

not why that would be the limit?

I haven't looked into a ton, but I did skim the jvm spec on exception handlers the other day and did not immediately see any limitation to how many exception handlers you can have

ah, I see

you are saying basically automatically grouping with do

yeah. just make the ones between labels into one function instead of N functions

I could, or just tell anyone who runs into the 254 limit to use do

haha yeah. i was checking my understanding. love reading this code and was just wondering

something I have wondered about a little is if I could mess with internal compiler state enough to have it generate the bytecode for each body inside the runner class, and there by avoid having to wrap things as fns and pass them in

but that seems very intense (might involve writing a subclass of ObjExpr or something)

would make a great keynote