I have to check the reset message, I hadn't noticed that.

How are you starting PD? From the command-line or double-clicking?

When you start from the command-line, you can access the files in the directory where you started it directly. When you double-click the working directory is set to where the double-clicked file is (unless otherwise specified in the file properties)

If you want files from anywhere else, give the full-path to them. But PD has a limit on the size of string arguments, so a very long path will not work. My suggestion is to always start PD from your working directory.

You can force a certain number of IO channels by specifying a number as the first argument to PD (but remember to match that on your CSD).

Looks like most of the problems you are having with it seem to stem from starting PD by double clicking on PD (or on a batch file). if you want to use PD that way, perhaps copying it to your working directory will do the trick (then PD either has to be on your path or the full-path to exe, from the drive letter up has to be given in the batch file).

I have had no problems starting and running PD on Windows, Linux or OSX. On windows and linux, I always start it from the command-line. On the OSX, I do both (double-clicking or command-line).

Victor

Victor Lazzarini wrote:

...

I realised now that this has not been included in the release notes, but it's probably the most important bit of the Csound5 distribution for the PD community:

Csound 5 includes csoundapi~, a PD frontend for csound in the style of the Max/MSP csound~ (which is based on csound4). Csoundapi~, unlike csound~ for PD, uses the csound library and API. It is multi-instantiable and provides many facilities for controlling csound. You will have access to the 1000 or so opcodes that csound provides (and that wonderful orchestra and score language that we all love :) ...).

..and the wonderful documentation that may or may not be true ;)

I finally got it to work on WinXp with pd0_39_2test7...

The installer created environment variables CSOUNDRC, OPCODEDIR64, PYTHONPATH and RAWWAVE_PATH and a user variable Path="C:\Program Files\Csound\bin".

So first I start pd and then load csoundapi.pd from "C:\Program Files\Csound\examples\csoundapi_tilde". [csoundapi~] is created (with 1 inlet and 3 outlets and "could not compile", which experience tells me really means "could not find") after I added "C:\Program Files\Csound\bin" to pd's path, but the csapi_demo.csd file only loads if I place it in pd/bin (now it has 4 inlets and 6 outlets).

I can also put it in pd and load it as "../csapi_demo.csd" but by then the [csoundapi~] object has the wrong number of inlets and outlets and the patch needs to be edited. So it seems like a bad idea to change files on an existing [csoundapi~].

Sending the [reset( message to [csoundapi~] always crashes pd.

According to the documentation, an environment variable INCDIR can be set to point to .sco and .orc files, but this is probably obsolete because it has no effect.

Is there any way to specify a directory for .csd files other than /pd/bin?

Martin