heh, my laptop is on battery again but at a much higher charge than earlier, and the 1000 oscillators stress test now hits 89% load this time. perf profiling on modern CPUs is actually completely fake but we do it anyway 😌

my ultra spec is my laptop, but only when it is running on mains power in a cold room, and only on runs where intel's magic beans decide to consistently schedule my audio thread on a P core instead of an E core

ok I got a lot of work done on implementing polyphony today! and by that I mean I had a 3 hour nap this afternoon 😌 (and narrowed down the design space a bit during said nap)

implementing it in the VM itself will be pretty straight forward. registers and instructions can be monophonic or polyphonic, and polyphonic instructions just map the same thunk to each lane in its registers. Some tiles will have to be monophonic, and those would get an implicit sum if you don't provide an explicit one.

that much fits pretty naturally in the architecture I already have, and the hard part is expressing it cleanly in the visual syntax.

I think polyphony is going to be an attribute that propagates from input tiles (eg midi note) that can't propagate past monophonic tiles (final output, loop write, as well as a tile for explicitly blocking it from propagating).

I'm going to avoid introducing unordered loops and flow control to the language, at least for now though.

I'm thinking of also having a simple scheduler for allocating events to polyphony lanes, and there's a few different modes I think would be useful. This would be configured per-patch to keep the syntax cleaner.

All of the schemes are some variation on X * Y lanes. X is the number of distinct notes that can be assigned. Y is the number of lanes per note.

For example, the "mandolin" scheduling strat would have X=4 Y=2 by default. The X indices are allocated round robin each time there is a new note. Each time there is a repetition of one of the allocated notes instead alternates which Y lane receives the event.

This would be handled implicitly by mollytime so your patch doesn't have to do any special handling for the parallelism, you just tell it where you want the XY->mono merge to happen, and optionally merge the Y lanes earlier.

This could probably also be implemented as a single scheduler with X lanes for notes times Y lanes for alternation times Z lanes for spread. I don't have any immediate ideas for patches where I'd want Y and Z to both be >1 though, so mostly it depends on whether a unified approach simplifies anything.

I'm leaning towards just having separate scheduling strats and adding more if I decide they're too limiting, instead of a more complicated monolithic one.

side thought, I've been thinking it would be fun to have inputs for various natural phenomena like the current phase of the moon, what the local tide would be if you lived somewhere with tides, current rainfall, wind speed, etc.

I'm trying to decide how automatic the location stuff should be. I could have a settings page where you just pick what location you want on a map, and that avoids having to weird out players with sketchy permissions requests.

the weather phenomena one is even worse because there's pretty much no good way to do that without requiring an internet connection, and I'd have to find a weather thing I could poll that's bot friendly and not a weird privacy harvesting scheme.

I'm considering maybe making these optional plugins for your optional enjoyment that way games don't have to ship with this stuff if they don't use it which they almost certainly wont.

Mollytime patches now can output mono or stereo sound, and they can have any number of generic inputs and outputs that can be routed to hardware ports or other programs.

I've decided that surround sound doesn't exist for now. I've got some ides for how to handle it, but it's kinda silly to bother right now since I don't have a surround sound system to test it with. I'll probably get some fancy headphones for it later, but it's not a 1.0 feature.

well, in the other news mollytime has several filters now as of this weekend.

this video shows off some of the mind boggling effects mollytime is capable of now (this is an evolved version of the drum patch I posted a recording of a while back) and I'm very proud of it though I have to apologize I forgot to mute my browser and so there's a discord bloop in the recording just before the two minute mark I don't really feel like doing a retake right now
#mollytime

I woke up this afternoon and realized this idea I had 98 days ago totally falls apart if you create a data dependency between invocations of the same function eg fn(fn()). Good thing I didn't build it!

I think instead I will probably have polyphony be implemented via shadow copies of polyphonic tiles.

https://mastodon.gamedev.place/@aeva/114968771707424143

I wrote a new screen for managing tile connections in mollytime, and I imagine a professional ui designer will feel real physical pain looking at this wonderful screenshot, which is why I decided to share it :3 It's pretty much the opposite of minimalism and it's sooooo functional and I can work a lot faster now ahahaha!

Now it only takes three or four clicks to toggle a wire whereas before it took more in some situations.

is 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:

https://mastodon.gamedev.place/@aeva/114612264992461462

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.

https://mastodon.gamedev.place/@aeva/114842120034168266

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 ^_^

#mollytime

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.

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.