CDP Interface for Renoise

[afta8]

This has been under development for over a year now by me and Djeroek and I have just published it to the Renoise Tools page.
The tool and it's installation guide are available here: http://www.renoise.com/tools/cdp-interface



The tool allows you to use Renoise as a general CDP front end and workspace, this makes it quite easy to rapidly experiment with sounds and then sequence them into song arrangements.
Renoise comes with a built in sample editor and sampler so combined with this tool and CDP it becomes a sound design powerhouse. Renoise is also cross platform running on Mac, Windows and Linux. The free demo version of Renoise will work with this tool without restriction.

Key features

• A total of 829 CDP process supported
• Automatic conversion of Stereo/Mono samples for processes that only work in Stereo/Mono
• Automatic conversion of WAV/ANA inputs and outputs for PVOC processes
• Automatic conversions of input Samples to FRQ for GetPitch processes
• Built in text editor (with Load/Save) for parameters that require text inputs
• Import, edit and scale breakpoints (with Load/Save) from Renoise envelope editors
• Process descriptions and tooltips for parameters
• Terminal output displayed in Renoise to help troubleshoot processes

That's all for now, I hope some of you find this useful.

Cheers

[lynx]

May I applaud you for your incredible efforts to support CDP in Renoise?  Bravo!!

[Xenakios]

Afta8, an incredible amount of work that I have to congratulate you for!

Unfortunately this is something I won't get to use myself since Renoise is a host program that just isn't a good "fit" for me. (I've tried it, couldn't make it do pretty much any of the stuff I am used to, and forgot about it.) This is why I've done the work on my CDP frontends in a way that also allows building them as stand alone applications too. I know that Reaper isn't a "good fit" for many people either. (There was never a standalone application release of the recent CDP frontend though. The build is still possible to do and works somewhat but went into a bit of a neglected state because I have myself preferred working with the frontend in Reaper, so the development efforts went Reaper-centric. The newer frontend will follow a more strict development model where the standalone application build will not get behind or be unreleased.)

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...

[davephillips]

... I've done the work on my CDP frontends in a way that also allows building them as stand alone applications too. I know that Reaper isn't a "good fit" for many people either. (There was never a standalone application release of the recent CDP frontend though. The build is still possible to do and works somewhat but went into a bit of a neglected state because I have myself preferred working with the frontend in Reaper, so the development efforts went Reaper-centric. The newer frontend will follow a more strict development model where the standalone application build will not get behind or be unreleased.)

So it *is* possible to build your code as a standalone ? I tried it some time ago, got no joy building it for Linux, but I'd love to take another shot at it. Is there an updated code base I can check out ?

Best,

dp

[Xenakios]

So it *is* possible to build your code as a standalone ? I tried it some time ago, got no joy building it for Linux, but I'd love to take another shot at it. Is there an updated code base I can check out ?

Best,

dp

The standalone build works (partially) only for Windows. I didn't get it to run on OS-X (just crashes at start) which was the reason I didn't publicly distribute the standalone application build. The source code hasn't been changed to build correctly for Linux yet. But I suppose I could take a quick look at that. (I now also have a Linux system with Juce and its dependencies installed. It's a horrible computer though that takes a long time to compile C++ code.)

[davephillips]

The standalone build works (partially) only for Windows. I didn't get it to run on OS-X (just crashes at start) which was the reason I didn't publicly distribute the standalone application build. The source code hasn't been changed to build correctly for Linux yet. But I suppose I could take a quick look at that. (I now also have a Linux system with Juce and its dependencies installed. It's a horrible computer though that takes a long time to compile C++ code.)

Bring it on, I'm available for testing any code for a Linux standalone.

And thanks for helping to bring the CDP software to a larger base of users !

Best,

dp

[Xenakios]

Anyway, let's not derail this thread too much from the original topic which is Afta8's CDP frontend for Renoise.

[afta8]

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:

Code Select Expand


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

[Xenakios]

I didn't realize Djeroek also worked on this! He sure has done an insane amount of work on the definitions.lua file!

I am in the process of trying to convert that file to C++ code...Automated, of course. I've made some progress. The resulting autogenerated .cpp file is already a tough nut for the compiler. I am afraid I will have to come up with some way to split this into several files. Just the generated code for a factory function that deals only with the CDP program descriptions and executable names required turning on the /bigobj switch and recompiles are not fun to do as they take so much time. I will have to see what more I can get out of this.

edit : I made the C++ code generation make 9 .cpp files, which can also be compiled multithreaded, so it's not taking so long to recompile. There are some irregularities in the Lua tables that will require some thinking on how to best convert to C++ code that will compile and work properly...

[Xenakios]

Trying to convert the Lua code into C++ started looking too messy, so I am now looking into making a C++ program that has Lua embedded and would read/use the definitions.lua file directly.

[afta8]

Yeah Djeroek has done an amazing job on compiling the definitions, really this tool wouldn't exist without his input.

Trying to convert the Lua code into C++ started looking too messy, so I am now looking into making a C++ program that has Lua embedded and would read/use the definitions.lua file directly.

Neat! This is quite a good idea.

For some processes the range settings aren't always right as they are based on the docs, these are fixed as they are found for newer releases. Does that mean if the definitions file is updated for the renoise tool it will be compatible with your tool as well?

Anyway, really looking forward to see what you do with it

Edit: There are a number of processes definitions that are commented out as they mostly have MultiChannel outputs. The Renoise tool doesn't yet support them so they are commented out. You should be able to trace them by searching the code for comment blocks.

[Xenakios]

Yeah Djeroek has done an amazing job on compiling the definitions, really this tool wouldn't exist without his input.

Trying to convert the Lua code into C++ started looking too messy, so I am now looking into making a C++ program that has Lua embedded and would read/use the definitions.lua file directly.

Neat! This is quite a good idea.

For some processes the range settings aren't always right as they are based on the docs, these are fixed as they are found for newer releases. Does that mean if the definitions file is updated for the renoise tool it will be compatible with your tool as well?

Anyway, really looking forward to see what you do with it

Edit: There are a number of processes definitions that are commented out as they mostly have MultiChannel outputs. The Renoise tool doesn't yet support them so they are commented out. You should be able to trace them by searching the code for comment blocks.

Yeah I am hoping I can use the definitions.lua file more or less as it is, so if it is updated it will still work. So far I have been able to use an unedited version of the current one. The C++ code is almost ready to be plugged into the GUI frontend code, until now it's been just a command line program to test the Lua C API and so on.

With my own frontend developments too, it sure has been a frustrating problem how the CDP program parameter ranges mentioned in the documentation don't always seem to be correct, resulting in the programs not completing their runs successfully and even crashing in some cases. Hopefully eventually the correct input parameter ranges/values can be mirrored in the frontends without having to study the actual C source codes of the CDP programs too much.

It's a bummer the multichannel programs wouldn't work in Renoise. (Is it a limitation in Renoise or your code...?) I have myself been working a lot with multichannel audio lately. I wonder if the data format could include a flag for the CDP program being multichannel instead of having the description commented out?

edit2 : The GUI frontend can now enumerate and filter the Lua defined CDP programs!

[afta8]

Yeah I am hoping I can use the definitions.lua file more or less as it is, so if it is updated it will still work. So far I have been able to use an unedited version of the current one. The C++ code is almost ready to be plugged into the GUI frontend code, until now it's been just a command line program to test the Lua C API and so on.

With my own frontend developments too, it sure has been a frustrating problem how the CDP program parameter ranges mentioned in the documentation don't always seem to be correct, resulting in the programs not completing their runs successfully and even crashing in some cases. Hopefully eventually the correct input parameter ranges/values can be mirrored in the frontends without having to study the actual C source codes of the CDP programs too much.

It's a bummer the multichannel programs wouldn't work in Renoise. (Is it a limitation in Renoise or your code...?) I have myself been working a lot with multichannel audio lately. I wonder if the data format could include a flag for the CDP program being multichannel instead of having the description commented out?

Yes the terminal output view has been quite useful for resolving incorrect parameter ranges, one thing I have noticed for some processes is that the range depends on some other slider settings, particularly with Pvoc process, the points setting can affect the range of some process sliders. As you say one way is to analyse the code for how these work or alternatively have some way to catch the errors or display the terminal error message for the process which usually tells you what the correct range should be.

With multichannel, it on the todo list, renoise doesn't support multichannel audio files so some splitting will be needed to put the different channels into stereo samples. I will however look at how to define multichannel processes in the definitions rather than commenting them out.

GUI looking good so far though! I like it

[Xenakios]

Creating processing nodes and creating parameters now works to some degree. Soon off to trying out actually running the CDP programs...

[djeroek]

Oh snap, what's this!? Behind the scenes development of v2?

The gui in the screenshot is incomplete, but a teaser;
cdp teaser by Hiek A Matiek, on Flickr