aevai made a tape loop #mollytime
i just realized i probably can't afford polyphony unless i really juice the perf of the vm
I guess I could try "multithreading"
is calling std::for_each(std::execution::par, ...) from a realtime thread like stuffing a portable hole inside a bag of holding
come to think of it, when you do a bunch of the same math in a for-loop sometimes godbolt gives you fancier math ops so maybe i should just try it that way first 🤔
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.
so either my math is wrong or the lesson learned here is you shouldn't add instrumentation markers for functions that run in under 100 nano seconds
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.
hah, if I plug my laptop in, the 1000 oscillators stress test only has a load of 54% and mostly sounds fine (hitches every few seconds)
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.
The "prism" scheduling strat is the other XY strat I have in mind right now. The X indices are also allocated round robin like the mandolin strat, but the midi events are copied verbatim to each note's Y lanes. A "prism" tile gives you a unique alpha value for interpolating across the Y lanes. This would be useful for stuff like unison spread, and maybe whatever it is that my friend leonard wants 1000 oscillators for.
I was thinking of having a "piano" mode that is just X=127 Y=1. each midi note gets a dedicated key, no lane repetition. I could have a tile where each lane provides a gate and a note number, and the return value is a gate describing how much sympathetic resonance the lane should receive from the other lanes with compatible frequencies. Basically use it to make the grandest bosendorfer. But that doesn't actually need a special scheduler mode, it can just be "prism" mode.
also the sympathetic resonance tile would work fine with the "mandolin" scheduler
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.
a bizarre consequence of upgrading to Fedora 42 today is all my patches in mollytime are reporting lower CPU usage. i'm guessing this is entirely due to recompiling with a newer version of llvm. I really hope this means its just faster now and not that it's reordering instructions around my calls to std::chrono::steady_clock::now or something
the 1000 oscillators benchmark (laptop plugged in) is roughly the same as before though so idk
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.
A friend is going to take a shot at a Windows port. Neither of us are familiar with the various Windows audio APIs, so I figure it's best if we just shoot for regular stereo outputs for now and worry about the dynamic i/o ports later. I'm hoping we can have that be a cross platform feature though.
Late last night I was thinking about adding the psmoveapi library to mollytime so I can use my old psvr wands with it, but now this morning I'm wondering if maybe someone else has already wrapped psmoveapi to translate it to midi and if I should just use that instead. I haven't found any such thing though.
anyone down for some drone I made some drone
(remember to turn the sound on) #mollytime
(remember to turn the sound on) #mollytime
I really need to add a "fade out" button
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
are you in the mood for some chill eerie slow experimental noise music? great, go find your headphones that have the good bass response, because I made some chill eerie slow experimental noise music #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.
are you ready for 6 minutes and 26 seconds of uplifting harsh yet pleasant sounds because you'll never guess what i just made #mollytime
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:
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.
The real victory today was ripping out the ADSR implementation and replacing it with a better one. Fixed a bunch of edge cases that had been bothering me, but also the new one is much simpler. The attack, decay, and release parameters now are the number of seconds to bring the amplitude from 0 to 1 or vice versa, and can be even modified while the envelope is running like on a proper synthesizer :O
That's the nice thing about this phase of the project. I can make major breaking changes to core functionality and I don't have to worry about things like versioning and such because "simply update every known patch file in existence by hand" is still a viable version migration strategy.
i think it's funny that it's been a little under half a year and i still haven't built any of the cool procedural wire drawing stuff i hashed out at the start of this devlog thread yet, because it turned out not to matter all that much in practice. i'd still like to take a shot at it, but it probably won't be soon
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 ^_^
I don't have OBS set up on this machine right now, which is too bad, because otherwise you would have got to see me tinker with the patch while it was playing :)
I think this might be the first time that I've gotten a song stuck in my head that I made myself https://mastodon.gamedev.place/@aeva/115575598757344830
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.
seems like it'll probably be a good idea to change the mix node to take a bipolar alpha value, and update the various random number generators to emit random bipolar values instead of unipolar values, but i'm gonna fiddle with this analysis script some more to better determine if that's a good idea or not
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.
note -> mix is bizarre (that's a midi note from a connected midi device, so usually that's a magnitude of about 30 to 90), but midi_hz -> mix is *really* bizarre (that's hz from a midi note, so somewhere in the ballpark of 3 or 4 digits normally). I don't remember any of these, and its weird that note happened 4 times. I wonder if these are bugged patches
I think I'm gonna keep mix's alpha unipolar. It seems likely that if I were to change it to bipolar, I'd just end up flipping the number conversions the other way.
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.
I know she is correct because I'm already kinda doing that. Also consider, "oscillators" is a category that would make sense. The moon is an oscillator, and sin is an oscillator, but the moon absolutely should not be in the same drawer as sin. This is important.
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.
ok whew yeah the new pick-and-place UI is much nicer to work with. here's a patch a made real quick to validate that it's a better workflow #mollytime
are you in the mood for roughly five minutes and thirty seconds of filtered feedback loops being gently agitated by random noise and the occasional saw wave? because you'll never guess what I made in #mollytime tonight
not shown in the video, but if you manage to send the signal off into infinity, the "beam" disappears from the oscilloscope. if you manage to generate NaNs, the oscilloscope screen wipes to black.
(tying this into my devlog thread) https://mastodon.gamedev.place/@aeva/115637167270104375
alright, I've added a thing that is very definitely not a monad, called "go" which I guess is a sort of macro or syntax sugar to allow you to make the order of a given input port's, uh, inputs... make the order of an input port's inputs explicit.
and then I used it to make a kinda terrible sequencer! enjoy :D
(this is a short video with sound, please turn your sound on! but only if you want to)
I realized there was a bug in that patch (that I don't feel like explaining), and so I recorded a new version for your enjoyment. Also I made the sequence a little more elaborate. #mollytime
dbat 
Fabian Giesen@aeva *adjust glasses* it's only an Oscilloscope™ if it's manufactured by Eskil Sköp & Söner AB. this is merely a sparkling waveform display
Heals 
Phairupegiont@aeva is this game like, zachtronics but you have to make music? with bonus points if you use fewer arrows
@phairupegiont in a sense yes, but much more freeform. i call it a game, because it's important to me that it be fun to use and a delight to watch, but really it's more a general purpose virtual modular synthesizer
however, it would be fun to include a challenge mode of some kind, i'm just not sure how i'd go about validating a correct solution
DNA schedule@aeva this sounds like a dryad orchestra warming up. It made my cat sit up alert and stare dumbfounded at the speakers.
@ryanprior :D :D :D
@aeva they're warming up to play https://www.youtube.com/watch?v=Ftbd-TDDVMk
Pinemarten
@ryanprior i dig it
Evie 🏳️⚧️
LR
ferunando@aeva sorry, i got lost in the development. is this still pygame based or have you gone c++? i kinda have a memory of you mentioning going c++, but i don't recall to what extent ^_^
anyway, nice ^_^
Tom Forsyth@aeva Unless you're a werewolf.
Asta [AMP]
Celes 🌙@celestia I can kinda see it now that you point it out. Vague Gannondorf vibe to some of them?
@aeva not quite sure, for me it was more of a general vibe for the sound rather than the actual rhythm or "notes"
it sounds like it could be some sort of growl from an enemy or the ambiance used in some of the adult shrines 
anyway, keep making those numbers go beep! 
Erin
mym