After effects is usually used for compositing and also supports some vfx, but isn't meant for realtime use. This would be similar to vvvv or touchdesigner, used for audio reactive visuals (VJing), interactive art exhibits, etc.
I think it has to do more with familiarity than complexity. You could have a good understanding of features like the ones showcased in the blogpost, but it could take you a minute of staring at a line to parse it if someone uses it in a way you're unfamiliar with. Doing that for potentially hours on end would be a pain.
It's definitely something I'd write for fun/personal projects but can't imagine working with other people in. On a side note, I believe this is where go's philosophy of having a dead simple single way of doing things is effective for working with large teams.
Interesting. Does anyone else see a band of green in their blue? My boundary is at 170. Greener than 85% of the population. This point looks like the transition between blue and green to me, to the right I can see the gradient go to blue then to green again, then back to blue. So there's a green band in the middle of my screen.
Looking at the demo source code it seems like it is running everything in browser and is not prerendered. It just lacks a parser. So the AST nodes in all examples are created through function calls https://github.com/fal-works/firedancer/blob/4a15e80fe55893b... .
Interesting problem to think about. The beauty of modular for me has always been that you can take voltage from literally anywhere and use it for CV. Modern modules also have an insane variety in controls and control surfaces, even for standard things like VCOs you have a ton of variety and featuresets. Saving the patch state is one thing but actually notating is crazy. Like I can't imagine someone being able to read this notation and play it accurately like someone sight reading a piano piece. You'd surely require familiarity with the setup ahead of time. As for recording it for posterity, being verbose and describing what you're doing in full works, I guess.
Didn't pd basically borrow spice's circuit layout language for the way it textually stores patches? I know it exists and it's so brittle that nobody ever, ever, edits it, but maybe there's a way to make it a little more resilient and editable?
A textual notation for rich and generic graphs can only become more "resilient and editable" by giving nice names to entities and by keeping documents small and hierarchical.
Not true at all; parsing matters. Json and yaml (and s-expressions and...) are equivalent but yaml having significant whitespace makes it mangleable in a way that the others aren't.
I think most experienced players are already pretty optimal at crafting. There might be some rare case where it might save you a couple div at best. It's usually obvious by design how to achieve something. Of course there is a market because some part of the playerbase can't do this (which might become lower) and some part of the playerbase still sees it as time efficient to just buy it precrafted. Likely there's less incentive to craft in bulk, large bulk currency trades become more expensive, making the crafted items more expensive for the unkowing new player who doesn't use this tool. Personally, I don't think it would change the economy that much.
Agreed, and I think my point around adoption by the masses was made a little too lightly - as you mentioned there will always be a part of the player base who prefer buying and playing the game rather than spending time crafting (regardless of how trivial the craft is).
I think the heuristic approach is not as bad as you think. Human crafters, and the current crafting techniques we have are pretty efficient. You don't need to explore the full graph of random states because the mod weights themselves are a representation of those states. As a human I can't think of any crafting item (alt and chaos spamming aside) where the probability isn't a simple to understand number. You think you can use something like modweight x currency cost (x some time modifier for acquisition and use of currency) for scoring. This is how craftofexile does it.
The more I think about this the more I feel you went really overkill on this. The complexity is several orderers of magnitude lower than what you claim. Like try crafting stuff on the emulator and see how easily you can narrow it down to usually 2 or 3 choices at most steps. There should be really easy heuristics to invalidate most branches. I've also used the COE simulator a ton and never had to model something that's on the order of 50+ states even.
