In any case if you only have csoundapi~ objects you are effectively
only running csound  (although the ksmp function calls are made by
PD) and PD's IO (which should not be any problem for the
CPU).

Note that you can  run PD only to provide control, connecting to
a csound through OSC, or through UDP (in which case
a server script in Tcl or Python is needed).

Victor

----- Original Message ----- 
From: "Chuckk Hubbard" 
To: 
Sent: Saturday, December 08, 2007 2:49 PM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: teaching csound: textbook, PD, 
etc


> On Dec 6, 2007 11:54 PM,   wrote:
>> I think you can use dac~ anyway, because you're already
>> running DSP in PD to make csoundapi~ run, there would not
>> be any overhead. Note that csoundapi~ should not be
>> producing sound directly; if it is, is because one of the API
>> functions that stop that happening is not working.
>
> That hasn't been happening, I use the -nd flags just in case now.  It
> was happening at one point, but I believe you fixed it.
> So far I don't have problems with CPU running Pd with Csoundapi~,
> although I mostly use it to test opcodes.
> As I understand it, it is possible to run Pd as two processes on two
> computers; perhaps it would be possible to somehow take advantage of
> its Wish side with Csound, without invoking Pd's DSP at all?  I like
> that Pd's edit mode and play mode are fairly seamless, and I wonder
> how hard it would be to implement a similar thing with cswish.
> Perhaps it could almost work as-is.
>
> -Chuckk
>
> -- 
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"