Appending libcsound.a

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Appending libcsound.a

David Akbari
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

David Akbari
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

Istvan Varga
In reply to this post by David Akbari
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

David Akbari

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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

Istvan Varga
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

David Akbari
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 [hidden email]
>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

Victor Lazzarini
In reply to this post by David Akbari
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 [hidden email]

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

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

David Akbari
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:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>OPCODEDIR</key>
     <string>/usr/local/lib/csound/opcodes</string>
     <key>OPCODEDIR64</key>
     <string>/usr/local/lib/csound/opcodes64</string>
</dict>
</plist>

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 [hidden email]
>
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> --
> Send bugs reports to this list.
> To unsubscribe, send email to [hidden email]
>

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

csoundapi~

Martin Peach
In reply to this post by Victor Lazzarini
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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: csoundapi~

Victor Lazzarini
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 [hidden email]

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

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Appending libcsound.a

Victor Lazzarini
In reply to this post by David Akbari
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:
>
><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
>"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
><plist version="1.0">
><dict>
>     <key>OPCODEDIR</key>
>     <string>/usr/local/lib/csound/opcodes</string>
>     <key>OPCODEDIR64</key>
>     <string>/usr/local/lib/csound/opcodes64</string>
></dict>
></plist>
>
>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 [hidden email]
>>
>>Victor Lazzarini
>>Music Technology Laboratory
>>Music Department
>>National University of Ireland, Maynooth
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to [hidden email]
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to [hidden email]

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

--
Send bugs reports to this list.
To unsubscribe, send email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: csoundapi~

Istvan Varga
In reply to this post by Victor Lazzarini
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 [hidden email]