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.
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 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.
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.
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.
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.
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 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
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.
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.
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)
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
@aeva A fitting patch for the occasion!
Happy new year <3
@aeva I was thinking how one could map the bouba-kiki scale to the 0-1 range in either direction. Because 0 graphically is very bouba but spoken sounds more kiki, while 1 is kiki graphically but sounds bouba when spoken.
I call this effect ludonarrative dissonance. /s
@essojadojef @aeva
Depends on the language. In Swedish they match quite nicely: 0="noll", 1="ett".
The solution is of course obvious: you need to move to Sweden :)
@aeva browsers can do WebMIDI, no? Perfect for a survey.
Edit: sorry, that actually requires a hardware synth: https://developer.mozilla.org/en-US/docs/Web/API/Web_MIDI_API
But there are JS synths AFAICT.
@aeva then you probably recognize this chunk of code now:
@lritter this is the "make it good later" version I put together yesterday https://github.com/Aeva/mollytime/blob/6926ed4725949b04584ac24647c6c107fcb190c3/src/patch.cpp#L3247
I want to rework it such that it keeps track of the actual age of a lane though, and not use the position relative to the head of the ring buffer as a proxy for age.