On Oct 13, 2006, at 7:13 AM, Steven Yi wrote:

> HI All,
>
> Regarding Dave Akbari's new opcodes (very much enjoying logcurve,
> btw!), I have just gotten around to working with them and had a couple
> suggestions for changes:
>
> 1)the gainslider opcode documentation mentions:
>
> "There is no bounds in the source code so you can for example give
> higher than 127 values for extra amplitude but possibly clipped
> audio."
>
> but the code given does seem to have bounds and also a possible bug 
> situation:
>
> int gainslider_init(CSOUND *csound, gainslider *p)
> {
>     *p->koutsig = GAINSLIDER((MYFLT) *p->kindex);
>
>     return OK;
> }
>
> int gainslider_perf(CSOUND *csound, gainslider *p)
> {
>
>     if (*p->kindex >= FL(0.0) && *p->kindex <= FL(152.0)) {
>       *p->koutsig = GAINSLIDER((MYFLT) *p->kindex);
>   }
>
>   return OK;
> }
>

Ah yes, the if statement was a residual from working with the same 
formula in other environments. In practice, values higher than 152 will 
make an audio signal distorted beyond recognition but in the Csound 
implementation I do not believe there should be such a limitation; I 
very much like the change you suggest below.

> For the init method, it does an initialization of the value against a
> kindex, but kindex may not be initialized at i-time.  If this happens,
> and kindex later at k-time is a value below 0 or above 152, the
> koutsig is always going to return the value from the init.  Now, this
> is a question I don't know the answer to: is a k-rate variable
> initialized to 0 when the pointer is allocated or is it just
> allocated?  I'd like to propose the init function be removed and the
> performance function be changed to:
>
> int gainslider_perf(CSOUND *csound, gainslider *p)
> {
>
>     if(*p->kindex <= FL(0.0)) {
>         *p->koutsig = FL(0.0);
>     } else {
>         *p->koutsig = GAINSLIDER((MYFLT) *p->kindex);
>    }
>
>    return OK;
> }
>
> This will also alleviate if ksmps is high and ksig happens to jump
> from a valid value to an invalid value (in the old code) that the last
> value from gainslider isn't being returned.
>
> 2)the logcurve, expcurve, and scale init functions also don't seem
> necessary as they're operating on a kval which may not be initialized.
>  These could probably removed as they're not doing any initial
> precalculations of state data or anything like that, and the thread
> for the OENTRY can be changed to 2.
>

The initial idea was to make them both i and k-rate as long as it is 
feasible to do code like

k1 init 0.55
k2 init 8

kout  logcurve  k1, ksteep

in the absense of proper i-rate initialization, it should be ok to 
remove the i-rate stuff right?

> 3)The documentation to logcurve mentions ksteepness should not be <=
> 1, but doesn't mention much in regards to how that value affects the
> generated curve.  I had to look at the formula and run some data
> through using different steepness values to figure out that values
> closer to 1 make it steeper while higher values flatten out the curve
> (is that right?).  If so, I think adding a little more text to
> describe that parameter will make it a little more intuitive to those
> first coming across the opcode (which, btw, has become my favorite
> opcode of the day! Thanks Dave!).  Also, should we add the formula for
> this opcode into the documentation?  I imagine some users who are
> mathematically savvy but aren't interested to dig into the code might
> want to know what the formula is to plot out curves for themselves to
> find what they're looking for.
>

Definitely adding the formula into the manual page is a good idea. In 
regards to the steepness parameter, a value of 1.00001 will give almost 
a straight line and values like 8, 16, 256, etc will give curves of 
increasing steepness. I don't believe there is a limit to how steep the 
curve can be.

> 4)Same general comments as 3 but for expcurve (with the info flipped
> for suggested values for steepness)
>
> 5)expcurve code seems to be wrong to me!  This is the macro defined in 
> ugakbari:
>
> #define EXPCURVE(x,y) (exp(x * log(y))-1/(y-1))
>
> while the UDO code is:
>
> kout	=	(exp(kfloat * log(ksteep)) - 1)/(ksteep - 1)
>
> I only noticed just now when trying to plot some values and I used the
> values from the macro.  It seems it is missing some parentheses and
> should be:
>
> #define EXPCURVE(x,y) ((exp(x * log(y))-1)/(y-1))
>
>

Initial tests didn't show it affecting the output but I'll have a look 
at the expression in greater detail. One of the main reasons I wanted 
to submit these to the language, was to get quality feedback from 
individuals such as yourself about ways to improve these, so thank you 
very much for your comments; I do quite appreciate the time you have 
taken to make these observations and look forward to exploring your 
suggestions in much greater detail :)

> Just wanted to note that I hope these comments are taken purely as
> constructive and that I'm very happy these opcodes are in! (Thanks
> Dave!)
>
> steven


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Steven,

Thank you so much for pointing out these potential discrepancies. I've 
re-compiled Csound with these changes and tested it; after looking at 
the code it seems things are simplified a great deal as well as the 
correction of the expression syntax for the expcurve opcode. I 
appreciate your effort to this end a great deal and feel that the 
changes you suggest would be excellent to check into the CVS. The 
Python script was also quite handy as well!

One question I do have though, which is more of a general inquiry, is 
that you mentioned previously the opcodes were in "thread 3" - what 
exactly does this mean from the standpoint of running Csound? In other 
words how does

   { "opcode", sizeof(opcode), 2, "k", "k", NULL, (SUBR)opcode_perf, 
NULL }

differ from

   { "opcode", sizeof(opcode), 3, "k", "k", (SUBR)opcode_init, 
(SUBR)opcode_perf, NULL }

at runtime?

I would eventually like to make the opcodes return valid init values at 
i-time, in the event a composer chooses to use any of these opcodes in 
a piece that is rendered non-realtime, etc. However I would like to 
take the time to understand the concept in greater detail before 
attempting an implementation to this end.

To reiterate, your changes are excellent and I would be most grateful 
if they made their way into the canonical CVS. Thank you again.


-David

On Oct 14, 2006, at 8:47 AM, Steven Yi wrote:

> Hi Dave,
>
> I'm glad that the email was useful!  I've attached two files here, one
> is a ugakbari.c file with modifications I've made, the other is a
> python testing script for the logcurve and expcurve formulas.  I
> misread the data the first time in looking at logcurve and found the
> same results as you regarding steepness values to use.
>
> Regarding:
>
>
>> The initial idea was to make them both i and k-rate as long as it is
>> feasible to do code like
>>
>> k1 init 0.55
>> k2 init 8
>>
>> kout  logcurve  k1, ksteep
>>
>> in the absense of proper i-rate initialization, it should be ok to
>> remove the i-rate stuff right?
>
>
> I'm not quite sure what you are saying here.  For the opcode, if
> you're going to be using krate vars anyways, and the first run of the
> krate func will overwrite anything done at itime with the code you
> have.  I've found that most krate opcodes with thread 3 that I've seen
> will use the i-time function to setup some internal state data,
> precalculate values from i-rate input args, allocate aux channels,
> etc., and then use the krate func to do the actual output.
>
> Without the i-rate funcs, the code you gave above will still give a
> valid krate val at k-time, but not at i-time, which seems to be
> perfectly fine as I don't think krate opcodes should be dependable to
> give a value at itime (maybe others disagree though).
>
>
>> Definitely adding the formula into the manual page is a good idea. In
>> regards to the steepness parameter, a value of 1.00001 will give 
>> almost
>> a straight line and values like 8, 16, 256, etc will give curves of
>> increasing steepness. I don't believe there is a limit to how steep 
>> the
>> curve can be.
>
> Cool, I'll make a change to the expcurve and logcurve in a moment with
> your info from above.  I'm sure it will be very handy!
>
>> > 5)expcurve code seems to be wrong to me!  This is the macro defined 
>> in
>> > ugakbari:
>> >
>> > #define EXPCURVE(x,y) (exp(x * log(y))-1/(y-1))
>> >
>> > while the UDO code is:
>> >
>> > kout  =       (exp(kfloat * log(ksteep)) - 1)/(ksteep - 1)
>> >
>> > I only noticed just now when trying to plot some values and I used 
>> the
>> > values from the macro.  It seems it is missing some parentheses and
>> > should be:
>> >
>> > #define EXPCURVE(x,y) ((exp(x * log(y))-1)/(y-1))
>> >
>> >
>>
>> Initial tests didn't show it affecting the output but I'll have a look
>> at the expression in greater detail. One of the main reasons I wanted
>> to submit these to the language, was to get quality feedback from
>> individuals such as yourself about ways to improve these, so thank you
>> very much for your comments; I do quite appreciate the time you have
>> taken to make these observations and look forward to exploring your
>> suggestions in much greater detail :)
>
> I'm fairly certain now that the original macro is off. If you read it 
> this way:
>
> #define EXPCURVE(x,y) (    exp(x * log(y))   -    1/(y-1)      )
>
> which is different from your original UDO code. I've made the change
> in the ugakbari.c file attached here.
>
>
> Well, let me know what you think about the changes in the ugakbari.c
> file; if they look good to you, I can go ahead and check them in,
> otherwise, let me know what you'd like different and I can check that
> in too.
>
> steven
> 


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net