Composers Desktop Project Forum

Are the OS-X binaries actually up to date ones?

When running them, I get messages with :

QuoteCDP Release 7 2014

Quote from: loganmcbroom on August 01, 2016, 09:17:40 AM
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.

I worked a bit on it again and added VST2 plugins hosting to the front-end. I didn't yet fix any of the problems that make the front-end unusable on other computers than mine. Maybe I'll look into those issues some day. Shouldn't be more than a couple of hours of work. However, there are additional problems that would require much more work to fix.

Quote from: loganmcbroom on July 06, 2016, 12:31:10 AM
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.

Quote from: loganmcbroom on June 08, 2016, 07:30:53 AM
running scripts in threads, being able to start a cdp module without blocking the current thread

This probably isn't really needed. The new CDP frontend I worked on myself doesn't use threads for running the CDP programs but it yet can keep the GUI thread running and also leverage multicore CPUs for running in parallel. The trick is in letting the JUCE ChildProcesses run without waiting for them to finish in the current thread. You will need to keep the ChildProcess instances stored as member variables of some suitable class. (Or have them as global variables.) Then use Juce's timer to periodically check if the ChildProcess or processes have finished.

Quote from: loganmcbroom on June 02, 2016, 02:59:27 AM
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.)

The C++ frontends I've worked on, use the JUCE library, which indeed implements child processes with the help of pipes on Windows. There's by the way a problem in JUCE's implementation which makes the ChildProcess hang with some of the CDP programs. If you happen to be using C++ and decide to use JUCE too, I can give you the one liner fix. (The JUCE developer didn't consider this important enough to merge the fix into the official JUCE source code.)

In any case, you should really look into some cross platform library/framework that deals with this kind of stuff for you. Using the win32 API directly is a massive headache and obviously not cross platform either. I would recommend looking into Qt or JUCE. (JUCE is my current preferred choice, it also has a history of being widely used for audio applications/plugins.)

Quote from: loganmcbroom on May 23, 2016, 07:20:52 PM
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.

Sorry, no news about this yet, but working on this definitely is in my long term plans. Despite all the problems in the CDP programs, they still do have some processings that just are not available anywhere else. The frontend could also fairly easily be expanded to support newly written internally implemented audio processes as well as 3rd party plugins like VST and AU.

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.

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

Quote from: afta8 on October 23, 2015, 12:26:08 PM
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!

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.

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

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