ideas:

• this is a take off on loopcollector
• constantly record from as many inputs as possible. each channel is independent, i.e. stereo input creates two sets of samples
• assemble predefined rhythm tracks using pieces. once again each track is independent. stereo inputs create two sets of buckets that are filled separately and played back together. mono tracks create two identical buckets. more than two channels = mixdown to stereo
• how do we do this? take a recording. split it into X frequency bands. split each band into N notes (configurable per file).
• do the same with incoming audio (length of a beat is whatever you want).
• when reassembling audio, stop taking pieces into each of the original loop's buckets when it's full
• once a track is completely filled, queue incoming samples. drop oldest sample when a set of new samples would be as loud
• there needs to be a gate on samples that are accepted
• app will need a file that describes each input track (number of measures, file format, # channels can be discovered)
• choosing next track to playback is at random. choosing next track whose buckets to fill is also random
• analysis only needs to be done once and results can be saved
• RMS values for all
• i sort of want to use this as an instrument, i need some MIDI things for timing purposes

go language-wise seems well suited for a file based non realtime version this project, primarily because of goroutines.

• for audio file i/o, i will need to use either cgo to call out to libsox or pipes to do ipc. ipc is probably easier but requires reading the file many times.
• for signal processing i am left with my own hacky stuff
• maybe make a wrapper for the dft_filter functions that copy output to a second buffer?

pd may work. super collider too. nsound. impromptu. check out capabilities of all of them.

in fact, i think i need to split this into two parts.

the analyzer will work on input audio files, and spit out descriptor files. MAYBE work on audio files

something else will consume them. file based stuff in go.

sc class to read json file and present X outputs of bands √

now i guess i need to create code to: a.) allocate bands (max beats 2) 2-channel buffers in two sets: active and filling. set this number in server options and reboot server at start. b.) create one synthdef to play all set of active buffers (for a band?) in order c.) another to read input and fill buffers d.) poll to see if buffers are full. I guess I can use a bufrd for this or will i need a custom ugen? e.) when filling buffers are full, switch targets of synths, clear formerly active buffers and start filling with randomly selected new input track

i think i need to schedule the play and record actions from sclang.

a thought: instead of scheduling new synth creation on every beat, have a doneAction of 0 and modulate the buffer number? same with playbufs

need to start go section over. refactoring has made things even less understandable. analyzer is probably ok.

producer needs to accept a list of files instead of recording from interface.

currently too tired to understand what to do