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.
"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.
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
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
#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
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 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!
Ok, the refocus was the right idea. It works now.
About 4/5h ago, I thought "ahh getting rid of the "src" around every argument, will not be thaaat hard".
Oh boy was I wrong haha
But I have made progress towards supporting real continuations.
I think the way to go now is to completely resolve them in the simplification step. And then just dealing with the Timed Function calls individualy
Hannes Güdelhöfer
