aevais it ugly enough to cause paint to peel? probably! is it intimidating to hypothetical new players? probably! however, this continues to be my guiding light:
This is how the old connection workflow worked if one of the sides of the selection had more than one possible option.
I have made a lot of patches with this old workflow and I am convinced now that despite what phones and tablets and unreal editor and windows 95 would have you believe, click-and-drag is an *awful* interaction verb and should not be used at all in frequently used actions.
The real victory today was ripping out the ADSR implementation and replacing it with a better one. Fixed a bunch of edge cases that had been bothering me, but also the new one is much simpler. The attack, decay, and release parameters now are the number of seconds to bring the amplitude from 0 to 1 or vice versa, and can be even modified while the envelope is running like on a proper synthesizer :O
That's the nice thing about this phase of the project. I can make major breaking changes to core functionality and I don't have to worry about things like versioning and such because "simply update every known patch file in existence by hand" is still a viable version migration strategy.
i think it's funny that it's been a little under half a year and i still haven't built any of the cool procedural wire drawing stuff i hashed out at the start of this devlog thread yet, because it turned out not to matter all that much in practice. i'd still like to take a shot at it, but it probably won't be soon
I added a quantizer and a thing for generating random repeating sequences to mollytime tonight :D
This song is probably one of my favorite things I've made in a while ^_^
I don't have OBS set up on this machine right now, which is too bad, because otherwise you would have got to see me tinker with the patch while it was playing :)
I think this might be the first time that I've gotten a song stuck in my head that I made myself https://mastodon.gamedev.place/@aeva/115575598757344830
I wrote a python script to survey the distribution of opcodes in the mollytime example patches.
The bipolar-to-unipolar opcode is used 71 times, but the unipolar-to-bipolar opcode is only used 8 times so far. I'm reasonably sure that most of these are used to couple oscillator tiles to mix tiles.
I feel like this is probably a pretty good sign that having mix assume a 0-1 alpha like a normal lerp would was a mistake.
seems like it'll probably be a good idea to change the mix node to take a bipolar alpha value, and update the various random number generators to emit random bipolar values instead of unipolar values, but i'm gonna fiddle with this analysis script some more to better determine if that's a good idea or not
jfc I've written a lot of mollytime patches.
This table shows each opcode I've attached to a "mix" node, and how many times I've made that connection.
"const" is a numeric constant, "stu" is the bipolar-to-unipolar converter, "uts" is its inverse, "flp" is a flip-flop, and "midi_hz" is midi note number to hz.
It's unclear if making the mix alpha unipolar was a mistake or not. There's quite a lot of multiplies here, and I often use multiplies to pull values towards zero.
note -> mix is bizarre (that's a midi note from a connected midi device, so usually that's a magnitude of about 30 to 90), but midi_hz -> mix is *really* bizarre (that's hz from a midi note, so somewhere in the ballpark of 3 or 4 digits normally). I don't remember any of these, and its weird that note happened 4 times. I wonder if these are bugged patches
I think I'm gonna keep mix's alpha unipolar. It seems likely that if I were to change it to bipolar, I'd just end up flipping the number conversions the other way.
This is the whole opcode survey. This just lists the total counts of each opcode, no information about what they're connected to. Also this is only for the patches I've bothered to check in to git, since I'm not on my normal computer at the moment.
Each number is me dragging and dropping a tile 😅
Besides putting to rest whether or not I should change the behavior of the mix instruction, I also put this together to help me decide on categories for organizing the tiles, as the obvious categories are too lopsided.
However, my sister wisely convinced me that top level categories are a waste of time and it is more useful to organize by vibe, eg make tiles adjacent because they feel like they should be together, and so that is what I am planning on doing now.
I know she is correct because I'm already kinda doing that. Also consider, "oscillators" is a category that would make sense. The moon is an oscillator, and sin is an oscillator, but the moon absolutely should not be in the same drawer as sin. This is important.
Rewriting the part catalog in the pick-and-place mode didn't take long at all it turns out. Here's a short video showing how the new version works.
The main difference is you select the catalog page from a sidebar instead of paging through them like its mario paint.
ok whew yeah the new pick-and-place UI is much nicer to work with. here's a patch a made real quick to validate that it's a better workflow #mollytime
are you in the mood for roughly five minutes and thirty seconds of filtered feedback loops being gently agitated by random noise and the occasional saw wave? because you'll never guess what I made in #mollytime tonight
not shown in the video, but if you manage to send the signal off into infinity, the "beam" disappears from the oscilloscope. if you manage to generate NaNs, the oscilloscope screen wipes to black.
(tying this into my devlog thread) https://mastodon.gamedev.place/@aeva/115637167270104375
alright, I've added a thing that is very definitely not a monad, called "go" which I guess is a sort of macro or syntax sugar to allow you to make the order of a given input port's, uh, inputs... make the order of an input port's inputs explicit.
and then I used it to make a kinda terrible sequencer! enjoy :D
(this is a short video with sound, please turn your sound on! but only if you want to)
I realized there was a bug in that patch (that I don't feel like explaining), and so I recorded a new version for your enjoyment. Also I made the sequence a little more elaborate. #mollytime
I added a new tile called "tweak" which lets you adjust its value live with the mouse wheel when the mouse is hovering over it. I haven't added an indicator for it yet, but the scope tile works fine in the mean time.
Here's a simple FM patch I whipped up to demonstrate it.
(video demonstration with sound)
#mollytime
I really need to make it so I can save the tweak positions next because look er listen to this :O
I HAD A VIOLIN HIDDEN IN HERE THIS WHOLE TIME :O I HAD NO IDEA
(more video w/ sound)
#mollytime
I added a little indicator to the tweak tiles so you can see what the f im doing. Anyways here's four minutes and twenty one seconds of me doing. (video w/ sound) #mollytime
not the final appearance, that's just a widget I threw together in about a half hour tonight
my strategy of allocating registers by simply heap allocating a few hundred floats wrapped in shared pointers has held up astonishingly well so far, but I think I'm going to switch to allocating the register file as a single array up front when a patch is compiled, and then copying values that should persist out of the previous iteration's register file during the program change on the audio thread.
this makes polyphony a lot easier to reason about. the other thing that makes polyphony a lot easier to reason about, is I've decided to have the number of polyphonic lanes be configured in a non-existent patch settings screen, rather than try to infer them from the patch. you get however many midi voices you want times however generic helper lanes you want (such as two if you want to do something fancy for stereo)
if you don't do anything that would be intrinsically polyphonic, like use midi or check which lane you are in, then you get a monophonic patch. I think that is reasonable behavior.
I'm a bit closer to figuring out how to make functions workable, since I'm trying not to paint myself into a corner there while I rework how the compiler works. One of the big open problems was what to do when someone produces a patch with a function that calls itself. The answer turns out to be "nothing" :) It's literally not possible with my chosen priors to support recursion, nor is it useful to.
as it happens, you can already write recursive algorithms anyway because the language supports cycles in the execution graph just fine. it's actually better, because you can't accidentally create infinite loops that block execution forever or oom on accident this way. ironically, allowing functions to recur does not make explicit graph cycles, which makes it impossible to make work without any flow control or stack machine. it's more efficient not to support it at all.
anyways, I think I have a clearer vision now as to how I'm going to implement polyphony. the main unsolved problem right now is how to make diagnostic tools like the oscilloscope have a coherent UI.
also I had this great realization that the execution model is not all that different from that of a spread sheet. registers are addressed by identity rather than position, but that's the main difference. the register file thing will make it a lot more similar though.
side thought: this devlog thread has been long enough to make the mastodon web ui bug out for a while now, but i kinda wanna keep it rolling and see how bad it can get XD
Eniko Fox@eniko if john mastodon didn't want it this way he would have fixed it before abdicating from the throne
Josh Simmons