Collab

[dy]

Hi!
Pretty cool project.
I was working on a very similar tool (called sonr - very preliminary sketch is here), even created syntax parser for that.
I like how you solved pipelining as a | b($ + x) | c
Was struggling a bit with figuring out operators overloading vs t param, found out that t param allows flexibility in defining sound

// with t:
sine(t*1.2, f) // increase rate
sine(t-2, f) // delay by 2 sec / phase adjust
sine(t%frame, f) // repeat frame

// without t:
sine(f) >>> 1.2
sine(f, phase) >> 2
sine(f) % frame

Just wanted to know if you'd be open to sharing some insights / collab?
Curious if we would be able to come to the same syntax.

[dy]

One proposal / question - why instead of stream >> you use $> operator?

[stagas]

Hi!

Both of the projects you linked look awesome, yeah, i think we're trying to build the same thing, if not very similar! I'm on Libera irc as stagas if you'd like to have a chat.

The example is a very vague design and doesn't have an exact implementation yet, I do however have an expression compiler (unpublished yet) that targets WebAssembly directly (no binaryen or anything else, builds raw wasm on the fly in less than 5ms, you could literally compile a new function on every animation frame xD) and is designed to support features like argument extraction and push variables from outside easily (gets you a list of arguments and their ranges and you can make a knob on the frontend for example on the fly).

Yeah I'm happy to have a chat, IRC is easier for me, i don't use anything else but if you have some other idea for communication let me know.

(the operator choice if i remember correctly was because it was complicating my parsing so i changed it to make the parser impl. smoother, but that's legacy already :p)

[dy]

That's cool. I had a plan for subscript to learn to compile to wasm binary too. Maybe I can learn how to hook it up to your compiler - or just use that instead. Do you have some example or docs how you run it?

I guess I'd very much liked to come up with standardized syntax that we can share, for now I'm coming from "common syntax" assumption - would be cool to have sound code-chunks that you can copy-paste to any more-less standard language - Python, Go, JS, C++, Java, Rust - they share some syntax parts. Something like glsl but for sound.

Also would be cool to come up with single way to define sounds.
I like your minimal example kick(param1, param2, ...) = ...actual formula.

A couple moments.

1. t is implicit context param in your case, which is reasonable, but non-conventional. Should that mb be first argument in kick(t, ...params) = ...? That would act as indicator if sound is time-invariant. Or mb that's useless noise.
2. a|b $> $*.8+$|c - whar's the difference between $> and | here? isn't that just a | b | $*.8+$ | c?
3. | operator naturally has precedence in langs below + operator, so eg. mixing a | lp + b | lp would require explicit grouping as (a | lp) + (b | lp) - is that something you account for?

Couldn't find you in irc, is that https://web.libera.chat/? Need some intro, haven't used irc for ages.

[stagas]

You could use a client like HexChat though the web client should work i just tried it. Just send me a /msg stagas hey when you connect and i'll see it. Getting back to you for the other points.

[stagas]

Re: our IRC conversation

regarding syntax:

I think syntax is a bikeshed, what I am aiming now is to get a normal infix (delay(lp(saw()))) implementation working end to end. I'm more concerned how to manage state per function as sine() | lp() | delay() every call has to match to the state it was being used earlier because in live-coding adding sine() | delay() | lp() | delay() <- what happens to state of delay now that we added one more, which one gets it?
The only actor that has knowledge is the editor that produces the code and it can diff, or they can be matched by their arguments signature which will hopefully be unique enough as in: delay(300) as long as it's the only one with that argument value, it can move around.

So in short, there are implementation difficulties that are not necessarily related to syntax as it can be subjective. The aim is to build an "intermediate"-kind language that does the "hard work" of managing state and variables etc, so then other syntaxes can be built on top, or used on its own.

Given it being an intermediate its syntax is going to be determined by what's easier/simpler for the compiler/parser to process, doesn't add complexity to the code and is still usable on its own.

Once there's an engine like that and it's working and it's producing audio correctly and robustly, anyone can experiment with whatever syntax they imagine as this is going to vary always (there is no perfect syntax).