I have no interest in distributing everything.

I do have an interest in distributing something that provides significant additional functionality over csound 5.

Here is my list again:

csound binary
csound utilities (OK with me if they only run INSIDE csound with -U)
FluidSynth opcode
Python opcodes
VST host opcodes
DSSI host opcodes
Python interface
LISP interface
Java interface
Jack
Better demos
Some sort of pvoc opcode set (Loris/ATS/whatever) as long as it actually works (Note: Loris does work, haven't tried the others). I have no brief for or against Loris or anything else. If Lazzarini or someone is actively maintaining something like this AS A CSOUND OPCODE that works, including analysis tools, then that should go in and the others out. Getting hetro/adsyn and pvanal/pvoc working properly might also be enough.
Same directory structure on all platforms
Don't care about front ends, not opposed to them either

-----Original Message-----
From: jpff@codemist.co.uk
Sent: Dec 1, 2005 6:01 AM
To: csound-devel@lists.sourceforge.net
Subject: [Cs-dev] What should be in a release?

I still want to move forward on this.

First there seem to be two fundamentally opposed ideas; either to
create a minimal binary distribution with additional distribution for
frontends, inter-working etc, or a single distribution that has it
all.

I am primarily concerned with distribution to end users who have no
time, no tools, no skill or no interest in building from source.
These users may not have root access either.

At present my model for distribution is in 4 main sections
bin        Binary programs
opc        Opcode etc plugins
doc        Manual
lib        Additional optional libraries

QUESTION: IS THERE ANOTHER SECTION NEEDED?

In bin at present i have:
   brkpt          cs            csb64enc        cscore
   csound         cstclsh       cswish          cvanal
   dnoise         envext        extract         extractor
   het_export     het_import    hetro           linseg
   lpanal         lpc_export    lpc_import      makecsd
   mixer          pvanal        pvlook          scale
   scot           scsort        sdif2ad         srconv
   tabdes

QUESTION: SHOULD ANY OF THESE NOT BE DISTRIBUTED?

QUESTION: WHAT OTHER BASIC BINARIES ARE THERE?

In the opc I expect all the lib.so/dynlib plugins we compile.
Personally I am disappointed to see the collection of a number of
them into a larger library, as it conflicts with my view of small lean
tuned performance systems, but I can live with the majority view

QUESTION: ARE THERE ANY PLUGINS WE SHOULD NOT DISTRIBUTE?

The documentation I am assuming is the HTML version of the manual,
which is looking almost complete now.  

QUESTION: SHOULD WE DISTRIBUTE PDF PS OR DOC MANUALS?

My largest uncertainty is regarding the libraries.  We should not
overwrite existing installed libraries, but checking this is a pain.
At present I am rather hand writing this area, but there is a
possibility for a more table-driven installation here.

QUESTION: ANYONE GOT A CLEAR MODEL FOR LIBRARIES?

The last topic is dealing with the OPCODEDIR environment.  We could
tell the user to set the environment correctly, but experience on the
Csound list is this is not easy.  I favour wrapping the installed
binaries with a script to set environments, possibly in two bin
directories -- eg wrapped in /usr/local/bin and unwrapped in
/usr/local/bib/CS5.

QUESTION: SHOULD WE USE ALL WRAPPERS?

QUESTION: WHICH ENVIRONMENT VARIABLES SHOULD WE DEFINE IN THE
WRAPPED?

That will do for now.  Some of the developers will be seeing each
other at the Electric Sounds '05 meeting this weekend, and I hope we
can find time to forward this area.  So now is a timely moment to add
input.

==John ffitch


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Dec 3, 2005, at 5:23 AM, Istvan Varga wrote:

> I already have these all, with the exception of the VST host opcodes
> that are obviously Win32/Mac only.

Actually all attempts at building the VST host opcodes have been 
unsuccessful on OS X :(

What the documentation seems to lack is a simple explanation of *where 
exactly* does the VSTSDK folder from Steinberg's SDK go !? When 
building the LADSPA/VST host bridge for Audacity, there was a clearly 
articulated readme file. Presently Csound's CVS module lacks such a 
clear README for building these highly anticipated opcodes. Reading all 
the source code from Opcodes/vst4cs/src/*.* does not reveal the correct 
way to build these :\

On Dec 3, 2005, at 10:22 AM, Michael Gogins wrote:

> If ATS requires a separate analysis utility, ATS should not be in the 
> Csound distribution unless the analysis utility also is included.

I disagree with this. I was under the impression that the only reason 
these files are not included with Csound is because of licensing issues 
for the ATS project. Other than actually making the ATS files, the 
opcodes work very well. I can see the point that it would be useful to 
include all necessary files for the analysis, but also remember that 
the files included with the ATS project are not the only ways to make 
ATS files. It seems to be becoming a more standardized format, as we 
can do analysis in SPEAR now as well.

> How well do the native Csound opcodes work? If they don't work, then I 
> strongly recommend Loris as I know that it does work and I build it on 
> Linux and Windows.

I've never been able to get Loris to work on OS X. Or FluidSynth, 
despite the fact that the headers are found and the configuration 
decision indicates they are building. Due to this fact (that SConstruct 
reports finding everything OK) I shouldn't really be messing around 
with custom.py; assuming the installer is written correctly.

What would be nice is to remove all the pre-compiled binaries from CVS 
and replace them with clear README files that serve as indicators to 
all relevant information to end up with the binaries in question.


-David



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net