2024-05-05 - measuring things
i've continued work on kplay over the last week. notable stuff -
- more kernels - dac_follower and dac_randomizer as mentioned in the last post. action_list for a lower-level list of explicit dac and pin actions, versus note_seq_player and nsp_varsize. linear_slide for moving a dac output linearly from one value to another over a specified range of time
- save / load / autosave - there's now a basic save/load function, and kplay can take a filename to load on launch. autosave persists the state every several seconds. this is good because i have very little input sanitization and there are lots of ways to crash the program and it gets tedious rebuilding things from scratch
- output naming - in a big moment of "why the fuck didn't i think of this earlier?" i realized that being able to name outputs would be super handy. so now dac and pin outputs can be named, and that makes it easier to see that you're affecting the dac connected to the level control of the filter the square wave is plugged into or whatever. that also gets persisted in the save files, so i can remember what was patched to what
today i sat down to do a thing i've been meaning to do for a while: figure out the frequency range on the wave generators. generators have 3 controls that affect the output frequency. "key" and "control" have voltage controlled inputs...i can drive them with dac outputs. alas, the one with the most influence - "tune" - has no control option besides the knob. and the knobs are touchy
so i set out to measure the ranges. start with the tune knob full left and key/control both at 0, find a minimum. tune knob full right, key/control at 255, find a maximum. test a few other states to get a feel for how each input affects the output. see how the different generators behave compared to each other.
as a side note, i now know my own hearing max freq is now somewhere around 14.5-15kHz. getting old sucks
i have 4 generators, 2 squares, a sine, and a saw. i put each of them through the same series of tests. 3 of the 4 (1 square, the sine and saw) have fairly similar properties -
- with the tune knob full left, the base frequency is 1-2Hz and the max frequency is 50-60Hz. this is too low to be particuarly useful
- with the tune knob full right, the key and control inputs hardly matter. the frequency is going to be in the 24-26kHz range regardless and that's beyond human hearing range
- with the tune knob adjusted for a minimum frequency of 10Hz, the max frequency will be 10-12kHz. this is a pretty effective coverage of human-hearable, i'll take it
the other square though...it's a weird one. when the tune knob is full left and key/control are maxed, i only get about 5Hz out of that one vs 60Hz from the others. and when i do the 10Hz baseline, the max is only around 800Hz. i did a few steps up from there and found for each 20Hz of baseline increase i could get the max frequency cap to go up by 1-2kHz. there's a "not too bad" point with a minimum of 40Hz and max of 3800Hz...reasonably useful but still weirdly constricted versus the others
i tried swapping the square modules to see if the problem was actually a power supply issue or something like that. nope, the problem follows the module. i decided to order a replacement...i might still find use in the extra one but i'd like to have a 2nd square with roughly the same characteristics as the 'working' one i have
i will also do some more testing to get a picture of the input value:output frequency trend over the span of possible inputs...is it a line or a curve? i'm actually not sure! knowing that would allow me to enhance kplay with some actual like, note values and stuff. i can tune to a baseline and then the software can know that key x and control y = output freq z
tempted to set up an automated testing thing where it makes the adjustment to inputs then captures a second of audio and does fft shit to find the frequency peak. i could generate the full trend that way...hmm...
back to blog index
back to jattdb.com