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.
idk why the background looks so distorted in the recording
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
#mollytimeare 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
I rewrote my oscilloscope today
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.
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)
#mollytime
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.
#mollytimeI added a new tile called "tweak" which lets you adjust its value live with the mouse wheel when the mouse is hovering over it. I haven't added an indicator for it yet, but the scope tile works fine in the mean time.
Here's a simple FM patch I whipped up to demonstrate it.
(video demonstration with sound)
#mollytime
I really need to make it so I can save the tweak positions next because look er listen to this :O
I HAD A VIOLIN HIDDEN IN HERE THIS WHOLE TIME :O I HAD NO IDEA
(more video w/ sound)
#mollytime
I added a little indicator to the tweak tiles so you can see what the f im doing. Anyways here's four minutes and twenty one seconds of me doing. (video w/ sound)
#mollytimenot the final appearance, that's just a widget I threw together in about a half hour tonight
my strategy of allocating registers by simply heap allocating a few hundred floats wrapped in shared pointers has held up astonishingly well so far, but I think I'm going to switch to allocating the register file as a single array up front when a patch is compiled, and then copying values that should persist out of the previous iteration's register file during the program change on the audio thread.
this makes polyphony a lot easier to reason about. the other thing that makes polyphony a lot easier to reason about, is I've decided to have the number of polyphonic lanes be configured in a non-existent patch settings screen, rather than try to infer them from the patch. you get however many midi voices you want times however generic helper lanes you want (such as two if you want to do something fancy for stereo)
if you don't do anything that would be intrinsically polyphonic, like use midi or check which lane you are in, then you get a monophonic patch. I think that is reasonable behavior.
I'm a bit closer to figuring out how to make functions workable, since I'm trying not to paint myself into a corner there while I rework how the compiler works. One of the big open problems was what to do when someone produces a patch with a function that calls itself. The answer turns out to be "nothing" :) It's literally not possible with my chosen priors to support recursion, nor is it useful to.
as it happens, you can already write recursive algorithms anyway because the language supports cycles in the execution graph just fine. it's actually better, because you can't accidentally create infinite loops that block execution forever or oom on accident this way. ironically, allowing functions to recur does not make explicit graph cycles, which makes it impossible to make work without any flow control or stack machine. it's more efficient not to support it at all.
anyways, I think I have a clearer vision now as to how I'm going to implement polyphony. the main unsolved problem right now is how to make diagnostic tools like the oscilloscope have a coherent UI.
also I had this great realization that the execution model is not all that different from that of a spread sheet. registers are addressed by identity rather than position, but that's the main difference. the register file thing will make it a lot more similar though.
side thought: this devlog thread has been long enough to make the mastodon web ui bug out for a while now, but i kinda wanna keep it rolling and see how bad it can get XD
I recorded a video of me constructing a self-playing #mollytime patch from scratch, and I'm pretty happy with how it turned out :O.
If you don't want watch in mostly silence as I set up the basic structure of the patch for ten minutes and thirty six seconds, the music picks up at around 10:36.
https://www.youtube.com/watch?v=Q7qHcTszBhU
"starlight" mollytime live jam
#mollytime is polyphonic as of tonight btw
(video with sound)
it's also a crashy mess now. maybe I'll simply riir it in rust tomorrow. (joke)
fixed it 😎 now it is nice and stable. no riiring necessary 😌
I kinda wanna put together a thing that takes the last sent general midi program number on a given midi channel and translates it to a scalar value or three that has them neatly ordered on a gradual spectrum so that mollytime patches can use it as a modulation parameter. eg ranking them on a spectrum from melodic to percussive or something like that
ah! i know what axis i should sort the general midi instruments on: bouba-to-kiki
now i want to throw together a little pygame app and do lots of a/b comparisons to science this out. what's the most affordable authoritative general midi synthesizer if you don't have a roland sound canvas handy? maybe the default windows one? (serious inquiry)
ok I wrote said pygame app and powered through ranking random instrument sounds in terms of relative kiki-ness, and made the resulting lookup table into a midi parameter tile in #mollytime.
this is the result:
(video with sound)
mollytime/src/kiki.inl at 4199b41915071c515fa2c8b89f67d6fc7c2781de · Aeva/mollytime
virtual synthesizer. Contribute to Aeva/mollytime development by creating an account on GitHub.
I am intending on also scoring them with a separate bouba ranking, which I expect to mostly track as the inverse of kiki, but I think some sounds are both.
one thing critically missing from this data set is the weird percussion the general midi does with channel 10
so like, ignoring all the sour notes that are coming in through channel 10 that are meant to be interpreted as aharmonic percussion sounds, this kiki score is a surprisingly good substitute for a proper general midi patch set. I'm running random midis through it and this is punching waay above its weight :O
HAPPY NEW YEAR EVERYONE! i recorded a #mollytime patch-from-scratch video to celebrate. 71 minutes is probably too long to post on mastodon, so here's a you-tube link instead:
https://www.youtube.com/watch?v=GQX588JlVFg
the grand finale starts at 1:10:02 if you wanna skip past all the slow build up
YouTubei need a new filter for mollytime. TopologyPreservingTransformStateVariableFilter has worked out pretty well, but it's too expensive for polyphony and has a nasty tendency to explode when you set the cutoff too high or too low
@aeva i do that sometimes
@hipsterelectron *sets ur filter cutoff to three octaves above the current note and hovers over C8* :3
aeva
d@nny disc@ mc²
ideaPDish