In reality, the best solution to the macro problem (and, also, the
multi-instancing problem) would be to make Csound a C++ program. Not to
rewrite the whole thing - which would be crazy, if you ask me - but to make
ENVIRON a true C++ class. Then the C++ compiler does exactly the same
thing, with perfect reliability and accuracy, that we are trying to
simulate with these macros.

(Note that I care much less about this proposal than I do about getting
Csound 5 into release.)

In other words, rather than having a whole bunch of C++ classes as would be
required for a thoroughly object-oriented solution, have _one_ ENVIRON or
CSOUND class that would have, as member functions, all the Csound API
functions plus all the internal Csound functions and, as member variables,
all the current global objects in Csound.

These objects would move into scope of the member functions, so the only
source code changes that should be required would be
CSOUND::function(arg1,arg2...) in place of function(ENVIRON*,arg1,arg2...).
Inside the opcode functions, the csdl.h macros would remain, and for the
Csound member functions, very little source changes would be required.

Alternatively, the opcodes also could become C++ classes, in which case the
csdl.h macros would either change, or go away entirely, also leaving very
little change in function sources.


Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Sun, 29 Feb 2004 10:58:53 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4203] RE: Added nreverb/reverb2; question
aboutPortAudio


On Sun, 2004-02-29 at 07:49, gogins@pipeline.com wrote:
> Your proposal for portaudio is good. As far as I'm concerned, go ahead and
> commit it.

Sounds good.  I'm taking my laptop out to do some work at a cafe, so
will make the change and commit later tonight.

> About macros, I agree in principle but not necessarily in this case. John
> Fitch in csdl.h has provided a clever solution whereby existing opcode
> source code can be re-used for plugin opcodes. Not using these macros
would
> require extensive recoding that also would make the opcode sources less
> easy to read.

Sorry, yes, I understand the use of the macros and it is *REALLY* a
clever solution to the problem of migrating the existing work.  But I
think it gets confusing for the work ahead, and it was just me being
tired and grumpy over having to grep around so much to figure out what
was going on. =)  

> I would, however, like to get rid of as many macros as possible. I would
> also advise the authors of new plugin opcodes NOT to use csdl.h, but to
use
> cs.h and the complete spelling of the calls.

I like your proposal to not use csdl.h for future opcodes; I used cs.h
in the fluidOpcodes opcode lib I built and will likely do the same when
I port it over to csound5 today.  I think I'll try converting Loris over
as an opcode lib as well and will also use cs.h.

The full spelling does make the code very hard to read though, but the
macro's as they are are confusing too.  Maybe a different macro, such
as:

#define CENVIRON(data) (data->h.insdshead->csound)

would be enough to be convenient and succinct as well. It also makes the
code a bit easier to understand I think, as it makes sense of what the
pointer is we're grabbing.  I'll probably use this in the fluid rewrite
today, though something like this as a part of cs.h would be nice.  (I
think Matt suggested something like this if not this exactly a while
back.)

steven


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .