Hey everyone, I reported this a bit ago, but Istvan thought maybe it was 
just not clean builds or problems with API compatibility in my code, so 
I did an eradicate, fresh build as of today's check out, and test with 
totally simple host and csd, both of which are attached. Note, this 
example *used* to work in both real time and deferred with 
OPCODEDIR=/csound5. This is on linux.

If OPCODEDIR=/csound5/Opcodes :

- my api example works with rendering ( "csound fl_controller.csd" )
- command line csound works with rendering ( as above )
- -odac does NOT work, with either api or command line, either portaudio 
or alsa
*** error: unknown rtaudio module 'PortAudio'
or
*** error: unknown rtaudio module 'alsa'


If OPCODEDIR=/csound5 :

- command line works with both renderring and -odac
- my api example does not work with either renderring or -odac

Error in pre-initialization function of module 'libsrconv.so'
Error in pre-initialization function of module 'libsndinfo.so'
Error in pre-initialization function of module 'libscale.so'

So, as far as I can tell, the API is currently unusable in real time, 
and to be used in deferred time requires a reexport of OPCODEDIR. What 
is OPCODEDIR supposed to be?

Thanks
Iain

Iain Duncan wrote:

> - my api example works with rendering ( "csound fl_controller.csd" )
> - command line csound works with rendering ( as above )
> - -odac does NOT work, with either api or command line, either portaudio 
> or alsa
> *** error: unknown rtaudio module 'PortAudio'
> or
> *** error: unknown rtaudio module 'alsa'

Well, actually where is librtpa.so ?

> - command line works with both renderring and -odac
> - my api example does not work with either renderring or -odac
> 
> Error in pre-initialization function of module 'libsrconv.so'
> Error in pre-initialization function of module 'libsndinfo.so'
> Error in pre-initialization function of module 'libscale.so'

Did you recompile and relink the API example against the new
sources ? If not, it probably does not like the new plugins as
binary API compatibility is not maintained until Csound 5 is
actually released.

> So, as far as I can tell, the API is currently unusable in real time, 
> and to be used in deferred time requires a reexport of OPCODEDIR. What 
> is OPCODEDIR supposed to be?

An environment variable storing the name of a directory containing
Csound plugin libraries such as libbabo.so, libbbcut.so, librtalsa.so,
and so on. For double precision plugins, OPCODEDIR64 should be set.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>> - my api example works with rendering ( "csound fl_controller.csd" )
>> - command line csound works with rendering ( as above )
>> - -odac does NOT work, with either api or command line, either 
>> portaudio or alsa
>> *** error: unknown rtaudio module 'PortAudio'
>> or
>> *** error: unknown rtaudio module 'alsa'
> 
> 
> Well, actually where is librtpa.so ?

Is is present at both /csound5/librtpa.so and 
/usr/local/lib/csound/opcodes/librtpa.so

>> - command line works with both renderring and -odac
>> - my api example does not work with either renderring or -odac
>>
>> Error in pre-initialization function of module 'libsrconv.so'
>> Error in pre-initialization function of module 'libsndinfo.so'
>> Error in pre-initialization function of module 'libscale.so'
> 
> Did you recompile and relink the API example against the new
> sources ? If not, it probably does not like the new plugins as
> binary API compatibility is not maintained until Csound 5 is
> actually released.

The api example was recompiled. The makefile is:

cs_simple_1: cs_simple_1.c
	g++ -o cs_simple_1 cs_simple_1.c  \
	-lcsound -lsndfile -lportaudio -lportmidi -lporttime

>> and to be used in deferred time requires a reexport of OPCODEDIR. What 
>> is OPCODEDIR supposed to be?
> 
> An environment variable storing the name of a directory containing
> Csound plugin libraries such as libbabo.so, libbbcut.so, librtalsa.so,
> and so on. For double precision plugins, OPCODEDIR64 should be set.

Ok, so is there a logical explanation of why different ones are working? 
Is this a problem with the source tree or the scons install?

Thanks for looking into this Istvan,
Iain




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> Is is present at both /csound5/librtpa.so and 
> /usr/local/lib/csound/opcodes/librtpa.so

Now which one is the correct, newly compiled file ?

> The api example was recompiled. The makefile is:
> 
> cs_simple_1: cs_simple_1.c
>     g++ -o cs_simple_1 cs_simple_1.c  \
>     -lcsound -lsndfile -lportaudio -lportmidi -lporttime

Where does it get -lcsound from ? Is it possible that you have
an old installation in /usr/local and that is used (assuming from
librtpa.so above) ?

> Ok, so is there a logical explanation of why different ones are working? 
> Is this a problem with the source tree or the scons install?

It is probably a problem with the installation. You should have exactly
one copy of each plugin, in a directory that you should set OPCODEDIR to.
The only exception is installing both 32 and 64 bit precision (not directly
supported by SConstruct), in which case single precision plugins should be
in OPCODEDIR, and double precision ones in OPCODEDIR64.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> The api example was recompiled. The makefile is:
> 
> cs_simple_1: cs_simple_1.c
>     g++ -o cs_simple_1 cs_simple_1.c  \
>     -lcsound -lsndfile -lportaudio -lportmidi -lporttime

Compiling with this command in the Csound build directory,

g++ -Wall -O2 -IH -o cs_simple_1 cs_simple_1.c -L. -lcsound -lsndfile -ldl -lm -lpthread

your example seems to work without the reported problems. I did have
to replace 'void *csound;' with 'CSOUND *csound;', as g++ does not like
implicit pointer conversions, and the file fails to compile as C due to
the use of C++ syntax. This does seem to suggest that you compiled
against an old version of Csound, given that the instance pointer type
was changed to CSOUND* somewhat more than about 1.5 months ago, and
without changes the example does not compile with a recent version
of libcsound as either C or C++.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks Istvan, I got it working by hunting down old csound files. I had 
a csound.h in multiple places.

Thanks again for all the attention to this.
Iain

Istvan Varga wrote:
> Iain Duncan wrote:
> 
>> The api example was recompiled. The makefile is:
>>
>> cs_simple_1: cs_simple_1.c
>>     g++ -o cs_simple_1 cs_simple_1.c  \
>>     -lcsound -lsndfile -lportaudio -lportmidi -lporttime
> 
> 
> Compiling with this command in the Csound build directory,
> 
> g++ -Wall -O2 -IH -o cs_simple_1 cs_simple_1.c -L. -lcsound -lsndfile 
> -ldl -lm -lpthread
> 
> your example seems to work without the reported problems. I did have
> to replace 'void *csound;' with 'CSOUND *csound;', as g++ does not like
> implicit pointer conversions, and the file fails to compile as C due to
> the use of C++ syntax. This does seem to suggest that you compiled
> against an old version of Csound, given that the instance pointer type
> was changed to CSOUND* somewhat more than about 1.5 months ago, and
> without changes the example does not compile with a recent version
> of libcsound as either C or C++.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net