Your proposal for portaudio is good. As far as I'm concerned, go ahead and
commit it.

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.

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.

Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Sat, 28 Feb 2004 22:43:00 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4198] Added nreverb/reverb2; question about PortAudio


Hi all,

I checked in a new entry2.c that has entries for nreverb and reverb2
opcodes as well as the required functions reverbx and reverbx_set.

I went try to realtime render and got confused as to why it wasn't
working. I had to grep around quite a bit.  (The use of macros continues
to obfuscate the code for me and confuse me as what everything really
is, i.e. rtout_dev is defined as part of CENVIRON now, though it looks
like a global variable when reading the code in rtpa.c (my own gripe
about all of these macros, feel free to ignore)).  So, yes, it seems
that from the code that a portaudio device number is required after
"dac" or "devaudio", i.e. for me to use device 1 for output I had to use
"-o dac1".  If this was mentioned before, sorry I missed it, but I
didn't see a single mention of this new feature.  

Also, rtout_dev defaults to 1024, but needs to be set to a device number
between 0 and (Pa_GetDeviceCount()-1).  (rtout_dev in the CENVIRON gets
used as the the PaDeviceIndex in PaStreamParameters struct as I
understand how the code was done).  Any objection to using device 0 as a
default if no device was given on the commandline as well as a message
to the user that no device was selected?  In my case, I had no idea
using "-o dac" required anything else beyond the dac.  The proposed
change then would be in the code in rtpa.c that opens the streams to
report "No DeviceId given, defaulting to device 0." and to set the
paStreamParameters_.device = 0 instead of 1024.  If no objections I'll
go ahead and commit.

Thanks all,
steven

p.s. - After adding nreverb and using -o dac0, things seem to be running
in realtime without any problems at all.  This is great!  I'm very
excited that this is working for me.  I'll be trying out more projects
with csound5 tonight and tomorrow for testing.

p.p.s. - Regarding the request for an extra opcode module in the CVS,
considering I've had only one response to just add to the csound5 cvs,
I'd like to ask, what should I call the directory?  There's already
Opcodes, so perhaps OpcodeLibraries?  (with all external opcode libs
added to that directory)  That seems confusing but I can't think of
anything else.


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

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