First, I would like to express my thanks to the Renoise team, afta8 and Emre. Renoise is a great piece of software that allows everyone, even the ones who are on linux or who don’t own a powerful computer, to make great music from a to z. The CDP lua tool sounds to be an incredible tool and I have read Emre’s articles with interest – a lot of creative ideas in there.
I got the “An output file was not produced – check your settings” message.
I’m from the linux world, but I must use my girlfriend’s computer for now, which runs windows sadly, so when I got the message, I could only see the verbose output for a fraction of a second, without knowing where to find it after its disappearance. The only way I found to see it was to take a screenshot… for shame !
Here it is though. Even worse, it is in french, and I can’t read everything. But it says something like “‘C:\Users\Claudine\Documents\Renoise\User’ is not recognised as an intern or extern command line, as an executable or as a command file.”
My feeling is that I put the CDP executables in the User Library\CDP folder, but for some strange reason, the tool cannot seem to read the space between User and Library and therefore cannot get the complete path to the executables.
I moved the executables directly in the Renoise folder and the problem was solved. I don’t know if there is a way to solve this bug, but I thought it might be useful to inform you.
While v2 of this tool is still cooking, I’ve managed to build an envelope editor native to the tool GUI. I’ve integrated this into the current tool so here’s v0.68:
It’s all vb objects, the trick is to use negative spacing values in vb columns/rows, this lets you overlap things and create layers, it’s then fairly straightforward to use vb buttons as objects/pixels. Mouse tracking is done by a x/y pad hidden underneath it all… It was a bit of a happy accident that led to this, but the technique can be used for more than an envelope editor. I’ll post it as a separate library soon, it’s fairly easy to plug and play
Process with more than 1 breakpoint env Distort Repeat for instance. I make one breakpoint envelope (for multiplier param) and then i push button make another one for cycle length and i get a same breakpoint. I make changes here and go to edit previous breakpoint and get the same edited breakpoint.
Process with more than 1 breakpoint env Distort Repeat for instance. I make one breakpoint envelope (for multiplier param) and then i push button make another one for cycle length and i get a same breakpoint. I make changes here and go to edit previous breakpoint and get the same edited breakpoint.
The last breakpoint envelope used is remembered right now and that is a feature , but it can be confusing indeed, maybe not as you’d expect/want in certain cases. Instances where you want to try out variations / a slightly adjusted shape. You are aware that you first have to close the breakout envelope window, than press the envelope icon of the new parameter you’d like to control?
Anyways yeah it seems really confusing that after editing brkpnt#2 i open brkpnt#1 and see brkpnt#2’s envelope still.
The best way to think of the current approach is that the envelope editor is process independent, hence why there is an ‘Apply’ button. You set the envelope up and then apply it to that parameter… Under the hood, the tool then generates a text breakpoint file for that parameter.
I will look into a fix for this, maybe recall the envelope for the specific parameter if it has been set up already.
I haven’t looked in here for a while. Wow, some great work is going on, V2 looks fantastic, can’t wait to check it out, and I’m looking forward to using the new breakpoint editor. Many thanks to everyone who’s worked on this project !
Hell yeah, any progress on the new tool version? Looks like some really grand mayor pushup to the whole concept, can’t wait to try it out.
Also I found that trying to compile CDP (the newer beta) on Ubuntu 16.04 still has the libm linking problem leading to only about 40 instead of 147 executables in the release folder. It still can be fixed the same way like I described in the thread before, changing the makefiles in the “cdparams”, “standalone” and “new” subfolders.
I created a diff/patch for this for fellow linuxers here and so I don’t loose it myself & others get it done easier. Copy the diff file to the folder where you have the sources in, and execute “patch -p1 < CDP_Libmfix.diff”. Before any compiling.
EDIT - the forum won’t let me upload .diff files, so I appended a “.txt” to the file, and then it worked…how pathetic…
Hell yeah, any progress on the new tool version? Looks like some really grand mayor pushup to the whole concept, can’t wait to try it out.
Not much activity over xmas & NY but getting back on it, maybe also of interest is another frontend being developed by Xenakios (some details here:http://www.kvraudio.com/forum/viewtopic.php?f=6&t=446446&start=105),)it uses the process definitions from this tool as well! either way good times coming up for CDP users
Also I found that trying to compile CDP (the newer beta) on Ubuntu 16.04 still has the libm linking problem leading to only about 40 instead of 147 executables in the release folder. It still can be fixed the same way like I described in the thread before, changing the makefiles in the “cdparams”, “standalone” and “new” subfolders.
Good to hear you are still planning to go on with it.
And the site requires registering, and the contact page is dead link. Heh.
Well, I need no help with it, I know what is going wrong. Thus I was able to fix it, and my patch does just this. The order of libs in the binary linking stage is “messed up”, and since some gcc version from a few years ago it is obligatory to have them right to left in the order they might link with each other. Whatever fukwit moron decided to make it fixed in this nitpicky way, because before the order didn’t matter and would compile just fine unless there was a backlinking loop in it.
Belive me, cdp is not the only project affected by unnessecary breakage. So old gcc versions will compile it just fine, newer (well, not so new, it is quite some time since this was changed…) will bail out and not compile many of the programs. Maybe some people don’t notice, because they are using professional very long term support distributions that freeze versions of programs (also gcc) to known good states.
It should be of interest to the cdp linux maintainer, but I just write it here because it might be of interest for people here to get CDP running on linux with your tool, or help other people to make it work.
Thank you for building this tool. As yet, I have been unable to enjoy it and I am wondering if I have found a bug or am simply facing my lack of knowledge with these things.
I followed all the steps and didn’t encounter any problems.
I have many different errors with the CDP tool in Renoise, but wanted to highlight one where I was able to get a successful output in the terminal, but was unsuccessful in the CDP tool.
In the terminal :
~/Binaries/CDP/Release$ ./distort reform 1 $HOME/cdptest/radtool.wav $HOME/cdptest/radtooldistort.wav
0 min 57.00 sec
I don’t see any outputs selected in the CDP tool’s gui.
Once you open up the tool gui, the input & output selectors should be auto-populated with the currently selected sample in the instrument list. Try running it again on a selected sample.
Hi, you’re almost there. The tool won’t auto-create new samples for the results, so you have to select an existing sample for the output.
Create an empty sample (name it to be able to see more clearly in the tool), and select the instrument and the sample in the two “output” boxes. You can also select the original instrument/sample as output, it will then be overwritten by the result.