Composers Desktop Project Forum
Composition => Showcase => Topic started by: Xenakios on February 16, 2015, 09:53:03 AM
-
I got quite frustrated with some aspects of the CDP frontend I have been working on, and decided to look at doing things from scratch. After a few days of work I've progressed quite nicely! I was able to come with a node graph based approach that allows quite cleanly to connect CDP programs together to form complex webs of processing. This will require a bit more work to become usable for the general public but perhaps a first test build might appear before too long. (Notably editing the CDP program parameters is currently very primitive, and no support for time varying parameters exists...)
(http://i.imgur.com/HMsTG33.gif)
-
Wow, looks amazing, this could well be the perfect kind of interface for CDP.
Is this Reaper only?
-
Wow, looks amazing, this could well be the perfect kind of interface for CDP.
Is this Reaper only?
The plan is to have builds of this that work both as standalone app and a Reaper plugin. The previous frontend also could be built as a standalone application but I didn't manage to make it work on OS-X, so I didn't publicly post builds of the standalone app. This new frontend now also has a working OS-X standalone application build since last night. (No Reaper plugin build exists yet, as it's kind of early days with this new software now. Adding the Reaper plugin mode will be relatively easy later, though.) I can't say a definitive date when this new frontend might be available for public testing, but perhaps during March isn't too inaccurate.
-
Fabulous !
Looking forward to this Xenakios.
I haven't had a load of CDP time recently, but did make a few really nice transformations with the previous Reaper plugin .
I particularly like the 'in place' function. The ability to drop the transformed file at the current point in the timeline (& on a new track etc) is a great compositional tool.
-
The plan is to have builds of this that work both as standalone app and a Reaper plugin. The previous frontend also could be built as a standalone application but I didn't manage to make it work on OS-X, so I didn't publicly post builds of the standalone app. This new frontend now also has a working OS-X standalone application build since last night. (No Reaper plugin build exists yet, as it's kind of early days with this new software now. Adding the Reaper plugin mode will be relatively easy later, though.) I can't say a definitive date when this new frontend might be available for public testing, but perhaps during March isn't too inaccurate.
Nice! an OSx standalone would be great..
Bonus points to you if in CDP tradition it could be launched and supplied with sounds via the command line too ;)
-
Experimenting with some extreme set ups... ;)
(http://i.imgur.com/wepD8Ba.gif)
-
Very nice! Please also consider standalone windows build 8)
-
Very nice! Please also consider standalone windows build 8)
Yeah I've been building it so far just as a standalone for both Windows and OS-X. I've been distracted with other stuff lately and will be until the end of this month...But I'll get back to this during April.
-
Wonderful idea and work Xenakios !! :D
[also a pc user hoping to get to try it]
-
I unfortunately got a bit stuck with this(*) and haven't worked on it lately. The plan is to continue with working on it, though. It did get to a quite interesting stage, after all.
(*) For example, I couldn't quite figure out the ideal way to implement the time varying parameter envelopes for this. I didn't want to do the most obvious thing and designing and implementing something more comprehensive turned out to be more involved than expected.
-
Xenakios, that really looks mindblowing. Looking forward to a Win standalone version!
-
I just unearthed this and again remembered how nice this could be if only developed a little further... :)
However, I also got to experience again how damn finicky about their parameters and how unstable the CDP programs can be. >:( It's very frustrating when a CDP program just keeps on giving errors or even crashing. A GUI frontend would need to be aware of these things and attempt to prevent the user from giving inputs that won't work. And that would require rewriting the logic that's already in the CDP programs but which can't easily be reused by a GUI front end. Sigh... :(
-
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.
(http://i.imgur.com/4JUbmMp.gif)
-
Looking good indeed!
-
Incredible, Xenakios! Really looking forward to this.
-
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.
-
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?
-
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.
-
Alright, makes sense. I was glad to hear you're using JUCE, I'll be ready to poke at it whenever you decide to put it out.
-
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.
-
Been making very good progress with this lately. A public beta might be possible soon... 8)
-
Good news!
-
Agreed, looking forward to this landing
-
Still needs some tweaks before a public release. Might take a bit more time because I am also working on a new composition currently...
-
Still working on this...
The source code repository is located at :
https://bitbucket.org/xenakios/cdp-front-end-mark-ii/commits/all
At the moment cloning/downloading the source code is not going to be very useful. Visual Studio and XCode projects are not yet in the repo and the .jucer file doesn't generate working projects either. I am still considering what I will do with the files needed for building the application. And of course endlessly procrastinating on giving out the ready to use binaries for the public...
-
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... ???
(http://i.imgur.com/HvWKGoU.gif)
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.)
-
Coo, what a tease!
-
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 :D ) , 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
-
Looking very usable. As always, looking forward to checking it out. Especially the vst support... I'll have to start adding that to my own project when I have the chance.
-
This looks amazing! Especially now you are looking at hourglass integration.
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. Once you have the sample data in a lua table it's quite easy to code custom effects in lua. I have this planned for the Renoise tool and have adapted bits of DSP code into lua, right now I have a biquad filter and various distortions.. also more stuff could be adapted from protoplug (http://www.osar.fr/protoplug/)..
-
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.)
-
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.)
(http://i.imgur.com/eLLluzv.gif)
-
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..
-
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.)
-
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...