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.

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.

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.