Composers Desktop Project Forum

Afta8, an incredible amount of work that I have to congratulate you for!

Unfortunately this is something I won't get to use myself since Renoise is a host program that just isn't a good "fit" for me. (I've tried it, couldn't make it do pretty much any of the stuff I am used to, and forgot about it.) This is why I've done the work on my CDP frontends in a way that also allows building them as stand alone applications too. I know that Reaper isn't a "good fit" for many people either. (There was never a standalone application release of the recent CDP frontend though. The build is still possible to do and works somewhat but went into a bit of a neglected state because I have myself preferred working with the frontend in Reaper, so the development efforts went Reaper-centric. The newer frontend will follow a more strict development model where the standalone application build will not get behind or be unreleased.)

How much reusable code is in the Renoise frontend? Or is it very Renoise-centric? Just thinking about possibilities here if any of the hard work you've done could be ported over to something that doesn't require using Renoise...

It sadly looks like the CDP developers have vanished from the face of the earth.  The only update I am aware of since the initial open source release since last year is the audio file formats fix for the pvoc, and the new source code for that was never made available.

Any chance the updated source codes could be made available?

Many of the programs do multiple passes over either the input or the output., for such things as maximum amplitude computation and normalisation; these will convert either with great difficulty or not at all to a real-time streaming environment. This includes for example the granular synthesis/brassage programs.

You may be overcomplicating this. Sure, it will be hard or impossible to make such things work for strictly live real time inputs. However, it would be possible to make the programs access pre-existing material in a random access manner from memory buffers or files. This could be accomplished by requiring the user to "record" the desired material into such a buffer or file first. Not always ideal, but a possible approach. (For example the GRM Tools Freeze plugin works this way, as does the non-ARA version of Celemony Melodyne.) Pre-existing files could also be imported via file dialogs/browsers.

Plugins and plugin hosts/DAWs usually allow playing back audio even without an input file playing at the same time on a track. Technologies also exist in some DAW applications that allow 3rd party plugins/extensions to access audio files in the host in a random access manner.

Experimenting with some extreme set ups...

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.

It occurred to me that maybe the reason for the pvoc program being somewhat slow is because of its extreme amount of text output it produces...I realized this now that I tried running pvoc anal with a "long" input file (about 6 minutes) via the JUCE C++ library's ChildProcess. I already had to change that code in JUCE's Windows implementation to have more buffering for the process's text output. But now I ran into a situation where I had to increase the buffer amount even more.

Perhaps it could be a good idea to produce less progress text output while pvoc runs...?