Hi List,

Since I've found that csoundapi~ for Pd can load opcodes from 
libcsound.a I was wondering what conventions exist for modifying 
entry1.c ... namely what is "T" type in the pv opcodes?

I realize this requires modifying the sources for each opcode, things 
like changing #include "csdl.h" to #include "csoundCore.h" and possibly 
appending functions to pstream.h or others for example.

What is the most efficient way at compiling all opcodes within 
libcsound.a? It looks like by default there is about 610 or so (as 
opposed to > 1000 with all dynamic libraries).


-David

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Nevermind, I figured it out.


-David

On Aug 24, 2005, at 1:42 AM, David Akbari wrote:

> Hi List,
>
> Since I've found that csoundapi~ for Pd can load opcodes from 
> libcsound.a I was wondering what conventions exist for modifying 
> entry1.c ... namely what is "T" type in the pv opcodes?
>
> I realize this requires modifying the sources for each opcode, things 
> like changing #include "csdl.h" to #include "csoundCore.h" and 
> possibly appending functions to pstream.h or others for example.
>
> What is the most efficient way at compiling all opcodes within 
> libcsound.a? It looks like by default there is about 610 or so (as 
> opposed to > 1000 with all dynamic libraries).
>
>
> -David
>

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

David Akbari wrote:

> Since I've found that csoundapi~ for Pd can load opcodes from 
> libcsound.a I was wondering what conventions exist for modifying 
> entry1.c ... namely what is "T" type in the pv opcodes?

It expects either a string of type S (constant or variable), or
i-rate value (variable, p-field, constant, etc.).

> I realize this requires modifying the sources for each opcode, things 
> like changing #include "csdl.h" to #include "csoundCore.h" and possibly 
> appending functions to pstream.h or others for example.
> 
> What is the most efficient way at compiling all opcodes within 
> libcsound.a? It looks like by default there is about 610 or so (as 
> opposed to > 1000 with all dynamic libraries).

I do not understand what you exactly mean; do you want to move all
plugins into libcsound.a ? What is wrong with using plugins ?
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

On Aug 24, 2005, at 5:30 AM, Istvan Varga wrote:
>
> I do not understand what you exactly mean; do you want to move all
> plugins into libcsound.a ? What is wrong with using plugins ?
>

Of course, the plugin interface that exists for Csound5 at present is 
the cleanest, most efficient way to load modules for Csound. This 
considered, there is nothing wrong with using plugins, in fact they 
would be better in most cases.

My problem is that I cannot seem to figure out a way to set an 
environment variable for Pd. (OPCODEDIR / OPCODEDIR64) I now realize 
that it likes to load opcodes from libcsound.a. There's really no way 
to set it in Pd (using Pd's "-path" flag doesn't work when pointing to 
OPCODEDIR64 and no patcher object/message exists for this purpose, at 
present) thus I have been basically just appending the sources from CVS 
so that all opcodes are built into libcsound.a. csoundapi~ seems to 
link against whatever libcsound.a is present at compile time. More 
specifically I have been messing around with

OOps/pstream.c,
OOps/pstream.h,
Engine/entry2.c

although this is an inefficient way to go about this, so far it's been 
working (I've succesfully added 12 pvs opcodes) which is good to be 
able to test in the interim (while the Pd scene progresses).

One thing to note is that I'm using Victor's package for OSX from June 
12th for this purpose and this predates the renaming from the ENVIRON 
structure to CSOUND. So in effect I'm doing a reverse CVS but for no 
official purpose.

For a beginning programmer such as myself, I think of this as nothing 
more than an exercise...


-David

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

How about setting OPCODEDIR/OPCODEDIR64 from csoundapi~ ?
The csoundSetDefaultEnv() function (recently added to the API) makes
it possible for the host, in this case csoundapi~, to set environment
variables before creating an instance of Csound.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Thanks, Isvan. This is exactly what I was looking for... it sure is a 
lot more efficient than appending 427 opcodes to libcsound.a.


-David

On Aug 24, 2005, at 7:10 AM, Istvan Varga wrote:

> How about setting OPCODEDIR/OPCODEDIR64 from csoundapi~ ?
> The csoundSetDefaultEnv() function (recently added to the API) makes
> it possible for the host, in this case csoundapi~, to set environment
> variables before creating an instance of Csound.
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

I had the impression that csoundapi~, as any other frontend (like the 
command-line csound),
looks for OPCODEDIR and loads the opcodes from that directory.
At least that is what seems to happen here.

Victor

At 11:46 24/08/2005, you wrote:

>On Aug 24, 2005, at 5:30 AM, Istvan Varga wrote:
>>
>>I do not understand what you exactly mean; do you want to move all
>>plugins into libcsound.a ? What is wrong with using plugins ?
>
>Of course, the plugin interface that exists for Csound5 at present is the 
>cleanest, most efficient way to load modules for Csound. This considered, 
>there is nothing wrong with using plugins, in fact they would be better in 
>most cases.
>
>My problem is that I cannot seem to figure out a way to set an environment 
>variable for Pd. (OPCODEDIR / OPCODEDIR64) I now realize that it likes to 
>load opcodes from libcsound.a. There's really no way to set it in Pd 
>(using Pd's "-path" flag doesn't work when pointing to OPCODEDIR64 and no 
>patcher object/message exists for this purpose, at present) thus I have 
>been basically just appending the sources from CVS so that all opcodes are 
>built into libcsound.a. csoundapi~ seems to link against whatever 
>libcsound.a is present at compile time. More specifically I have been 
>messing around with
>
>OOps/pstream.c,
>OOps/pstream.h,
>Engine/entry2.c
>
>although this is an inefficient way to go about this, so far it's been 
>working (I've succesfully added 12 pvs opcodes) which is good to be able 
>to test in the interim (while the Pd scene progresses).
>
>One thing to note is that I'm using Victor's package for OSX from June 
>12th for this purpose and this predates the renaming from the ENVIRON 
>structure to CSOUND. So in effect I'm doing a reverse CVS but for no 
>official purpose.
>
>For a beginning programmer such as myself, I think of this as nothing more 
>than an exercise...
>
>
>-David
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

I think that is true for Windows and Linux, however Aqua apps for some 
reason don't seem to see commandline environment variables. However, 
there is a simple fix along those lines.

The problem is that on OSX programs launched from the aqua interface do 
not read the files like .profile to get environment variables -- those 
are only available to programs launched via a shell.  There is, 
however, a file that provides this sort of info for aqua interfaces.  
It is
~/.MacOSX/environment.plist -- it doesn't exist by default so you have 
to make it usually. Below are sample contents of this file:





     OPCODEDIR
     /usr/local/lib/csound/opcodes
     OPCODEDIR64
     /usr/local/lib/csound/opcodes64



This seems to load the opcodes as expected...


-David

On Aug 24, 2005, at 9:27 AM, Victor Lazzarini wrote:

> I had the impression that csoundapi~, as any other frontend (like the 
> command-line csound),
> looks for OPCODEDIR and loads the opcodes from that directory.
> At least that is what seems to happen here.
>
> Victor
>
> At 11:46 24/08/2005, you wrote:
>
>> On Aug 24, 2005, at 5:30 AM, Istvan Varga wrote:
>>>
>>> I do not understand what you exactly mean; do you want to move all
>>> plugins into libcsound.a ? What is wrong with using plugins ?
>>
>> Of course, the plugin interface that exists for Csound5 at present is 
>> the cleanest, most efficient way to load modules for Csound. This 
>> considered, there is nothing wrong with using plugins, in fact they 
>> would be better in most cases.
>>
>> My problem is that I cannot seem to figure out a way to set an 
>> environment variable for Pd. (OPCODEDIR / OPCODEDIR64) I now realize 
>> that it likes to load opcodes from libcsound.a. There's really no way 
>> to set it in Pd (using Pd's "-path" flag doesn't work when pointing 
>> to OPCODEDIR64 and no patcher object/message exists for this purpose, 
>> at present) thus I have been basically just appending the sources 
>> from CVS so that all opcodes are built into libcsound.a. csoundapi~ 
>> seems to link against whatever libcsound.a is present at compile 
>> time. More specifically I have been messing around with
>>
>> OOps/pstream.c,
>> OOps/pstream.h,
>> Engine/entry2.c
>>
>> although this is an inefficient way to go about this, so far it's 
>> been working (I've succesfully added 12 pvs opcodes) which is good to 
>> be able to test in the interim (while the Pd scene progresses).
>>
>> One thing to note is that I'm using Victor's package for OSX from 
>> June 12th for this purpose and this predates the renaming from the 
>> ENVIRON structure to CSOUND. So in effect I'm doing a reverse CVS but 
>> for no official purpose.
>>
>> For a beginning programmer such as myself, I think of this as nothing 
>> more than an exercise...
>>
>>
>> -David
>>
>> --
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

I've been messing around with the 4.23 version of csoundapi~ on WinXP 
and after some initial frustration I've succeeded in getting it to work, 
more or less. I have found that it is not necessary to invoke it with 
-lib csoundapi~, but I get the message "Warning: could not compile" if 
the .csd is located anywhere except at the top level of the pd 
directory. I suppose this is because csound is looking there for the 
orc/sco. I wonder if there is a way to put the .sco in my pd patches 
directory and have them work.
Also I notice that when the csoundapi~ is idle I get a high-pitched 
whine after an event is complete, unless I send the 'e' command or set 
run 0. I get this with pd 0.37 and pd 0.39. Is there a way to clear the 
audio buffer?

Martin


-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

I have to check that whine, it's probably a bug. Probably will not have much
time very soon. By the way, you might be able to run the orc/sco from anywhere
by giving the full path to it.

Victor

At 15:01 24/08/2005, Martin Peach wrote:
>I've been messing around with the 4.23 version of csoundapi~ on WinXP and 
>after some initial frustration I've succeeded in getting it to work, more 
>or less. I have found that it is not necessary to invoke it with -lib 
>csoundapi~, but I get the message "Warning: could not compile" if the .csd 
>is located anywhere except at the top level of the pd directory. I suppose 
>this is because csound is looking there for the orc/sco. I wonder if there 
>is a way to put the .sco in my pd patches directory and have them work.
>Also I notice that when the csoundapi~ is idle I get a high-pitched whine 
>after an event is complete, unless I send the 'e' command or set run 0. I 
>get this with pd 0.37 and pd 0.39. Is there a way to clear the audio buffer?
>
>Martin
>
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

In my OSX I launch PD from the command-line

/Applications/pd/bin/pd

mind you my version of PD is probably older. It's not an aqua application,
but just an ordinary darwin command (that runs under Tcl/Tk).

Victor

At 14:47 24/08/2005, you wrote:
>I think that is true for Windows and Linux, however Aqua apps for some 
>reason don't seem to see commandline environment variables. However, there 
>is a simple fix along those lines.
>
>The problem is that on OSX programs launched from the aqua interface do 
>not read the files like .profile to get environment variables -- those are 
>only available to programs launched via a shell.  There is, however, a 
>file that provides this sort of info for aqua interfaces.
>It is
>~/.MacOSX/environment.plist -- it doesn't exist by default so you have to 
>make it usually. Below are sample contents of this file:
>
>
>"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>
>
>     OPCODEDIR
>     /usr/local/lib/csound/opcodes
>     OPCODEDIR64
>     /usr/local/lib/csound/opcodes64
>
>
>
>This seems to load the opcodes as expected...
>
>
>-David
>
>On Aug 24, 2005, at 9:27 AM, Victor Lazzarini wrote:
>
>>I had the impression that csoundapi~, as any other frontend (like the 
>>command-line csound),
>>looks for OPCODEDIR and loads the opcodes from that directory.
>>At least that is what seems to happen here.
>>
>>Victor
>>
>>At 11:46 24/08/2005, you wrote:
>>
>>>On Aug 24, 2005, at 5:30 AM, Istvan Varga wrote:
>>>>
>>>>I do not understand what you exactly mean; do you want to move all
>>>>plugins into libcsound.a ? What is wrong with using plugins ?
>>>
>>>Of course, the plugin interface that exists for Csound5 at present is 
>>>the cleanest, most efficient way to load modules for Csound. This 
>>>considered, there is nothing wrong with using plugins, in fact they 
>>>would be better in most cases.
>>>
>>>My problem is that I cannot seem to figure out a way to set an 
>>>environment variable for Pd. (OPCODEDIR / OPCODEDIR64) I now realize 
>>>that it likes to load opcodes from libcsound.a. There's really no way to 
>>>set it in Pd (using Pd's "-path" flag doesn't work when pointing to 
>>>OPCODEDIR64 and no patcher object/message exists for this purpose, at 
>>>present) thus I have been basically just appending the sources from CVS 
>>>so that all opcodes are built into libcsound.a. csoundapi~ seems to link 
>>>against whatever libcsound.a is present at compile time. More 
>>>specifically I have been messing around with
>>>
>>>OOps/pstream.c,
>>>OOps/pstream.h,
>>>Engine/entry2.c
>>>
>>>although this is an inefficient way to go about this, so far it's been 
>>>working (I've succesfully added 12 pvs opcodes) which is good to be able 
>>>to test in the interim (while the Pd scene progresses).
>>>
>>>One thing to note is that I'm using Victor's package for OSX from June 
>>>12th for this purpose and this predates the renaming from the ENVIRON 
>>>structure to CSOUND. So in effect I'm doing a reverse CVS but for no 
>>>official purpose.
>>>
>>>For a beginning programmer such as myself, I think of this as nothing 
>>>more than an exercise...
>>>
>>>
>>>-David
>>>
>>>--
>>>Send bugs reports to this list.
>>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>
>>Victor Lazzarini
>>Music Technology Laboratory
>>Music Department
>>National University of Ireland, Maynooth
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 

-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

This problem may be caused by the fact that Csound 4.23, unlike
version 5, does not clear the spout buffer to zero when there are
no active notes, so garbage that was left there is repeated until
a new note that uses one of the 'out' opcodes is turned on.
One possible workaround is to add an always-on dummy instrument
to the orchestra that writes zero samples to the audio output.

Victor Lazzarini wrote:

> I have to check that whine, it's probably a bug. Probably will not have 
> much
> time very soon. By the way, you might be able to run the orc/sco from 
> anywhere
> by giving the full path to it.
> 
> Victor
> 
> At 15:01 24/08/2005, Martin Peach wrote:
> 
>> I've been messing around with the 4.23 version of csoundapi~ on WinXP 
>> and after some initial frustration I've succeeded in getting it to 
>> work, more or less. I have found that it is not necessary to invoke it 
>> with -lib csoundapi~, but I get the message "Warning: could not 
>> compile" if the .csd is located anywhere except at the top level of 
>> the pd directory. I suppose this is because csound is looking there 
>> for the orc/sco. I wonder if there is a way to put the .sco in my pd 
>> patches directory and have them work.
>> Also I notice that when the csoundapi~ is idle I get a high-pitched 
>> whine after an event is complete, unless I send the 'e' command or set 
>> run 0. I get this with pd 0.37 and pd 0.39. Is there a way to clear 
>> the audio buffer?
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk