sndkit TODO
A dynamically generated list of public-facing TODO items for
sndkit. The TODO list is managed using this
wiki's zetdo, using the state TODO-sndkit.
port glot from mnodes to sndkit
UUID: #ace90258.
ugens page in sndkit should be procedurally generated
UUID: #93def5c1.
create graforge performance utility that works similar to pipelining diagram
UUID: #1438984d.
2022-04-03 07:23:34: inspired by reading about pipelining diagrams in CSAPP. what I'm thinking at the moment is to build an interface that renders a node list in a patch, and then times how long each component takes.
create faust nodes in sndkit
UUID: #3842ba70.
2022-05-22 09:17:49: from what I remember about FAUST architecture formats: path of least resistance would be to make small nodes where all inputs are audio rate, export to C, then call FAUST functions like tick functions. speed/performance isn't terribly important here.
2022-05-22 09:14:59: I don't want FAUST code to be in sndkit. This would only be for prototyping.
2022-03-23 09:39:38: some way to easily wrap sndkit nodes and LIL boilerplate around Faust generated C code. If I just make them single-sample tick functions.
create sound recipes page in sndkit
UUID: #ae5a3011.
2022-05-16 08:46:43: for another time, when I have more bandwidth
2022-04-29 11:15:20: a good intiial start would be to literally just make the page, and add potential sounds, and a brief description. Even just the synthwave sounds are a good start.
2022-04-06 16:20:55: My initial thinking here was to port my initial synthwave instrument elements. I feel like that would be an easier thing for me to do than make a blog series.
2022-04-06 16:18:45: it seems I made an initial recipes branch
2022-04-06 13:51:47: I think this would be a good small creative thing I could do on a regular basis. I have added it to my agenda list.
create limit
UUID: #3f1d0bba.
create cabtmp
UUID: #f6125d13.
create ANSI C version of KBVerb
UUID: #33b2d86a.
2021-12-02 09:53:52: I have FAUST generated C code. going to poke at this for a bit, see if I can't rework this.
convert chowkick into sndkit node
UUID: #31a59826.
chowkick is a kick plugin under a BSD license. it would be neat to extract the core DSP code from the JUCE plugin code, wrap it into a sndkit node, and then reduce the C++ code into ANSI C.
2021-09-10 09:32:14: clearly, this kick is not something I am going to have time for this month. will have to push aside for now.
2021-09-10 09:22:53: added the chowdsp utilities, which is where I think the WDF utilities are.
2021-09-10 09:16:40: the pulseshaper has all the circuit stuff. uses WDFs from another project I think.
2021-09-10 09:10:13: chowkick outfilter
2021-09-10 09:09:42: chowkick resonantfilter
2021-09-10 09:09:10: chowkick pulseshaper
2021-09-10 09:08:50: chowkick trigger
2021-09-10 09:06:55: ah okay. I don't think I'll need to compile this code. the DSP bits are quite simple. trigger goes into pulseshaper which goes into resonate filter, which goes into an 'outputfilter' and then a DC blocker. there's also work to account for polyphony. this will be discarded.
2021-09-10 09:02:00: peaking at the code. seeing if I can get the DSP code to compile without the JUCE plugin bits.
chowkick trigger
UUID: #3667e868.
2021-09-10 09:24:25: this is going to have to be rewritten. from what I see so far, this looks like a thing that takes MIDI signals and turns them into gate signals. for the pulseshaper.
chowkick pulseshaper
UUID: #e5d0f6b3.
2021-09-10 09:25:30: this is the most complicated bit, and is where the WDFs are. the best course of action here is to reduce the C++ code to a point where it builds okay on my system, then reduce to C.
chowkick resonantfilter
UUID: #3367c482.
2021-09-10 09:25:53: this resonant filter looks like a biquad at first glance.
chowkick outfilter
UUID: #76b11e01.
2021-09-10 09:27:19: another biquad, possibly a lowpass filter from the looks of it.
port hexwave into sndkit
UUID: #5b744390.
it's a really neat sounding technique and is part of the stb library collection, so it is public domain.
2022-06-20 09:25:53: will need to look at this more closely. I've been hesitant to move forward because I'm uncertain how the code works, but since it's "extras" code standards are a little bit lower.
2022-05-14 17:27:13: seems to be some globals being used. a bit sloppy and unsndkit-like. hmmm. there seems to be ways around this.
2022-05-14 17:23:34: created a hexwave branch and imported stb_hexwave.h as-is. I have no idea what's involved in getting it to work. Will have to examine the code.
2022-05-12 09:46:20: I should at least glance at this.
2022-04-29 11:20:54: this might prove to be an interesting oscillator for some of my upcoming gesture studies. putting on the list
2021-12-02 09:54:39: now that (sndkit) has an extras folder, I could basically drop this in now.
2021-08-03 08:52:41: code: https://github.com/nothings/stb/blob/master/stb_hexwave.h.
2021-08-03 08:52:29: demo video https://www.youtube.com/watch?v=hsUCrAsDN-M
port soundpipe to sndkit
UUID: #8222e6fc.
this is a long-term task. I eventually want every module in soundpipe available in sndkit. Some will be ported to public domain literate programs, others will just be C code with an MIT license.
2021-07-26 20:38:53: maybe someday Ill have a voc redux as an improvement to tract.
2021-07-26 20:36:44: stuff that I think I could port without issue: adsr, butterworth filters, clamp, clock, compressor, crossfade, delay, diode, dmetro, expon, line, loadwav, maygate, noise, paulstretch, peaklim, randh, saturator, scrambler, tadsr, tdiv, tenv, tenv2, tenvx, tgate, thresh, tseq...
2021-07-26 20:34:22: ones that aren't worth holding onto or are FAUST-based: autowah (FAUST), bitcrush (needs to be re-written), bl-stuff (faust, also blep replaces them), count (too basic/weird), dtrig, incr, jcrev (FAUST), nsmp, phaser, prop (!gest works better), randmt, random, reverse, sdelay, spa, sparec, tread, zitarev (FAUST)
2021-07-26 20:31:18: loosely glancing at the soundpipe folder the ones that stick out are: pinknoise, brown, talkbox, verbity, lpc.
2021-07-26 20:29:12: FAUST-derived stuff is not getting ported, unless I can reverse engineer them (but I do not intend to). some of my old stuff is a bit silly and not worth keeping. When you factor those out, there's very little that will remain as "code only".
make a boilerplate function that frees cables and frees data for nodes
UUID: #a8b39cbf.
the destroy function in patchwerk is used so frequently that it would be worth creating a wrapper around it. Also, maybe memory allocation stuff as well?
create bitcrush algo
UUID: #f2945ac3.
the current soundpipe module is broken and not worth repair (totalled). it would be better to build another one from scratch.
2021-03-30 22:01:20: should downsampling be a normalized value so that it can be sample-rate independant? I'm going to say no for now because the soundpipe bitcrush wasn't.
2021-03-30 21:59:02: yeah. I think that makes sense. bit depth all comes down to reducing noise floor. and noise floor happens as you strip away bits that are LSB. it was just a bit counter-intuitive for me for some reason.
2021-03-30 21:56:52: bit reduction can be done with a shift I think? but is it really about losing LSBs?
2021-03-30 21:53:58: downsampling is done via a sample and hold. the counter can be managed using a phasor. aliasing is desired.
2021-03-30 21:51:29: a bitcrusher actually does two things: it truncates the bit depth, and it downsamples. Both are done in an intentionally crude way.
add error codes to sndkit core
UUID: #317b788d.
it is going to be difficult to know what goes wrong when things go wrong. adding specific error codes with canned messages will make life easier.
cflooper
UUID: #a1e9dfbb.
a cross-fade looping sampler with adjustable crossfade times and pitch control.
2022-03-14 09:21:11: holding off for now. looped pad sounds just aren't all that important to me right now, plus I already have a way to do it in one go.
2022-03-07 09:07:27: I recently tried to do a crossfade delay line, so I've been thinking about crossfades. That effort failed, but maybe there are some insights here.
2021-01-31 10:59:19: If I can't figure out continuous adjustment, having something that dynamically produces a crossfade at run-time is good enough I guess. Since I added (crate), I've been able to mess around with samples before and being able to turn any sound into a seamless texture is exciting to me.
2021-01-31 10:57:38: I already have a static crossfade loop generator (cfloop). I want this one to have seamlessly adjustable crossfade looping abilities. Being able to do that continuously without clicks is what is interesting to me. I'm sure there may be a clever way to do this, I just haven't figured it out.
FM4
UUID: #76f74cad.
a 4 operator FM voice designed to be highly flexible.
2023-03-31 06:04:30: WIP in gmorphfm. The routing algorithms need to be implemented, but after that it should be in a "done" state.
2021-07-23 20:24:51: pushing this aside for a while I guess.
2021-02-12 09:40:03: I want this FM oscillator to be keep me interested for a while. Each operator should be able to take in wavetables of arbitrary size. I should also be able to morph between an arbitrary set of wavetables, possibly with arbitray sizes. Feedback control will be a global knob. Since I want different configurations, it seems like any other solution would be too messy.
port plateau DSP to patchwerk node
UUID: #b24e17bf.
see playground/plateau for more deets. the idea is to get the original C++ running, then to make a version of it in ANSI C later.
2023-03-31 06:08:51: this would be something I'd drop into mnodes now
valp4
UUID: #48eecf9c.
valp4 is a Virtual-Analogue Low-Pass 4-pole filter
2022-04-06 13:57:11: not really doing much subtractive synthesis, though it is a cool filter to have around. I'm afraid this is low priority now.
2022-03-09 08:52:04: the filter I believe that is going to be ported here is the Diode Ladder filter, described at the end of chater 5 of the art of VA filter design. Section 5.10, pg 164 (PDF page 176).
2021-07-23 20:35:37: this feels less pressing to me, so I'm removing it from the list. wavetables and FM and phase distortion is more interesting to me anyways.
2021-07-05 12:17:33: I also want to consult Zavalishin again, and try to see if I can grok the TPT stuff. I seem to recall things making sense at one point for valp1. Hopefully I can understand things again, and keep it long enough in my head to write it down!
2021-07-05 12:13:48: it seems nonmateria has done the heavy lifting of porting Pirkle's C++ code to C: https://codeberg.org/nonmateria/folderkit/src/branch/main/src/dsp/va_filter.c. I may end up turning this into a more generic
vafiltthat can be configured for different filter types, similar to how blep is configured for different waveforms.2021-03-02 14:00:28: this needs to be examined more closely. similar to growl or bigverb, this has a lot of underlying components.
2021-02-12 09:19:23: I wrote a comment about this, but on the wrong task. will pirkle has a C++ implementation that is worth examining. It is from the same Art of VA filter design book. My version would ported to ANSI C, and of course would give credit to Pirkle.
paulstretch
UUID: #4482dab5.
an implementation of the famous paulstretch algorithm. this code already exists in soundpipe, it just needs to be rewritten as a literate program.
2022-03-13 10:28:39: to speed things along, I am making a paulstretch branch with a boilerplate org file
add slightly better error handling to core api
UUID: #4535c004.
that is to say, make sure things don't continue if an error happens. right now no error checking is happening, even though errors could be returned. will be especially important when cables and tables are introduced.