Greetings:

  I've run into this trouble before, so it's worth pointing out again. 
This fragment (from H/csoundCore.h) fails under GCC 3.2.2:

<<<<<<< csoundCore.h
  FUNC   *ftfind(struct ENVIRON_*,MYFLT*);

#define MAXCHAN       16        /* for 6 ports */
=======
#define MAXCHAN 16      /* 16 MIDI channels; only one port for now */
 >>>>>>> 1.68

  I assume this is just badly formatted, but am I correct also to assume 
that the FUNC line should remain along with one of the #define statements ?

Best,

dp




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Following on from last week's discussion, I'd suggest that csdl.h, cs.h
and oload.c in the 4.23 versions should be edited to provide a minimal 
interface for plugin
opcodes, without which the whole thing is pretty much dead on the ground.

I have done these changes to my windows and will do to the linux 
distributions, but
perhaps the GBS package should offer it as well. I don't see it as breaking the
code freeze.

Here's the suggested changes.

csdl.h:

adding the following lines

#define auxalloc pcglob->auxalloc_
#define getstring pcglob->getstring_
#define die pcglob->die_
#define ftfind pcglob->ftfind_
#define initerror pcglob->initerror_
#define perferror pcglob->perferror_
#define mmalloc pcglob->mmalloc_
#define mcalloc pcglob->mcalloc_
#define mfree pcglob->mfree_
#define dispset pcglob->dispset
#define display pcglob->display
#define intpow pcglob->intpow_
#define ftfindp pcglob->ftfindp
#define ftnp2find pcglob->ftnp2find
#define unquote pcglob->unquote
#define ldmemfile pcglob->ldmemfile
#define err_printf pcglob->err_printf_

CS.h:

add the following lines to the GLOBALS struct,
perhaps after  the line containing void (*SetRtcloseCallback)(void *csound, 
void (*rtclose__)(void));

   void (*auxalloc_)(long nbytes, AUXCH *auxchp);
   char *(*getstring_)(int, char*);
   void (*die_)(char *);
   FUNC *(*ftfind_)(MYFLT *);
   void (*initerror_)(char *);
   void (*perferror_)(char *);
   void *(*mmalloc_)(long);
   void *(*mcalloc_)(long);
   void (*mfree_)(void *);
   void (*dispset)(WINDAT *, MYFLT *, long, char *, int, char *);
   void (*display)(WINDAT *);
   MYFLT (*intpow_)(MYFLT, long);
   FUNC *(*ftfindp)( MYFLT *argp);
   FUNC *(*ftnp2find)( MYFLT *);
   char *(*unquote)(char *);
   MEMFIL *(*ldmemfile)(char *);
   void (*err_printf_)(char *, ...);

oload.c:

add these lines to initialise the GLOBALS structure, just before
/*
* Data fields.
*/:

  auxalloc,
  getstring,
  die,
  ftfind,
  initerror,
  perferror,
  mmalloc,
  mcalloc,
  mfree,
  dispset,
  display,
  intpow,
  ftfindp,
  ftnp2find,
  unquote,
  ldmemfile,
  err_printf,

I suspect Anthony Kozar has done something of the kind so that
plugins can work on SuperMills (not exactly sure if he made the same changes,
but they seem compatible to these).

Victor



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Dave Phillips wrote:

>  I've run into this trouble before, so it's worth pointing out again. 
> This fragment (from H/csoundCore.h) fails under GCC 3.2.2:
> 
> <<<<<<< csoundCore.h
>  FUNC   *ftfind(struct ENVIRON_*,MYFLT*);
> 
> #define MAXCHAN       16        /* for 6 ports */
> =======
> #define MAXCHAN 16      /* 16 MIDI channels; only one port for now */
>  >>>>>>> 1.68
> 
>  I assume this is just badly formatted, but am I correct also to assume 
> that the FUNC line should remain along with one of the #define statements ?

This is a CVS file conflict. Just delete the file and run cvs update again.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

No, I have not changed any code to support opcode plugins (other than adding
the shared library loading stuff to dl_opcodes.c and that is in CVS).  All
that I have done to make plugins work as expected is to create a symbol
export list in a file called Perf.cw4.mcp.exp.

This file lists almost every non-static variable and function in global
scope in all of Csound (over 2000).  I removed a few names which were
troublesome or clearly not needed but most are there.  Yes, this means that
in Mills Csound you can do ridiculous things like call musmon() from a
plugin.  But I decided to err on the side of having too many exported
symbols since I had no idea (back then) which symbols were needed.

In general, "SuperMills" contains very few changes to the cross-platform
Csound code and the Mills 4.23f12 release on Sourceforge is straight from
CVS.  Both support opcode plugins with all of the needed internal functions.

I would suggest that something similar be done for GBS, MacCsound, MyCsound,
etc. unless there is no desire to really support plugins with these
"flavors" until Csound 5.

I don't think that modifying the GLOBALS struct is a particularly good idea
though.  Since information about this struct may be compiled into existing
clients and plugins for Cs4, couldn't modifying the struct break them?

Anthony 

On 3/29/05 8:13 AM, Victor Lazzarini  etched in
stone:

> Following on from last week's discussion, I'd suggest that csdl.h, cs.h
> and oload.c in the 4.23 versions should be edited to provide a minimal
> interface for plugin
> opcodes, without which the whole thing is pretty much dead on the ground.
> [...]

> I suspect Anthony Kozar has done something of the kind so that
> plugins can work on SuperMills (not exactly sure if he made the same changes,
> but they seem compatible to these).



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini  writes:

> Following on from last week's discussion, I'd suggest that csdl.h,
> cs.h and oload.c in the 4.23 versions should be edited to provide a
> minimal interface for plugin opcodes,

> I have done these changes ...,
> but perhaps the GBS package should offer it as well.

As far as I know, the GBS distribution of Csound 4 already supports
plugin opcodes.  I myself was able to build and load the Loris opcodes
on Linux, and Kelly Fitz reports success on MacOS X.

The source version of Csound GBS builds the opcodes gabops, metro,
newfils, syncgrain, and vectorial, but you only get something usable
if you enable shared libraries.

Csound GBS allows the construction of opcodes without access to the
Csound sources.  The install process makes available everything
needed, including the headers.  The csound-config script can be used
to find the location of what's needed to build opcodes.  A little
autoconf magic allows a completely automated configuration for opcode
authors. 

Csound GBS does not use oload.c.  It uses load_opcodes.c.

Please send me a specific bug report if you find a problem building
and loading opcodes with Csound GBS.

John


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

John,

Hello.  Hope you are having a great day.

I am happy to hear about the plugin opcode success with Csound 4 GBS.

If Kelly was able to get the Loris opcodes to work at MacCsound plugins, do
you think you might be able to convince him to share these plugins with us?

Has anyone been able to use the GBS sources to build plugins that work with
MacCsound and are compiled with Xcode?

Dr. B.

on 3/30/05 7:17 PM, John D. Ramsdell at ramsdell@mitre.org wrote:

> Victor Lazzarini  writes:
> 
>> Following on from last week's discussion, I'd suggest that csdl.h,
>> cs.h and oload.c in the 4.23 versions should be edited to provide a
>> minimal interface for plugin opcodes,
> 
>> I have done these changes ...,
>> but perhaps the GBS package should offer it as well.
> 
> As far as I know, the GBS distribution of Csound 4 already supports
> plugin opcodes.  I myself was able to build and load the Loris opcodes
> on Linux, and Kelly Fitz reports success on MacOS X.
> 
> The source version of Csound GBS builds the opcodes gabops, metro,
> newfils, syncgrain, and vectorial, but you only get something usable
> if you enable shared libraries.
> 
> Csound GBS allows the construction of opcodes without access to the
> Csound sources.  The install process makes available everything
> needed, including the headers.  The csound-config script can be used
> to find the location of what's needed to build opcodes.  A little
> autoconf magic allows a completely automated configuration for opcode
> authors. 
> 
> Csound GBS does not use oload.c.  It uses load_opcodes.c.
> 
> Please send me a specific bug report if you find a problem building
> and loading opcodes with Csound GBS.
> 
> John
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: (617) 747-2485   Office Fax: (617) 747-2564
 +  eMail: rboulanger@csounds.com  or  rboulanger@berklee.edu
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Catalog with Audio @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  CsoundForums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

"Richard Boulanger"  writes:

> If Kelly was able to get the Loris opcodes to work at MacCsound
> plugins, do you think you might be able to convince him to share
> these plugins with us?

You don't need to ask him, you can just go to
http://sf.net/projects/loris and take the sources.  The stuff that
automatically configures itself for Csound GBS is only in the CVS
repository, but he allows anonymous CVS checkouts.

John


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar  writes:

> No, I have not changed any code to support opcode plugins (other
> than adding the shared library loading stuff to dl_opcodes.c and
> that is in CVS).

Csound GBS uses load_opcodes.c.  It uses dlopen on all platforms but
Windows.  You don't have to do anything to Csound GBS to get opcodes
to build and load on MacOS X.  I seems to work using the identical
code used on Linux.

John


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Modifying the ENVIRON struct doesn't break compatibility if thing are
added at the end of the struct, if I remember correctly (we discussed
this a couple years ago I think and I remember Michael Gogins
explaining something like this to me at the time).


On Wed, 30 Mar 2005 17:00:14 -0500, Anthony Kozar
 wrote:
> No, I have not changed any code to support opcode plugins (other than adding
> the shared library loading stuff to dl_opcodes.c and that is in CVS).  All
> that I have done to make plugins work as expected is to create a symbol
> export list in a file called Perf.cw4.mcp.exp.
> 
> This file lists almost every non-static variable and function in global
> scope in all of Csound (over 2000).  I removed a few names which were
> troublesome or clearly not needed but most are there.  Yes, this means that
> in Mills Csound you can do ridiculous things like call musmon() from a
> plugin.  But I decided to err on the side of having too many exported
> symbols since I had no idea (back then) which symbols were needed.
> 
> In general, "SuperMills" contains very few changes to the cross-platform
> Csound code and the Mills 4.23f12 release on Sourceforge is straight from
> CVS.  Both support opcode plugins with all of the needed internal functions.
> 
> I would suggest that something similar be done for GBS, MacCsound, MyCsound,
> etc. unless there is no desire to really support plugins with these
> "flavors" until Csound 5.
> 
> I don't think that modifying the GLOBALS struct is a particularly good idea
> though.  Since information about this struct may be compiled into existing
> clients and plugins for Cs4, couldn't modifying the struct break them?
> 
> Anthony
> 
> On 3/29/05 8:13 AM, Victor Lazzarini  etched in
> stone:
> 
> > Following on from last week's discussion, I'd suggest that csdl.h, cs.h
> > and oload.c in the 4.23 versions should be edited to provide a minimal
> > interface for plugin
> > opcodes, without which the whole thing is pretty much dead on the ground.
> > [...]
> 
> > I suspect Anthony Kozar has done something of the kind so that
> > plugins can work on SuperMills (not exactly sure if he made the same changes,
> > but they seem compatible to these).
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

I was just curious if anyone has tried using a (standalone) version of 
CsoundVST with fXpansion's proprietary "VST to AudioUnits" or "VST to 
RealTimeAudioSuite" format? I realize CsoundVST is a part of Csound5, 
and I was just curious.

Thanks,
-David

On Mar 31, 2005, at 10:52 AM, Steven Yi wrote:

> Modifying the ENVIRON struct doesn't break compatibility if thing are
> added at the end of the struct, if I remember correctly (we discussed
> this a couple years ago I think and I remember Michael Gogins
> explaining something like this to me at the time).
>
>
> On Wed, 30 Mar 2005 17:00:14 -0500, Anthony Kozar
>  wrote:
>> No, I have not changed any code to support opcode plugins (other than 
>> adding
>> the shared library loading stuff to dl_opcodes.c and that is in CVS). 
>>  All
>> that I have done to make plugins work as expected is to create a 
>> symbol
>> export list in a file called Perf.cw4.mcp.exp.
>>
>> This file lists almost every non-static variable and function in 
>> global
>> scope in all of Csound (over 2000).  I removed a few names which were
>> troublesome or clearly not needed but most are there.  Yes, this 
>> means that
>> in Mills Csound you can do ridiculous things like call musmon() from a
>> plugin.  But I decided to err on the side of having too many exported
>> symbols since I had no idea (back then) which symbols were needed.
>>
>> In general, "SuperMills" contains very few changes to the 
>> cross-platform
>> Csound code and the Mills 4.23f12 release on Sourceforge is straight 
>> from
>> CVS.  Both support opcode plugins with all of the needed internal 
>> functions.
>>
>> I would suggest that something similar be done for GBS, MacCsound, 
>> MyCsound,
>> etc. unless there is no desire to really support plugins with these
>> "flavors" until Csound 5.
>>
>> I don't think that modifying the GLOBALS struct is a particularly 
>> good idea
>> though.  Since information about this struct may be compiled into 
>> existing
>> clients and plugins for Cs4, couldn't modifying the struct break them?
>>
>> Anthony
>>
>> On 3/29/05 8:13 AM, Victor Lazzarini  
>> etched in
>> stone:
>>
>>> Following on from last week's discussion, I'd suggest that csdl.h, 
>>> cs.h
>>> and oload.c in the 4.23 versions should be edited to provide a 
>>> minimal
>>> interface for plugin
>>> opcodes, without which the whole thing is pretty much dead on the 
>>> ground.
>>> [...]
>>
>>> I suspect Anthony Kozar has done something of the kind so that
>>> plugins can work on SuperMills (not exactly sure if he made the same 
>>> changes,
>>> but they seem compatible to these).
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The reason I have changed the GLOBALS structure is that it
seemed the most logical way to give access to auxalloc etc., without
having to build a library with these functions to link them. That's the
way csound5 was working before the latest improvements.

The changes did not seem to break my windows version. The plugin opcode
code seems also to be compatible with the other cs4.23 versions.

If GBS supports plugins and it allows us to link to auxalloc etc., no changes
are needed.

Victor

At 23:00 30/03/2005, you wrote:
>No, I have not changed any code to support opcode plugins (other than adding
>the shared library loading stuff to dl_opcodes.c and that is in CVS).  All
>that I have done to make plugins work as expected is to create a symbol
>export list in a file called Perf.cw4.mcp.exp.
>
>This file lists almost every non-static variable and function in global
>scope in all of Csound (over 2000).  I removed a few names which were
>troublesome or clearly not needed but most are there.  Yes, this means that
>in Mills Csound you can do ridiculous things like call musmon() from a
>plugin.  But I decided to err on the side of having too many exported
>symbols since I had no idea (back then) which symbols were needed.
>
>In general, "SuperMills" contains very few changes to the cross-platform
>Csound code and the Mills 4.23f12 release on Sourceforge is straight from
>CVS.  Both support opcode plugins with all of the needed internal functions.
>
>I would suggest that something similar be done for GBS, MacCsound, MyCsound,
>etc. unless there is no desire to really support plugins with these
>"flavors" until Csound 5.
>
>I don't think that modifying the GLOBALS struct is a particularly good idea
>though.  Since information about this struct may be compiled into existing
>clients and plugins for Cs4, couldn't modifying the struct break them?
>
>Anthony
>
>On 3/29/05 8:13 AM, Victor Lazzarini  etched in
>stone:
>
> > Following on from last week's discussion, I'd suggest that csdl.h, cs.h
> > and oload.c in the 4.23 versions should be edited to provide a minimal
> > interface for plugin
> > opcodes, without which the whole thing is pretty much dead on the ground.
> > [...]
>
> > I suspect Anthony Kozar has done something of the kind so that
> > plugins can work on SuperMills (not exactly sure if he made the same 
> changes,
> > but they seem compatible to these).
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net