Composers Desktop Project Forum

I could use juce for the recording in that function but I'd rather not. Thoughts?

Why not? Implementing recording with Juce shouldn't be a big deal, maybe a few dozen lines of code assuming you already have the realtime audio stuff anyway for playback. If you need to add the realtime audio things first, that will require a few dozen lines of code.

The library implementation is what I want far more than anything else.

I think that's something that was merely hinted as a possibility that might eventually happen. I don't think the library implementations actually exist yet. It's now been over 2 years since the open sourcing of CDP and virtually no updates or news have emerged since.

In any case, I am a bit skeptical if running the CDP programs as library code would be a good idea anyway. Many of them seem to be quite buggy, so running them as in-process library code would likely in many cases just cause problems like crashes or memory leaks.

Well that's fantastic news because I am using C++ and I am using JUCE. This is the first thing I've used JUCE for and I didn't realize it had something built in for handling child processes... Really a huge relief as the windows api has indeed been a massive headache. Just managed to get pipes working but I am more than happy to tear it back down.

I can't imagine a more satisfying reply, I'll take that fix if you don't mind.

In the file juce_win32_Threads.cpp, there's the line :

if (CreatePipe (&readPipe, &writePipe, &securityAtts, 0)

If that is left like that, it may cause for example CDP's pvoc.exe to hang with long input files. Changing it to :

if (CreatePipe (&readPipe, &writePipe, &securityAtts, 1048576)

Should fix that problem. The number 1048576 is of course a bit arbitrary, it may be too big for most uses of the ChildProcess and may still be too small for some cases. But so far that has worked for me. (The number is the buffer size used by the pipe. The number 0 makes the buffer size be some undefined default size which doesn't play well with some of the CDP programs.)

This looks really interesting, I think the data flow approach is a good way to go. If you're planning to release this freely would you consider making a github repo of it?

It's been hosted in an open source repo (not in Github though) all this time but I haven't advertised that since I haven't wanted to give the impression it's something someone could just easily build and start using. It has problems like hardcoded file paths to my own filesystems, among other flaws.

Thanks to the work done by Afta8 and especially Djeroek on their Renoise front-end, my new front-end will potentially have over  800 of the CDP processes available! This will obviously need lots of additional work, but currently it's looking pretty good.

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

Quote from: Xenakios on October 22, 2015, 09:10:52 PM

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!

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