Very useful info, Anthony. Thanks.

Multiple omments in line.

Art Hunkins

Art:  are you asking about files loaded by the orc/sco or about plugins or
about other necessary libraries??  The answer is different for each of
these.
------
I'm asking about the plugins and other libraries - the subject of those 
multiple, darned WARNING messages, and popup boxes "can't find 
Python25.dll".
-----
For shared libraries (.dll's) required by Csound or one of Csound's plugins,
the required location of these libraries is determined by the operating
system.  (Some OSes such as Linux may allow the user to configure these
paths).  Since these libraries are loaded automatically by the OS, Csound
does not have any control over where to look for them.  Thus, Python25.dll
must be where WINDOWS expects it to be, not Csound.
-----
OK. From what Michael says, this must be Windows/system32. I gather that if 
the Windows 5.07.2 installer is working correctly, it will put Python25.dll 
there. Also, if you're installing Python yourself, it will likewise be 
placed in the proper location. So the user shouldn't have to worry about 
this. Right now, however, there seems to be a problem with the 5.07.2 
installer not actually installing Python (when requested), while Csound is 
expecting it - apparently resulting in that bothersome "can't find 
Python25.dll" popup (actually there are two of them - the second one also 
specifying "FluidSynth").
----- 
Plugins are different, because Csound explicitly loads them while running.
Thus, Csound decides where to look for its own plugin libraries.

I have just looked at the code for plugin loading, and while there is a
comment that says plugins are sought in the current directory if OPCODEDIR
is undefined, it appears that this is no longer true for _release_ versions
of Csound.  In fact, the following code seems wrong to me for Windows:

/* default directory to load plugins from if environment variable is not set
*/
#if !(defined(_CSOUND_RELEASE_) && (defined(LINUX) || defined(__MACH__)))
#  define ENABLE_OPCODEDIR_WARNINGS 1
#  ifdef CS_DEFAULT_PLUGINDIR
#    undef CS_DEFAULT_PLUGINDIR
#  endif
#  define CS_DEFAULT_PLUGINDIR      "."
#else
#  define ENABLE_OPCODEDIR_WARNINGS 0
#  ifndef CS_DEFAULT_PLUGINDIR
#    ifndef USE_DOUBLE
#      define CS_DEFAULT_PLUGINDIR  "/usr/local/lib/csound/plugins"
#    else
#      define CS_DEFAULT_PLUGINDIR  "/usr/local/lib/csound/plugins64"
#    endif
#  endif
#endif


It appears that the current dir is only used (_for_plugins_) when both on
Linux or MacOS X and when building a non-release version of Csound.  But
Windows always is looking in "/usr/local/lib/csound/plugins" or
".../plugins64".  Is this correct?
-----
It would certainly be nice if on Windows the search, by default, would be in 
the current directory. (Personally, I like to run everything out of the 
current directory, with no environment variables.) I wonder if this is the 
source for the many WARNING messages at the beginning of a Csound run - as 
in "xxxxx is not a plugin". It would be so nice if these would disappear.
-----
Another issue, Art, is that the notion of the "current directory" may be
affected by how you are running Csound.  From the command line, it is
obviously the shell's current directory.  But if you run Csound from a GUI
interface launched by double-clicking on it, the current directory is set to
some default by the operating system.  On MacOS X, this seems to be the root
of the file system (which is generally useless).  On MacOS 9, it is the
folder containing the GUI application.  I have no idea what the default is
on Windows.
-----
Anybody know, or does it matter? I'll add my name to the list of those 
unable to run (my realtime) compositions on either Winsound or CsoundGUI. 
Neither produce any sound; both seem to have trouble finding 
libraries/plugins where they are normally located (though this is common to 
all renderings as discussed above). And I'm talking about putting all my 
materials in Csound/bin and running from there (the presumed "current 
directory").
-----
Hope that this clears things up.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If plugins are searched for in the current directory, then yes, I would
expect a lot of those warnings.

I think that these messages are useless unless someone is developing a
plugin.  I too would like to see them removed or changed so that they only
print with --verbose (or a similar mechanism).

The problem is that plugins are loaded _before_ the Csound command line is
processed (and a host application might not even be intending to call
csoundCompile() after csoundPreCompile()).  So I am not sure how to turn
these messages off by default and still be able to enable them somehow.

Any suggestions?

I hate to suggest it ... but an environment variable would work.  Another
problem I think is that the message callback cannot be set before calling
csoundPreCompile (?) so host apps can't catch these messages.  This is
especially noticeable on OS 9 where these is no console to view them with.

Anthony

Art Hunkins wrote on 12/15/07 3:07 PM:

> It would certainly be nice if on Windows the search, by default, would be in
> the current directory. (Personally, I like to run everything out of the
> current directory, with no environment variables.) I wonder if this is the
> source for the many WARNING messages at the beginning of a Csound run - as
> in "xxxxx is not a plugin". It would be so nice if these would disappear.


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have always disliked those messages about not being a plugin; but
then I wanted a totally different model for loading plugins anyway.
  I would prefer that the messages were suppressed, or as an
alternative stored until the level of verbosity was determined.
==John ffitch

"This research is of insufficient standard"

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have a version that delays printing the warnings about unloadable
modules until the end of loading.  This could be delayed until later,
and so controlled by command-line options.  
==John ffitch

"This research is of insufficient standard"

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff wrote on 12/16/07 6:00 AM:

> I have a version that delays printing the warnings about unloadable
> modules until the end of loading.  This could be delayed until later,
> and so controlled by command-line options.
> ==John ffitch

This would be great, John.  I suggest delaying them until after argument
parsing and then only printing if --verbose is on.

victor wrote on 12/16/07 5:11 AM:

> why can't we set them to a high-verbose level, so that they are
> not shown by default?

Plugins are loaded during csoundPreCompile() -- before command line
arguments are parsed (or even passed to the Csound library).

Anthony


-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Arhhhhhh. Just deleted my entire Csound5 tree (with those changes this
morning) and Sourceforge does not seem to want to talk to me.....
Hum....

==John ffitch

"This research is of insufficient standard"

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have recovered my code.  The problem is that is the messages are not
printed in csoundPreCompile then either we need a new API function to
print them, or there is a danger that the API users will not get the
messages.
  Not sure of the way ahead here.

Until then there is a collection of messages waiting to be printed;
could do in argdecode, with possible loss to API users.

==John ffitch

"This research is of insufficient standard"

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net