Hannes GüdelhöferI'm not even at the hoisting state yet. Still working on the part that gets an AST where all the timings are resolved.
Then I can start to hoist the calls up, if needed.
This tickles one of the nerdiest corners of my brain.
I have a timed AST now. (nothing Hydra specific yet!)
Next up is hoisting (will need hydra specific code).
When this works out, basil will make a huge step away from #hydra.
Which still requires a lot of footwork. Need to implement all the glsl code and rendering framework etc.
If I can pull this of this will be possible:
`add <(s 4) [(<o s> 3) (voronoi [4 6])]> # out`
Hah I just found another edge case. the <o s> in the middle will currently not work as intended (in this case, it will always be s), it needs to be multiplexed with the containing <> pattern. Damn.
Currently I am converting each pattern individually to timing events, but I need to respect the inner patterns when converting 🤔
Maybe it's easier to bubble the patterns all the way up and re-construct the ast in each resolved event? That would make the resulting translation into gsls waaay easier, but probably now as small as it can be.
Could I normalize the timing signal at each sub-pattern?
Currently one cycle is 0-1, twi cycles would be 0-2.
in the code `add <(s 4) [(<o t> 3) (voronoi [4 6])]> # out` the <o t> should make one full loop when the containing pattern makes two.
If instead of using the same timing signal the inner pattern uses one that goes up 1 every full outer cycle, but from 0-1 "in every invoation", would that work?
Currently one cycle is 0-1, twi cycles would be 0-2.
in the code `add <(s 4) [(<o t> 3) (voronoi [4 6])]> # out` the <o t> should make one full loop when the containing pattern makes two.
If instead of using the same timing signal the inner pattern uses one that goes up 1 every full outer cycle, but from 0-1 "in every invoation", would that work?
"in every invocation" in quotes, because the "o" would see 0-.5, because its in the first spot of the [ ] patter. the "t" would then see 1.0-1.5 (.5-1 goes to the voronoi part).
The global timing would go from 0-4 for the whole code to loop, but the outer pattern will only be a cycle of 2 with this.
I kind alike this because it doesn't just bubble up the whole timing all the way. It makes propagation harder though.
Especially because with hoisting I would need to track the correct timings closely. 🤔
I think I managed to get this "working".
It's now split into 3 parts:
- 1. I convert all Patterns into "Timings"
- 2. I scope the timings, so they all run on global time (trickling down!)
- 3. I do the "normal" hydra hoisting, while keeping these timings in tact
I've not tested this other then looking at somer examples yet. (and even that I've only done for like 3 minutes).
My head is smoking though lol
From this:
`osc # mod <(s 4) [(<o t> 3) (x [4 6])]> # y # out`
I now can generate
`y
mod [ <(y # s 4)>(0:1|2) | <(y # [ <o>(1:1.5|4) | <t>(3:3.5|4) ] 3)>(1:1.5|2) | <(y # x [ <4>(1.5:1.75|2) | <6>(1.75:2|2) ])>(1.5:2|2) ]
osc
out `
"[ | ]" denote timing groups, "() timing information: (start:end|cycle).
I'm at the point where I can start writing the translation layer to gsls!
If this works, its gonna be so cool =D
There is a lot of crucial mini-notation features missing currently (all the modifiers like !@/*. But this is a integrated mini-notation in the Base-parser of the language! (cc @froos )
There is a few turns on the road left, but I can kinda make it out now, which is 🎉
Now I have to actually put this on a website, so I can see it!
then you blink and you wonder why you are googling "GLSL 3.00 ES" and why you get " ERROR: unsupported shader version" and why modulo isn't a think without it. wat
YESSSS
This is already so amazing!
Need to get all the timings and scalings correct.
But its looking so promising!
I still can barely contain my excitement over this.
This took quite some brain juice. I have a few of the basics to implement before I feel it is ready for the Nudel alpha test torture implementation 😅
(Like multiple outputs and inputs and syncing to the strudel time is probably a must. Ah btw @froos how to seconds map to cycles in strudel? Is there an east function to get the cpm? (Or the cycle count directly?)
If it’s ready (for alpha ) it’s gonna join dente too
huh, apparently ternaries in GLSL cannot be used with uniform sampler2D as the value they result in? :o
That means I have to hoist these timings further up, so I can replace it with more if calls.
That means I have to hoist these timings further up, so I can replace it with more if calls.
`<1 2>/[1 2]` patters are the next knot.
Maybe I'm restricting it to simple numbers for now 🤔
Maybe I'm restricting it to simple numbers for now 🤔
The basics of / and * are working now (only allowing numbers after.
The complexity of mini notation gets me every time: `<<1 2>/2 3>` is surprisingly devious! ( `[[1 2]/2 3]` is working perfect of course lol)
Uh It might actually work just like it does in strudel. Maybe the pattern is just a bit counterintuitive lol
We are going places!
#basil @pastagang FIrst draft is up. It's sharing scrappy fiddle time! https://basil.reckt3r.rocks/
cmd+enter executes.
Expect bugs lol.
Sometimes the console helps. Often not xD
@pastagang oh yeah white screen until you press cmd+enter lol
Working on loading images now.
I'm trying to find out, how much I want to stray away from hydra with this.
`s0.initImage(...)`, only works with (somewhat) predifined naming for "s0".
I kinda just wanna allow
`maggi = initImage "https://spag.cc/maggi"`.
But that would also mean finding a syntax for assigning variables.
I'm als not ready yet to deal with variables everywhere 🤔
`initImage "https//:spag.cc/maggi" # set maggi`
Variable name in the last place seems like such a sacrileg somehow lol
`loadScript` now works!
It's very hacky, because I parse the whole thing before I execute it, so I the functions aren't loaded yet, and I just need to bail on generating the GLSL code.
So I try again in that case. Surely this will not bite me later lol
sobelx now works.
But it's so hacky.
Like that it works in hydra is allready kinda a hack.
But I've hacked some more on top lol
I want to implement this "correctly".
(detecting that a function needs a special setup, and then split the drawing chain at that place and have a frame buffer in between).
Probably some interactions between that and hoisting to figure out, but that would mean, that it could work everywhere just like you expect.
(detecting that a function needs a special setup, and then split the drawing chain at that place and have a frame buffer in between).
Probably some interactions between that and hoisting to figure out, but that would mean, that it could work everywhere just like you expect.
I wanted to fix that you have to do "modR (src o0)" instead of "modR".
But it's kinda surprisingly hard?
I do the hoisting before looking up any hydra specifics, but I need to know if the argument is supposed to be a chain or not 🤔
Ahh well that broke think.
In a not so easy to fix way as well.
Time to work on continuations, to be able to fix it lol
Ui. Continuations are causing more brain knots.
I need to know when to hoist them up, which gets complicated, as they are currently comming up in timing situations.
so I need to figure out if the (#..) in `osc # (# y 2)` needs hoisting (yes).
But how about `osc # (# y 2 # rs .2)`? in that only the y needs hoisting, not the rs 🤔
Why am I dealing with continuations again?
Because I wanted to eliminate the TImings from single calls, because that makes the auto injection of `( src ...)` possible in `modR o0`.
Because I can transform `<modR modS> o0` into `<(# modR o0) (# modS o0)>`. And then it's easy to look up if I need the auto adding of src or not. But maybee going full on Continuations is too much? Timed<FunctionCall> might be enough? 🤔
Going full continuations does unlock some cooler (although maybe a but niche?) possibilites. I think I would need to resolve the continuations during hoistings though.
And then they become syntax sugar for the TImed Function calls.
Probably best to focus on that then!
I need to stop doing cool side quest and figure out lambdas and fft next.
But hey extra-hydra shaders (and a few others) are preloaded again. (Will look at hyper hydra at some point too)
🤔 Is there a world where I evaluate lambdas in GLSL land at all? And only pass in the values that need to cross the JS / GLSL boundary?
It's probably way easier to not allow that at all 🤔
ahh keep it simple first. Lambdas in JS only it is.