aevaI 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
I recorded a video of me constructing a self-playing #mollytime patch from scratch, and I'm pretty happy with how it turned out :O.
If you don't want watch in mostly silence as I set up the basic structure of the patch for ten minutes and thirty six seconds, the music picks up at around 10:36.
"starlight" mollytime live jam
#mollytime is polyphonic as of tonight btw
(video with sound)
(video with sound)
LR@lritter totally figured it out. no fancy tools, just the time honored debugging strat of doing something else for a few hours and then the answer comes to me right as i'm about to go to bed 😎
@aeva then you probably recognize this chunk of code now:
@lritter this is the "make it good later" version I put together yesterday https://github.com/Aeva/mollytime/blob/6926ed4725949b04584ac24647c6c107fcb190c3/src/patch.cpp#L3247
I want to rework it such that it keeps track of the actual age of a lane though, and not use the position relative to the head of the ring buffer as a proxy for age.
