Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:5121] New Mac file releases and CVS imports

Date2004-07-30 08:31
FromAnthony Kozar
Subject[CSOUND-DEV:5121] New Mac file releases and CVS imports
There is now a "csoundmac" release package on Sourceforge. (Thanks John!)  I
plan to make this package a "one-stop shop" for MacOS users of Csound.  To
get used to making file releases, I went ahead and released two versions of
a "Mac Cscore SDK" which I created earlier this month.  These files contain
everything a Mac user with CodeWarrior might need to easily create Cscore
programs.

I expect to be releasing a new Mills csound version based on canonical
4.23f12 early next week.  To facilitate the development of future versions
of Csound for MacOS, I have created a new "macintosh" module in CVS.  I have
imported the Mac-only sources for Perf including project files (currently
only for Csound 4).  There is a ReadMe for the Mac sources and a separate
ChangeLog for changes to the Mac-only files.

I did a fresh checkout of both the csound and macintosh modules (both are
needed to build Perf) and rebuilt everything from scratch successfully.  So
this is the first MacOS 9 version of Csound built completely with files
obtained from CVS.  I am very excited that everything is finally in place to
be able to do this!!

I will be adding the Mills Front End sources to the macintosh module soon.
For the 4.23f12 Mac release, I have decided to remove the OMS Midi support
due to the potential licensing conflicts I have discussed previously.  I
haven't tried building this way yet but I don't think it will be too
difficult.  So -- heads up! -- no Midi on MacOS 9 until a solution can be
engineered.

For Matt Ingalls:

I am hoping that you will want to share the csoundmac release package and
macintosh CVS module.  If you want to add releases of CsoundLib/CsoundLibX,
OS X command-line binaries, or even MacCsound (!) that would be great!  I am
setting up the Mills Front End and Perf files as separate subdirectories of
the CVS module and you could add each independent project of yours as a
subdirectory as well.  Note that I am not copying the canonical source code
into the macintosh module, though.  I have set up my CodeWarrior project
files to expect the two modules to be checked out "side by side."


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/


PS.  Thanks to John ffitch, John Ramsdell, and Michael Gogins for all of
their support in helping me make it this far :)

Date2004-07-30 18:33
From"Matt J. Ingalls"
Subject[CSOUND-DEV:5122] Re: New Mac file releases and CVS imports

hi anthony

> I am hoping that you will want to share the csoundmac release package and
> macintosh CVS module.  If you want to add releases of CsoundLib/CsoundLibX,
> OS X command-line binaries, or even MacCsound (!) that would be great!  I am

yes that would be cool.  also are you using mac_files.c?  that is probably 
the only mac-specific file we are both using and i have made some updates 
to it [which also requires some minor changes in sfheader.c or something]
i also created a new #ifdef scheme for mac - would you be cool with this:

MAC     /* all macs! classic & osx, cfm & macho - needed for things like sounddesignerII files */
__MACH__	/* OSX MACH-O defined by apple */
macintosh 	/* All CFM Mac Compiles (Classic and OSX) defined by apple */
mills_macintosh /* all mac compiles BEFORE OSX */
mills_macintosh /* Mills "Perf" port */


here is how my sysdep.h currently looks:

#ifdef __MACH__
# define  MAC			/* all macs! classic & osx, cfm & macho */
# include 
#  define DIRSEP '/'
# define  SYS5
# define  WINDOWS
# define  RTAUDIO
//#define HAVE_FLTK

#elif defined(macintosh) /* All CFM Mac Compiles (Classic and OSX) */
# include 
# include        /* for open() etc protos on mac */
# include 
# define  SYS5
# define  SFDIGDES
# define  WINDOWS
# define  RTAUDIO
//# define  SFIRCAM // -- enabling this makes sd2 file support go away
# define  u_char  unsigned char
# define  u_short unsigned short
# define  u_int   unsigned int
# define  u_long  unsigned long
# define  O_NDELAY (0)
# define DIRSEP ':'
# define  MAC				/* all macs! classic & osx, cfm & macho */
# define mac_classic
//# define mills_macintosh /* DEFINE THIS to COMPILE the Mills"Perf"Version */
# ifdef mills_macintosh
#  define exit(x) die("");
# endif
#elif defined(SYMANTEC)

Date2004-08-03 04:56
FromAnthony Kozar
Subject[CSOUND-DEV:5136] Re: New Mac file releases and CVS imports
Hi Matt, 

Sorry that it took me so long to reply ... I was out of town.

On 7/30/04 1:33 PM, Matt J. Ingalls etched in stone:

>> I am hoping that you will want to share the csoundmac release package and
>> macintosh CVS module.

> yes that would be cool.

Great!  I am very glad that you want to start moving your code to
Sourceforge.  :)

> also are you using mac_files.c?  that is probably
> the only mac-specific file we are both using and i have made some updates
> to it [which also requires some minor changes in sfheader.c or something]

I am not familiar with any file named mac_files.c.  I have a file named
tc_files.c which includes the support for Sound Designer files, I think.
If you have updates to it, I certainly would be interested.

> i also created a new #ifdef scheme for mac - would you be cool with this:
> 
> MAC     /* all macs! classic & osx, cfm & macho - needed for things like
> sounddesignerII files */
> __MACH__    /* OSX MACH-O defined by apple */
> macintosh     /* All CFM Mac Compiles (Classic and OSX) defined by apple */
> mills_macintosh /* all mac compiles BEFORE OSX */
> mills_macintosh /* Mills "Perf" port */

I think MAC is ok.  I didn't know that macintosh is defined for CFM on OS X.
That is confusing to me.  What is the correct way to detect that one is
compiling for pre-OS X (using Apple or compiler defines)?  "mac_classic" is
still tested for in many places, and should be defined after detecting OS 9,
I think.

I am currently using mills_macintosh a little bit differently than you are.
I am using it to define that the Mills version is being built, but I am
assuming that it will be possible to have non-Mills targets on OS 9 in the
future.  For example, I would not define for an OS 9 CsoundLib and I hope
someday to make Csound buildable as an MPW tool.

Already, I have compiled standalone console versions of scsort, scxtrct,
scot, and cscore.  And when doing so, I do not define mills_macintosh
because that includes a lot of unnecessary code.  I have also modified
Csound 4 CVS to undefine it and placed the definition of mills_macintosh in
a prefix file (Prefix.h) for compiling with CodeWarrior (since CW does not
allow "command line" macro definitions).

So I would prefer some way to distinguish between Mills and non-Mills builds
on OS 9.
  
> here is how my sysdep.h currently looks:
> 
> #ifdef __MACH__
> # define  MAC            /* all macs! classic & osx, cfm & macho */
> # include 
> #  define DIRSEP '/'
> # define  SYS5
> # define  WINDOWS
> # define  RTAUDIO
> //#define HAVE_FLTK
> 
> #elif defined(macintosh) /* All CFM Mac Compiles (Classic and OSX) */
> # include 
> # include        /* for open() etc protos on mac */
> # include 
> # define  SYS5
> # define  SFDIGDES
> # define  WINDOWS
> # define  RTAUDIO
> //# define  SFIRCAM // -- enabling this makes sd2 file support go away
> # define  u_char  unsigned char
> # define  u_short unsigned short
> # define  u_int   unsigned int
> # define  u_long  unsigned long
> # define  O_NDELAY (0)
> # define DIRSEP ':'
> # define  MAC                /* all macs! classic & osx, cfm & macho */
> # define mac_classic
> //# define mills_macintosh /* DEFINE THIS to COMPILE the Mills"Perf"Version */
> # ifdef mills_macintosh
> #  define exit(x) die("");
> # endif
> #elif defined(SYMANTEC)

Here is what is currently in CVS:

#if defined(macintosh)
# define mac_classic /* All Mac Compiles Before OSX, including Carbon */
/* # define mills_macintosh /\* DEFINE THIS to COMPILE the
Mills"Perf"Version *\/ */
# include 
# include        /* for open() etc protos on mac */
# ifndef __MRC__
#  include 
# endif
# define  SYS5
# define  SFDIGDES
# define  WINDOWS
# define  RTAUDIO
/*# define  SFIRCAM*/
# define  u_char  unsigned char
# define  u_short unsigned short
# define  u_int   unsigned int
# define  u_long  unsigned long
# define  O_NDELAY (0)
# ifdef mills_macintosh
#  define exit(x) die("");
# endif
# define DIRSEP ':'
#elif defined(SYMANTEC)


And then I have the following in Prefix.h:

/*    Prefix.h file for the Mac Mills version of Csound   */

#include    

#define    mills_macintosh         /* Compile the Mills "Perf" Version */


I have also defined a macro called STANDALONE_CSCORE in my Cscore
distribution in order to get around a couple of other problems.  I suspect
that the distinction between mac_classic and mills_macintosh in the code
really needs to be made more clear.  Finally, we could probably abandon the
SYMANTEC code at this point.  I really doubt that it would be an issue for
anyone any longer.


One last thing, Matt.  Did you ever have a functioning build of Perf on 68K
Macs ?  I have been unsuccessful at producing anything other than a crashing
executable.  I tried several of the 68K builds from Bath ftp and they crash
also.  I went all the way back to the oldest working source code I could
find of yours (3.494_PPC) and the 68K target you had in the project also
crashed when built.  So I have been assuming it never worked.

I doubt that anyone cares about 68K Mac support anymore.  But I do have some
old Macs that I can test on if necessary and was just trying to be
"thorough".

Thanks.

Anthony

Date2004-08-03 17:56
From"Matt J. Ingalls"
Subject[CSOUND-DEV:5139] Re: New Mac file releases and CVS imports
>
> I am not familiar with any file named mac_files.c.  I have a file named
> tc_files.c which includes the support for Sound Designer files, I think.
> If you have updates to it, I certainly would be interested.

same thing. i think i renamed it mac_files.c when i got it carbon
compatible..


>> mills_macintosh /* all mac compiles BEFORE OSX */
>> mills_macintosh /* Mills "Perf" port */

> I think MAC is ok.  I didn't know that macintosh is defined for CFM on 
OS X.
> That is confusing to me.  What is the correct way to detect that one is
> compiling for pre-OS X (using Apple or compiler defines)?  "mac_classic" 
is
> still tested for in many places, and should be defined after detecting 
OS 9,
> I think.

woops somehow you have a typo [two mills_macintoshes] -- but it is right
below!??  i think we should use

#ifdef mac_classic

for all non-carbon cfm [aka pre os-x] compiles

i dont know if there really is a macro for pre-osx -- there maybe
for carbonized apps, i do run this
check at runtime to see if im running in osx or classic:

// This code taken from DTS Q&A OV03 "Detecting Classic and Carbon X 
Environment".
// = 0x01000);

if (mRunningOnOSX)
         ...coraudio stuff...
else
         ...soundmanager stuff...


> One last thing, Matt.  Did you ever have a functioning build of Perf on 
68K
> Macs ?

no - when we got the code in 1995 the GOAL was to get it compiled for
PPCs.  we never supported 68k.
-- have you tried compiling just a commandline
inteface w/ it?


-mm

Date2004-08-11 08:28
FromAnthony Kozar
Subject[CSOUND-DEV:5187] Re: New Mac file releases and CVS imports
On 8/3/04 12:56 PM, Matt J. Ingalls etched in stone:

> woops somehow you have a typo [two mills_macintoshes] -- but it is right
> below!??  i think we should use
> 
> #ifdef mac_classic
> 
> for all non-carbon cfm [aka pre os-x] compiles

OK, good.  This is what I was already thinking.

>> One last thing, Matt.  Did you ever have a functioning build of Perf on
>> 68K Macs ?

> no - when we got the code in 1995 the GOAL was to get it compiled for
> PPCs.  we never supported 68k.
> -- have you tried compiling just a commandline
> inteface w/ it?

Thanks for clearing this up.  I was confused by the fact that the
documenation always referred to the Mills version as "Csound for Power
Macintosh" but that there are a series of 68K releases on Bath ftp.  As I
mentioned before though, none of the 68K releases seem to work.

I haven't tried to make a simple command-line version for 68K but I am not
going to worry about it anymore.  I currently am not aware of anyone trying
to run Csound on such old machines.

One more question for now.  Do you have code written for auto-loading opcode
plugins yet?  I wrote my own code for loading the plugins on OS 9 but I do
not want to duplicate any more of your efforts if I can avoid it :)

Thanks again.

Anthony

Date2004-08-11 21:07
From"Matt J. Ingalls"
Subject[CSOUND-DEV:5203] Re: New Mac file releases and CVS imports
> One more question for now.  Do you have code written for auto-loading opcode
> plugins yet?  I wrote my own code for loading the plugins on OS 9 but I do
> not want to duplicate any more of your efforts if I can avoid it :)

i implemented cfm library plugins a couple of years ago - worked on os9 
and osx - sent the code to john but it was never put in the sources - 
anyway your code looks pretty much the same, so thats cool..

was going to 
do opcodes as a bundle in mach-o, but it looks like the
linux dylib stuff compiles and works fine, so i dont think its worth 
it.
or are you talking about 
user-defined opcodes [csound code] that i at one point claimed that i was 
implementing it..


-m

Date2004-08-11 23:03
FromAnthony Kozar
Subject[CSOUND-DEV:5204] Re: New Mac file releases and CVS imports
On 8/11/04 4:07 PM, Matt J. Ingalls etched in stone:

> 
>> One more question for now.  Do you have code written for auto-loading opcode
>> plugins yet?  I wrote my own code for loading the plugins on OS 9 but I do
>> not want to duplicate any more of your efforts if I can avoid it :)
> 
> i implemented cfm library plugins a couple of years ago - worked on os9
> and osx - sent the code to john but it was never put in the sources -
> anyway your code looks pretty much the same, so thats cool..

Well, that's good :)

> was going to 
> do opcodes as a bundle in mach-o, but it looks like the
> linux dylib stuff compiles and works fine, so i dont think its worth
> it.
> or are you talking about
> user-defined opcodes [csound code] that i at one point claimed that i was
> implementing it..

Actually, I was wondering if you had code to search a designated "Opcodes"
directory and load any opcode libraries that it finds there without the user
having to specify them on a command-line.  My code only loads libraries
named by the user.

Anthony