Composers Desktop Project Forum

Quote from: rwdobson on December 21, 2016, 02:23:12 PM
The recommended build system uses CMake, which will need to be installed separately if not already available.

Thank you for doing this!!

Any chance this repo will merge the Linux build, so all platforms can work from the same source tree?

Nicely done!  Systematic, straightforward scripting, nicely documented.  Looks like you are laying the groundwork for a formidable CDP command-line tutorial.

I've been looking to purchase a decent audio interface for my Libreboot'd X200 laptop, and wanted something that worked in Linux without proprietary drivers, had decent converters, live input monitoring, and digital I/O.  I seem to have nailed it with the Sound Devices USBPre 2 (http://www.sounddevices.com/products/portable-audio-tools/usbpre2).  it is targeted primarily for remote recording applications, and so despite its excellent ADCs, it is fully bus powered.  Even with Slackware Linux, my experience setting it up was literally plug & play!  it wouldn't be my first choice for low-latency recording/mixing with plugins (if that's your thing).  But if reliable, unfettered operation and quality sound "on the go" are your thing, I really recommend it.  I wish other audio hardware was so thoughtfully considered.

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.

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!

Just for confirmation, what is the line in your .bashrc file setting the environment variable?

May I applaud you for your incredible efforts to support CDP in Renoise?  Bravo!!

Thinking about this some more, I think if I were to make an additional suggestion to CDP developers for the build, I would request that the makeprograms.sh script check if PortAudio is found on the system, and ask the user if they want to build the local copy of portaudio if it is not found.  This would satisfy two requirements:

1) From the user side, a repo-installed PortAudio for your distribution (e.g., Trisquel, Debian, etc.) will probably be configured to use (and therefore should play nicely) with the audio subsystems used by that distribution (e.g., ALSA, PulseAudio), and over time this library will probably be kept more current by the package maintainer.  (On Slackware, you can use a SlackBuild to achieve effectively the same thing, or just compile it yourself.)

2) From the CDP developer side, including the portaudio source will allow these four programs to still reference some of the needed library source files (e.g., pa_ringbuffer.c/.h) for the build, since these don't seem to be included with even the so-called "-dev" packages maintained in many repos.

But as a rule, I would not compile against a local copy of portaudio unless the user really wanted it.

As you say, it is probably an impediment to folks who just give want to give the bulk of the system a whirl.  In particular, I would imagine that most users of the Renoise CDP tool might not ever use these four programs.  I'll point out (for anyone else reading) that these programs have been already segregated from the other programs in the makeprograms.sh script, so setting the PABUILD variable in that file to "no" ought to be enough to just get on with building the rest of the CDP system.

If you're stubborn like me (I use these programs a lot), then you'll find that both JACK and PortAudio are dependencies, even though the programs run fine--albeit, with some extra error output--even when the JACK server wasn't running.  I didn't want/need JACK on that particular machine, and found happily I could do without.

As an aside, I've been tinkering with the Linux build a bit.  I could not quite understand why JACK was required to build listaudevs, paplay, pvplay, and recsf, and it turns out you really don't need it!  After mucking with a few of the Linux makefiles, it turned out to be not very hard to compile these CDP tools against a system install of the portaudio library configured only for ALSA (sans Jack).  So far, no problems at all on my Slackware install.

Did you "export" the variable?  Without it, the variable you set won't be seen outside your current environment.  For example:

export CDP_SOUND_EXT=wav

Thank you very much, Dave.  This tutorial is easy to follow, and doesn't demand a lot from users who are not accustomed to building software.

Most of the developers have been heard from on this forum fairly recently (i.e., in the past two or three months), so I feel it is too soon to give up on them.  However, I am a little surprised that you have not seen the revised PVOC source, which you did ask for some time ago.  If you haven't already, may I recommend sending Richard Dobson a polite PM; or failing that, a personal email?

As for me, I'd really like an improved working environment for Linux/Mac command-line users, complete with man pages and some workflow concessions (e.g., a '-f' flag to overwrite existing files, etc.), and things along those lines.  No big ideas.  But enough that I'd like to see where everything stands before possibly taking a stab at some of them . . .

Excuse me for somehow overlooking this post!  And I would like to also apologize that no one else responded to you, either.

Did you ever resolve your issues with building the CDP source?  The portaudio library is required for only a small subset of all CDP programs, as you said, so at the least, it should be relatively straightforward to get things in order.  That you are running a 64-bit platform shouldn't be a problem.  I assume you're building for Mac OS X?

Regarding your second question, typing "pitch" at my shell, the interaction looks much like this:
$ pitch
CDP Release 7 2014

PITCH OPERATIONS ON A SPECTRAL FILE

USAGE: pitch NAME (mode) infile outfile parameters:

where NAME can be any one of

altharms    octmove    transp    tune    pick    chordf    chord

Type 'pitch altharms' for more info on pitch altharms..ETC.


$


So, indeed, "speed" is not a valid option for this command, so the command is not incorrect.  Are you perhaps looking for the MODIFY SPEED process?

Hi,

Where can the (very) latest CDP sources be found?  I recall there being a git repository or sourceforge project talked about on this forum, but not sure I was ever able to track it down.