tragic. pygame.display.flip seems to always imply a vsync stall if you aren't using it to create an opengl context, and so solving the input events merging problem is going to be a pain in the ass. it is, however, an ass pain for another night: it is now time to "donkey kong"

EDIT: pygame.display.flip does not imply vsync! I just messed up my throttling logic :D huzzah!

someone brought up a really good point, which is that depending on how the touch screen works, it may be fundamentally ambiguous whether or not rapidly alternating adjacent taps can be interpreted as one touch event wiggling vs two separate touch events

easy to verify if that is the case, but damn, that might put the kibosh on one of my diabolical plans

ok great news, that seems to not be the case here. I made little touch indicators draw colors for what they correspond to, and rapid adjacent taps don't share a color.

bad news; when a touch or sometimes a long string of rapid touches is seemingly dropped without explanation, nothing for them shows up in evtest either D: does that mean my touch screen is just not registering them?

I want to add a pair of instructions for switching between (0, 1) range and (-1, 1) range. so

u = s * .5 + .5

and

s = u * 2 - 1

what are good short names for these operations?

EDIT: can be up to three words, less than 7 letters each preferably closer to 4 each

why the hell am i outputting 48 khz

i'm pretty sure i can't even hear 10 khz

i love how a bunch of people were like it's because of nyquist duh and then the two smart people were like these two specific numbers are because of video tape and film

EDIT: honorable mention to the 3rd smart person whose text wall came in after I posted this

I'm going to end up with something vaguely resembling a type system in this language because I'm looking to add reading and writing to buffers so I can do stuff like tape loops and sampling, and having different connection types keeps the operator from accidentally using a sine wave as a file handle.

I've got a sneaking suspicion this is also going to end up tracking metadata about how often code should execute, which is kinda a cool idea.

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.