There is no hard and fast rule for Windows, therefore, my Windows installer simply copies the relevant parts of the csound CVS directory tree into Program Files/csound.

This is as close to standard as Windows gets, by the way.

DLLs also can go into Windows/System32.

I think most people with existing front ends to Csound aren't tracking, since their software already works by shelling out or through pipes. "If it works, and I'm busy with new projects, don't fix it." I find this understandable but regrettable.

Experience shows they aren't eager to change their code to use the API -- unfortunately, since few other things would be as good for Csound. 

I don't agree that metadata is necessary, but I do think it is desirable.

I think two packages for 32 and 64 bits is better than what we have now.

Do check in the Mac installer start.

Regards,
Mike



-----Original Message-----
From: Anthony Kozar 
Sent: Oct 14, 2005 2:07 AM
To: New Csound Developer list 
Subject: Re: [Cs-dev] Re: When can we release Csound 5 ??

Istvan Varga wrote on 10/13/05 4:21 PM:

> In fact, to even begin
> creating an installer, the first step is designing the general structure
> and layout of a Csound installation,

I thought that most of these issues were already decided.  Linux certainly
seems to _mandate_ most of these issues for you.  Matt and I have made
several suggestions about how things should be laid out on OS X.  I do not
know how Windows works though.  I suppose that we need a comprehensive
naming scheme for libraries and versions so that multiple csound libs can be
installed at the same time.  I imagine though that there are also standards
(or at least precedents) for these things on Linux and OS X as well.

> So, with all the issues left to be solved for so long time, is it
> a good idea to rush for a release in only a few weeks ?

Well, OK.  I may have been feeling a little overly _optimistic_ this
afternoon.  But the main purpose of my "speech" was hopefully to energize
and motivate people to really dig in and try to push for the finish line,
because I really do believe that it is in sight !!  (And has been for a few
months as you have pointed out).

>> **  Does everyone accept the current API?  Does it meet all of your
>> anticipated needs for your host applications?  What needs to change?

> Now this is the big question that so far was not really answered by
> anyone. 

Well, there has been a significant amount of discussion, with suggestions
for additions.  So, that is an answer.  There has also been a lot of silence
from people that have a large stake in the API.  That could be taken as
tacit assent to the current state of the API OR it could mean that people
are too busy to follow this list.

I think it may be a good idea to directly email some of the people who
maintain existing front ends for Csound 4 and ask them to review the Csound
5 API.  We need their feedback, otherwise we may be encouraging a situation
that will prevent Csound 5 from being a unified base for everyone's work.

I suggest that we email Matt Ingalls, Gabriel Maldonado, Jean Piche, and
possibly John Ramsdell directly to ask for their feedback.  Soliciting the
feedback of others who may potentially have an interest might not be a bad
idea either.  Maybe Rick Taube, Steven Beck, the developers of athenaCL, AC
Toolbox, ... any developer of a major computer music system that has output
for Csound or maybe has always wanted to interact with Csound more easily.

> A GUI installer for Windows already exists, and is used by the Gogins
> SourceForge releases.

Ok.  Let's run with that.

> So far no attempts were made at an installer for any Mac platform.

Any Mac installer should have a GUI and would do best to work in a standard
way.  The easiest way to achieve this would be to use Apple's packaging and
installer tools.  I have used them to package up Csound GBS by hand.  There
is a GUI packager, but once you figure out how it should work, the whole
process can be automated with a command-line script.  Hans Steiner created
an example of how to do this with the Csound 4.23f07 release he created for
the Cecilia project and I have a copy of his code.  Maybe I should check
this into CVS as a starting point?
 
> For distributing Linux packages,
> using the native package formats of distributions (rpm, deb, etc.) may
> be an option; of course, we would need several packages, one for each
> distribution, but that is likely to be needed anyway due to binary
> compatibility issues.

Of course, we should use whatever standards exist for Linux.  I am no
expert, but most distros I have seen can make use of either RPM or DEB
packages, right?  Using standard package formats also allows users to use
whatever GUI tools they might have on their Linux for installation.  (I know
Gentoo is weird, and perhaps others too.  But someone on the list
volunteered to create a Gentoo package I think).
 
> Of course, regardless of how a release is packaged, the question of
> what is to be packaged still remains, including the already mentioned
> issues of required libraries, directory structure, environment variables,
> floats vs. doubles, libcsound and headers for development, optionally
> manual and source code, etc.

Csound is essentially a software development package now, right?  So, I
would think it is clear that we need to install static and dynamic
libraries, along with headers, and something into /usr/local/share to at
least indicate where to find the manual.  The command-line front-end is the
"example" program and of course all standard plugins in CVS will be
installed.

The main issue I imagine is 32-bit vs. 64-bit.  I would tend to say "install
both" but that may make the package too big.  If so, make two packages.
Simple.

In a binary release, I see no reason not to include all of the "extras" that
apply to a particular platform:  vst4cs, dssi4cs, stk opcodes, python
opcodes, high-level wrappers, CsoundVST, etc.

I think that important libraries like PortAudio, FLTK, PortMIDI (and
libsndfile on non-Linux) should be statically linked into the Csound
binaries to avoid "dependency hell" and incompatibility problems.

>> ** Michael needs to complete and incorporate the various language wrappers.

> This is definitely not an approach I like, particularly the idea of
> possibly reverting something after the release.

I wasn't suggesting reverting after the release.  I think a lot the
discussion over this matter boils down to miscommunication.  If Mike adds
his code to the library soon, we can all make sure that we can still build
Csound before any release is made.  If there is a problem, it can be fixed
or undone before a release.  But I think we have discussed it to death and
it should just be done so we can all see how it will work!

>> ** We need to make a final decision on the metadata issue.

> Well, my proposal is simple and easy to implement in that it is
> not to have additional opcode metadata.

Yes, well, those of who are interested in creating user-friendly front-ends
for Csound accept that this is necessary.  My own private conversations with
Matt Ingalls and comments made on this list not very long ago by Jean Piche
have made it clear, I think, that this will be very useful.  And I believe
that MacCsound and Cecilia make Csound accessible to a MUCH wider audience,
so we should support their efforts!!

> The loading of named GEN routines is not really elegant, although
> it works; it does not seem to be used extensively, though, that is
> why suggestions to change it were not made so far.

It is not used because it is a brand new mechanism that was hacked in to
deal with some "missing" GENs from Gab and Victor.  And those GENs should
probably just be assigned permanent numbers and be added to fgens.c. The
usefulness of the ability for plugins or hosts to add named GENs will not be
fully evident until after the release of Csound 5, I think.  We should
strive for a better interface though so that it IS used by people.  I think
this needs two solutions:  a better mechanism for loading GENs from plugins,
and an API function for a host app to add a GEN, similar to the AddOpcode
call.

> There are of course quite a few static and extern variables
> that obviously need to be removed eventually, mostly in crufty old code,
> or some very ugly files that would need major changes (examples include
> the SoundFont opcodes and FLTK widgets) and thus were not touched yet.
> Nevertheless, important major parts like the parser, audio and MIDI I/O,
> event processing (insert.c, musmon.c, etc.), and much of the opcode
> libray are known to be clean.

We are all very grateful to you, Istvan, and anyone else who worked on this
for doing the tough work of making Csound multiply-instantiable!

I know that Cscore will not work yet though with multiple instances, and
there may be other features as well.  (Soundfonts as you mention).  Some of
these may not have to be fixed before a release, although all should be
eventually, of course.  I could try to fix up Cscore as I have time.  (It
doesn't quite work in single-instance mode yet either).

Maybe you could identify for us which statics should NOT be removed?

Thanks for all of the feedback.  I am still hoping that we can all begin to
move again towards the finish line!  We can get there fairly soon (months) I
think.  (Let's just not be TOO hasty to push an incomplete Csound 5 out the
door!)


Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
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

On Oct 14, 2005, at 9:56 AM, Michael Gogins wrote:

> There is no hard and fast rule for Windows, therefore, my Windows 
> installer simply copies the relevant parts of the csound CVS directory 
> tree into Program Files/csound.

> Do check in the Mac installer start.

I mean, FWIW, I think 90% of all Mac "installers" consist of a disk 
image file (*.dmg) which is mounted by the user and contains a single 
*.app which can be dragged anywhere.

The "Package Maker" program that comes in Apple's developer tools only 
copies the files to a specified directory as well.

The question then becomes "what are 'reasonable defaults'" for this? 
/usr/local/bin or /usr/bin ??

IMHO to make an installer with Package Maker is quite a trivial matter 
and is easily implemented. However, is a more "platform independent" 
method such as Steven Yi's Java based installer (a lá Blue) preferred?


-David


-------------------------------------------------------
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

David Akbari wrote on 10/14/05 10:37 AM:

> I mean, FWIW, I think 90% of all Mac "installers" consist of a disk
> image file (*.dmg) which is mounted by the user and contains a single
> *.app which can be dragged anywhere.

Yes.  I think Csound for OS X should be distributed as a .dmg.  But it
requires a real installer package, since there is no .app to drag and drop.

> The "Package Maker" program that comes in Apple's developer tools only
> copies the files to a specified directory as well.

I believe that it can do more than that.  Most importantly, it is possible
-- if you build the package very carefully -- to have it preserve and
reconstruct the resource forks of any files that have them upon
installation.  This is VERY important for Csound when using FLTK on OS X.

I managed to make an installer package for Csound GBS that did this.  The
biggest pain though was not being able to easily specify when an admin
password is or is not necessary.

> The question then becomes "what are 'reasonable defaults'" for this?
> /usr/local/bin or /usr/bin ??

What do you think the default should be?  (since you are probably our most
vocal OS X user/tester)   /usr/local/bin makes more sense from a Unix
perspective and would be consistent with Linux.  The problem is that
/usr/local/bin is not on the default path in OS X.  Or, that is the case at
least in 10.2 -- do you know if it has changed in later versions?  /usr/bin
is the "safest" place to install things for users who are command-line
newbies, because it will "just work."  We also need to consider though that
Matt has designated a folder in /Library/Application Support/ for plugins --
i.e. he is not using /usr/local/lib.

But I think the installer should also give the option of installing anywhere
the user wants, including in their home directory.  And it should be smart
enough to ask for a password when installing somewhere owned by root but not
demand one when installing somewhere the user owns.  This is necessary for
students who may not have complete access to a machine.  (And Apple's GUI
package maker does not allow both options in the same package, from what I
can tell).

> IMHO to make an installer with Package Maker is quite a trivial matter
> and is easily implemented. However, is a more "platform independent"
> method such as Steven Yi's Java based installer (a lá Blue) preferred?

I really would prefer to avoid any attempts at a cross-platform installer.

Finally, whoever ends up packaging for OS X should make sure to set their
compiler to be compatible with older versions of OS X if necessary.  The
default with each new OS upgrade is to break backwards compatibility.  We
should be compiling for 10.2 and later (maybe even 10.1 unless the CoreAudio
API is not complete in that version).

Anthony



-------------------------------------------------------
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

On Oct 15, 2005, at 1:23 AM, Anthony Kozar wrote:

>> The question then becomes "what are 'reasonable defaults'" for this?
>> /usr/local/bin or /usr/bin ??
>
> What do you think the default should be?  (since you are probably our 
> most
> vocal OS X user/tester)   /usr/local/bin makes more sense from a Unix
> perspective and would be consistent with Linux.  The problem is that
> /usr/local/bin is not on the default path in OS X.  Or, that is the 
> case at
> least in 10.2 -- do you know if it has changed in later versions?  
> /usr/bin
> is the "safest" place to install things for users who are command-line
> newbies, because it will "just work."  We also need to consider though 
> that
> Matt has designated a folder in /Library/Application Support/ for 
> plugins --
> i.e. he is not using /usr/local/lib.

I use /usr/local/bin. But it's also worth noting that I'm still holding 
on to the "rock solid FLTK release May 16 2005" which lives in 
/usr/local/bin and I run the CVS builds from the build directory. (In 
my case ~/CVS/csound5, just as an example.)

There is a way to append the $PATH in OSX which I have done and it has 
allowed me to automatically set OPCODEDIR, OPCODEDIR64, INCDIR, etc. in 
addition to appending the /usr/local/bin to the default PATH. It's 
likely a simple shell script can be created to append the .cshrc or 
whatever file corresponds to the user's preferred shell.

> I think the installer should also give the option of installing 
> anywhere
> the user wants, including in their home directory.  And it should be 
> smart
> enough to ask for a password when installing somewhere owned by root 
> but not
> demand one when installing somewhere the user owns.  This is necessary 
> for
> students who may not have complete access to a machine.  (And Apple's 
> GUI
> package maker does not allow both options in the same package, from 
> what I
> can tell).

Here's a question, when Csound5 is eventually released, will it be 
possible to run it using AppleScript (do shell script "*.sh")? (ie NOT 
with the Terminal.app) because I'd really like to see them install 
Csound5 on all the computers in the labs at Berklee but the thing is 
they've totally locked out the Terminal.app (fear of students changing 
grades... I know, LOL right?)

What other options exist besides the "Package Maker"? (Personally I 
don't mind SConstruct...)


-David



-------------------------------------------------------
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

Done.  The files showing how Hans Steiner was able to create a "proper"
MacOS X installer for Csound 4 are now in the Csound 5 repository under the
/installer/macosx/  directory.  I hope that this gives someone a good start
on making the Cs5 installer.  I would be happy to test the installer and the
packaging scripts and to provide feedback on if they meet standards for
usability on the Mac.

Also, I committed my code to csmodule.c for loading plugins on MacOS 9.

Anthony


Michael Gogins wrote on 10/14/05 9:56 AM:

> Do check in the Mac installer start.



-------------------------------------------------------
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

David Akbari wrote on 10/15/05 2:38 AM:

> It's 
> likely a simple shell script can be created to append the .cshrc or
> whatever file corresponds to the user's preferred shell.

This is a possibility, but my shell scripting abilities are not up to the
task.   Plus, it would have to be "smart" enough not to add the directory to
the PATH if it is already there.

> Here's a question, when Csound5 is eventually released, will it be
> possible to run it using AppleScript (do shell script "*.sh")?

I have no idea.  If you can control other command-line apps this way, then I
would imagine that scripting Csound will work fine.

(Note that Mills Csound is AppleScriptable :)

> What other options exist besides the "Package Maker"? (Personally I
> don't mind SConstruct...)

It is really just the GUI for the Package Maker that is limiting, I think.
If one uses the existing command-line tools, and learns to write good
package scripts, then I think that a lot more can be done with Apple's
installer.

This is the route to go anyways since using the GUI has to be done manually,
and we want an automatic packaging mechanism controllable from SCons.

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/



-------------------------------------------------------
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