Thanks for the feedback everyone, it has been a lot of fun putting this together and an equal amount of credit needs to go to Djeroek from the Renoise Forums for all his work on compiling the process definitions (i'll explain further below)
How much reusable code is in the Renoise frontend? Or is it very Renoise-centric? Just thinking about possibilities here if any of the hard work you've done could be ported over to something that doesn't require using Renoise...
I think a fair bit of it could be re-used, under the hood you have two sides to this tool, you have the code that builds the GUI, does the sample handling and puts together the terminal commands etc.
And then you have a definitions file that codifies all the CDP processes into a standard data format (using Lua tables), here's an example:
dsp["Tunevary - Replace spectral frequencies with the harmonics of specified pitch(es), uses pitch template text file"] = {
cmds = { exe = "tunevary", mode = "tunevary", tip = "This complementary spectral program builds on and combines aspects of PITCH TUNE and FILTER VARIBANK. Thus it can tune a spectrum to the specified pitches (given that those pitches are in the analysis file, otherwise, it skips or approximates them), AND it can do so in a time-varying way. Thus the pitch template file also contains times. TUNEVARY can therefore be seen as an extension of PITCH TUNE." },
arg1 = { name = "Input", input = "ana", tip = "Select the input sound to the process" },
arg2 = { name = "Output", output = "ana", tip = "Select the output sound to the process" },
arg3 = { name = "pitch_template", input = "txt", tip = "textfile containing pitch data as a list of lines, each line containing a time followed by a (possibly fractional) MIDI pitch value(s)." },
arg4 = { name = "focus", switch = "-f", min = 0, max = 1, input = "brk", def = 1, tip = "determines the degree to which partial pitches are focused onto the template. Range: 0 to 1." },
arg5 = { name = "clarity", switch = "-c", min = 0, max = 1, input = "brk", def = 0, tip = "determines the degree to which non-template partials are suppressed. Range: 0 to 1" },
arg6 = { name = "trace", switch = "-t", min = 1, max = 12000, input = "brk", def = 512, tip = "specifies window-by-window the number of most prominent spectral channels to be replaced by the template pitches. (Range: 1 to number of channels)" },
arg7 = { name = "bcut", switch = "-b", min = 0, max = 22050, input = "brk", def = 50, tip = "instructs the program to ignore any pitches below bcut, the Bass cutoff frequency given in Hz." },
}
So briefly what you can see here are tables within tables, the 'cmds' table key contains details of the exe and its mode and the args1...argsN details the command line arguments.
What the tool does is read this 'definition' and build the GUI accordingly, it can see from 'arg1' the input files are 'ana' so it will do a PVOC conversion, the tool decides what GUI elements to build based on what is contained in the 'arg..' tables.
So I specified this format and started coding the main tool and meanwhile Djeroek (who collaborated on this with me) did the laborious task of going through the CDP docs and codifying all the processes in this format (he writes a bit more about it here:
https://www.facebook.com/hiekamatiek/posts/717818141606516:0)
The result is 10,000+ lines of code defining 830+ processes covering most of the CDP commands! While the GUI side is probably not that portable the data format for the CDP process definitions definitely is. I don't think it would be too much trouble to write a conversion script to convert it to whatever data format you want.
Anyway I would be happy to take you through it more detail and explain the ins and outs of the data format and the GUI building logic etc.. I really like the look of some of your reaper prototypes, particularly the node/graph approach, happy to help in any way really
