Composers Desktop Project Forum

Just wanted to clarify here that this project has been suspended indefinitely, unfortunately. I got a bit too ambitious with it and got the code into a state where I wasn't able to proceed further. Of course I could go back in the Git history and restart from an earlier point, but the bigger changes I did were something I really wanted working anyway...

You would need to write a script that deletes the intermediate files.

Have you tried the Renoise forums? I would guess many people here are not Renoise users.

edit : You might also want to try running the CDP programs directly on the command line, to see if your installation of CDP is working and/or that your input files are compatible. (For example many of the CDP programs only work with mono files. I don't know if the Renoise tool attempts to work around that in some manner...Renoise is also completely incompatible with channel counts above stereo.)

I don't think that is going to work.

Quote from: afta8 on January 03, 2017, 11:14:57 AM
Sweet!!!

Have you resolved the issue with accessing audio data? On Renoise the processing speed once the data is in the Lua side is quite fast, I don't think it uses LuaJit either, I run it on 64bit Mac Osx, I think the implementation is using LuaBind.. not sure if that makes a difference..

The speed seems fairly decent even with per-sample accesses. (In the gif animation it generates 10 seconds of 4 channel audio in about 0.3 seconds, so about 30x real time and probably a bit faster too if the overhead of creating the buffer and writing it to disk wouldn't be taken into account.)

However, I suppose for a scripting environment it would be useful in any case to have a bit higher level operations available. So instead of multiplying or adding samples etc one by one, one would have functions like :

buf:multiplyRegionBy(startChan,endChan,startSample,endSample,gainFactor)
buf:addFrom(bufToAddFrom, startChan, endChan, startSample, endSample, gainFactor)
buf:applyEnvelope(startChan,endChan, {{0,0.0},{44100.0,1.0},{88200,0.0}})

(Those are just imaginary examples, the actual API would need to be designed more carefully.)

I did also add the disk file access into the scripted DSP node, but I think that should also do resampling of the audio into a target sample rate, so that the scripts don't need to bother dealing with that for simple use cases. (At the moment I just did a simple wrapping of the JUCE MemoryMappedAudioFormatReader.)

As suggested by afta8, preliminary Lua script based DSP node...(At the moment good only for generating audio, but accessing audio files will be added shortly.)

Quote from: afta8 on December 25, 2016, 12:48:30 PM
Do you need any beta testers?

I'm presuming you have lua embedded in this now? If so, then it would be super cool if you enabled some kind of 'roll your own effects' feature.

Sure, beta testing will be needed once it is in a reasonably good shape. I just recently started working on a state history (aka undo history) feature which is a bit complicated one to do and has required changing some things that will need quite a bit more work to ensure they work properly...

Lua scripting has been incorporated into various things already. I have been thinking about doing the Lua audio data access thing too, but it might be a bit slow to access audio data on a per sample basis from Lua. (λ uses the official Lua C implementation, via the Sol2 C++ library. If LuaJIT still doesn't work on 64 bit macOS, it unfortunately isn't an option for me to use...)

Perhaps a compromise could be to allow doing higher order operations from Lua script code. For example, allow building DSP graphs from nodes like gain changers, panners, filters, delays etc...Also snippets of audio material from files could be scheduled for playing with various properties. (This actually is partially implemented in the Montage node already...I haven't tested what are the practical limits for the number/density of sound events in that though.)

Quote from: rwdobson on December 21, 2016, 02:23:12 PM
Get it in the usual way by cloning a new repository
Building for Windows requires the Mingw command line environment with gcc etc.

Thanks! 

Interestingly, I was able to build some of the programs on Windows in Visual Studio 2017 from the source code that was previously available. (Even with the concrete profit that the PVOC programs run faster than the official MinGw builds!) I have to test these new sources for what is going to happen...

Since SoundCloud allows adding comments on the timeline, do you think you could add comments on what source sounds and CDP processes were used during the piece at each moment? That might be educationally useful.

Finally some videos with sound too :

http://youtu.be/hb-i3KUEO5Y

http://youtu.be/bTv_k7F7GQY

These don't yet showcase the CDP programs (apart from Modify Radical Reverse  ) , but I'll make a 3rd video soon where I will show more of the CDP stuff.

edit : CDP program demos video :

https://www.youtube.com/watch?v=RsmHBJ02HE8

Still working on it. The scope of the application has increased quite a bit...It obviously needed for example a way to mix sounds together, but I felt the CDP facilities were a bit limited and clumsy to use. So I've worked on a basic multilane/track audio editing thing too...



The frontend does also to some extent support the old school CDP mix files and submix programs but I think most effort will go into making the new "mixer sequencer". (It will also have text/script based ways to create and manipulate the mix events besides the GUI/mouse style editing.)

Quote from: simonk on November 02, 2016, 02:18:05 PM

Sorry for the delay,latest 7.1 source zip here

http://unstablesound.net/downloads/CDPrelease71src.zip

Thanks, appreciated!

Quote from: simonk on October 30, 2016, 08:20:37 AM
I'll give Richard a nudge

If setting up the GitHub repo is too involved for him at the moment, how about just packing the current up to date source code into an archive file and post that somewhere?

I am interested in the source code so I could build the CDP programs with the compilers of my choosing and have some changes integrated I've done on the source code. At the moment this is not so nice, because the available source code still has the sound file format handling bugs .

Any news on the source code release?

Quote from: Robert Fraser on October 21, 2016, 11:46:00 AM
As far as I know, modify loudness 4 is the correct command. For example, -l0.707946 will give -3dB output, whether the input is lower or higher than this (just tested both).

I think Logan means that the program will produce an error if it happens that the level will be exactly the same. This is a slight problem for tools/frontends which would then need to avoid using parameters which don't make a change into the input sound, as some of the CDP programs are so eager to detect that situation. I suppose there are not any other solutions for this currently than changing the CDP programs source code to bypass these "it will be the same sound" checks or hacking some special cases into the programs that use the CDP programs.