aeva
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.
Efi (nap pet) 🦊💤
LR@lritter well hey would you look at that, 1000 sine oscillators only 98% - 99% load
it has other problems, so I wouldn't say it is up to task yet exactly
Sebastian Felix Zappe@lritter @aeva for the record, getting an orchestra sound right like this requires quite some fiddling (no pun intended)
(Source: I spent more time than I should have recording myself playing the violin – and never achieved the orchestra sound I wished for, each additional layer simply caused more phase cancellation)
@hypo @aeva but yeah, just for sound you could just do the audio analog of filming yourself in different places with a static camera and then superimpose the images; except with audio you need no masking and can just add them (as long as there's no interference sounds in the bg that also accumulate).
so you mic the place as if you were recording an orchestra (stereo mic), then move a chair to the right, play it again, etc.
Evie 🏳️⚧️
>>>>>>>
like
struct SimdBlock { float values[8]; }
that kinda thing. and then i set the alignment on that type, and i make my arrays be arrays of that type. and then i can even pass them into/out of functions (that can get inlined) and all that good stuff and the information the compiler needs to vectorize is pretty much always there
linear cannon
halcy @ 
@aeva psst
for { int math; float math}
is slightly better than
for { int math }
fot { float math }
cuz int and float uses different parts of the cpu so they can overlap slightly
d@nny disc@ mc²Mutex<T> which produces a lock guard that dereferences to T) is an extremely good idea but you can very easily make a tiny wrapper to do that in c++ even if the stdlib doesn't do that itself@hipsterelectron in my experience std::execution is really good when you want full saturation of your computer's resources and don't care about the UI being frozen for a few minutes.
I'd probably just spin up a few threads with std::thread and use atomics to set up a fence and a common shutdown flag
