beyond the basics

[misk]

Hey all, I've been inspired to install CDP, thanks to the game-changing renoise front-end by afta8 and djeroek. I love it, and it's inspired me to actually build my own shell scripts of repetitive processes, as well as look into how to get the cleanest possible results from each process.

I've noticed from reading the documentation that there are a few other environment variables besides CDP_SOUND_EXT, such as CDP_MEMORY_BBSIZE.

Are there other possible environment variables that can be specified? I really want to get the most I can out of this, and honestly the spectral morphing experiments i've made are blowing my mind. Sure it isn't real-time, but I'm getting transformations that remind me of Kyma (in terms of cleanliness).

I'd love if there was a thread on here where we could discuss tips, tricks, and personal favorite tools. I've experienced a major paradigm-shift since i've been working with these tools (all of a week or so). I see the concept of a 'sound' differently than I did. it's not just a sample anymore, but so much more hidden potential!

so lets talk about undocumented features, weird bugs, other environment variables, shell scripts, and other such nerdery!

[lynx]

Thanks for suggesting this thread.

I started with CDP on the PC, and took away a lot of useful lessons from Trevor's Sound Loom and Robert's Soundshaper.  Now running Linux full-time, I'm using the "beta" 64-bit sources of CDP with a few build tweaks to minimize dependencies under Slackware.  I miss the great PC GUIs, but I remain satisfied with CDP even "in the raw."  I have found the Tcl shell (tclsh) a useful front-end.  It allows direct command-line access to the CDP binaries (like any other shell), while remaining fully extensible (allowing me to write function wrappers for CDP processes as I go), and generally just saving some repetitive typing for cleaning up scratch files or specifying the names of sound or breakpoint files.  With more time, I could take it further, and write some basic Tk GUIs for making/editing breakpoint files or feeding notelists algorithmically without leaving the tclsh environment, but I've not gotten that far.  Fortunately, CDP is very forgiving to a "try it & hear it" interaction with the composer/user.

I'll admit I'm not well-versed with other shell environment parameters.  I suppose I probably should inspect the source code more closely to see what features remain "hidden" under the hood.  Also on my TODO . . .

As you say, the system is not "realtime," but I remain thoroughly blown away by what can be accomplished with the CDP tools.  It's most frustrating aspect for me is--at least from my present level of experience--the unpredictability of some processes.  However, the T-V aspect of so many process parameters offer such subtle & exacting level of control/manipulation, that I've generally come to favour the directness and simplicity of working with CDP (after all: it's just me, my DAC, and often a text editor!) over the use of my vastly more "sophisticated" (read: expensive, cumbersome, often proprietary) realtime instruments, especially when my goal is to yield something of more lasting consequence than just bashing away at the keyboards.  While CDP doesn't gratify the digits, CDP is my favourite instrument!

[misk]

interesting about the tc shell, most of my experience in nix is in plain old 'vanilla' bash, but working with cdp is motivation enough to check out other shells for the sake of potential automation features alone.

I completely understand where you're coming from with regards to proprietary instruments. when working with CDP, i find them to be corpulent and slowâ€"devoting too much of their processing power to allowing you to hear what you're actually doing. It's almost similar to writing music by ear on a piano vs. learning to sight-read enough to hear a (likely) potential outcome in your 'minds ear'. I'm not at the point where I can do that, but some processes are straight-forward enough that I have a good idea of where i'll be after executing a process.

Funny you should say that about the text editor! Lately it's been just me, sublime text, a terminal window, and renoiseâ€"the main benefit of renoise being the ability to have a buffer as a scratch track!

It's strange though to be talking to people on other forums about say, drum n bass production, and knowing that one could just as easily sculpt a sound with a few cdp processes as one could with a series of plugins in a DAW. I think the only thing that might excite me more is a max 7 front-end, just to have everything in one environment.

cdp reminds me of something like nethackâ€"it doesn't look as pretty, but there's still a depth to it that is unrivaled by anything else i've seen, regardless as how 'pretty' something else might seem.

[lynx]

Bash is pretty capable as shells go.  It's the default on most Linux-based systems, and has incorporated a lot of features that made other shells (e.g., ksh and zsh) once attractive.  From where I sit, I think there's not much advantage to using other common shells over bash (tclsh is really an interactive Tcl prompt, not so much a substitute for a proper shell), although I use to like ksh93 only because it tends to be cleaner and more consistent.  Often, specific functionality that is confining in bash (or any other shell) is better served by another utility.  CDP includes several utilities for manipulating tables of data, for example.  You could extend your capabilities here by writing awk scripts (or perl, if that's your thing) for these kinds of problems.  Note lists can be produced by almost anything (try generating random numbers in R, for example).  Pretty much whatever you're comfortable with is game.  I do miss the PC GUIs, though, and hope one of them makes it over to Linux before long.

As you say, realtime systems are often surprisingly "slow"!  On my desktop, CDP renders all but larger sounds almost instantly.  Sculpting a sound following an iterative trial & error process is something that I find typically more rewarding and less painstaking in CDP than most other systems I've worked with, allowing me to learn more by the simple fact that I can usually do many more trials than other systems might allow in the same span of time.  I consider it an absolute luxury to be able to render a two minute long sound in "high def", and having it ready for audition in five seconds (or less).  The old tape practitioners would be more than a little envious!

I like your idea of using Renoise as a workspace.  I do something similar with Harrison Mixbus, sometimes.  But, generally, the fewer tools I can get away with, these days, the better.  Failing a well integrated front-end, I'll take "simple."  In lieu of a work environment packed with more gear and software than anyone could possibly learn to use well in a lifetime, how many distractions can I cut away and still results I'm proud of?  A top-notch DAC & good headphones might be a given, but do I even need a particularly good computer, anymore?  Maybe not.  The road to gain enough know-how to really use everything effectively will be a long one for me.  But it's been interesting and oddly liberating!

If you don't already own them, I highly recommend Trevor Wishart's Audible Design and On Sonic Art.  I found these books useful and inspiring.