oh, so I was thinking about the sampling rate stuff because I want to make tape loops and such, and I figured ok three new tiles: blank tape, tape read, tape write. the blank tape tile provides a handle for the memory buffer to be used with the other two tiles along with the buffer itself.

I thought it would be cute to just provide tiles for different kinds of blank media instead of making you specify the exact buffer size, but I've since abandoned this idea.

bytes per second is 48000 * sizeof(double)

wikipedia says a cassette typically has either 30 minutes or an hour worth of tape, so

48000 * sizeof(double) * 60 * 30

is about half a GiB, which is way too much to allocate by default for a tile you can casually throw down without thinking about.

I thought ok, well, maybe something smaller. Floppy? 1.44 MiB gets you a few seconds of audio lol.

I have since abandoned this idea, you're just going to have to specify how long the blank tape is.

I came to the earlier conclusion that mollytime doesn't currently have the headroom needed for polyphony by eyeballing this perf chart I collected the other day: https://mastodon.gamedev.place/@aeva/114894322623350182

My rough estimate from eyeballing the zoomed out screenshot is that patch took 12 % of the frame cadence to run.

I added a simpler measuring system that just measures the start and end times of that loop and divides the delta by the time since the last start time, and most of my patches are only at 1% load.

hah, I programmatically generated a patch with 1000 oscillators and remarkably that's just a smidge past the limit. my load monitor reports about 99% load, the sound frequently crackles, but you can hear the correct tone (they're all running at 440 hz and their outputs are averaged). It sounds correct with 500 oscillators, and I don't feel like bisecting the real limit right now.

I think that's adequate proof that mollytime has more than enough headroom to justify implementing polyphony.

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