Hi David,

Just wanted to say I'm happy to be able to pass on the things I've
learned and of course am always happy to be corrected when I pass on
things that aren't quite correct!  I've gone ahead and checked in
changes; they overwrote something John did but I think that since
we've both verified these opcodes work and the expcurve macro was
fixed in the version I checked in that it should be fine.

Well, regarding thread 3, the idea of the opcode thread is a little
off as it's not really a thread.  Each opcode entry has three funtion
pointers, one for itime, for ktime, and one for atime.  In truth,
there really is only two "times" in the engine at which opcode
functions are called, once when the instrument is initialized, the
other in the kperf loop.

The thread type is used by the engine during setup when an instrument
is allocated.  You can look at the instance() function in
Engine/insert.c to see this.  At this time, when an instance of a note
is being made, it looks at the instrument template and gets the size
of the total block of memory that is required for the state
information of all opcodes (precalculated at parse time, the size of
all the dsblksiz of each opcode plus a few ohter things), then does a
check of all opcodes and their types to setup up which function
pointers are going to be used at init-time and at kperf time.  In
insert() in that same file, after the instance is made, you'll see the
call to all iopadr functions (the itime functions) for the instrument.

Next, check kperf in csound.c and search for "opadr".  opadr will be
set by instance to either the krate or arate functions for the opcode
if they are set to be used by thread number.  (That's set in the
instance).

Now the difference between the thread 2 code changes I put in and what
you had with thread 3 is that no itime func is used for the opcode
now, and it only is run in the kperf loop.

If you want to do a check at itime, you could switch the oentry back
to thread 3 and then add some code to verify parameters.  This however
is not safe a itime with krate variables, as from the opcode point of
view, you have no idea if the variable has been preinitialized at
itime.  But at ktime, you know that all code above will have been run
and that krate variables entering into the opcode will have been
calculated.

If you want to make the opcode return values at i-time, I'd recommend
making the opcode polymorphic and add a signature that has only irate
vars for input and output.  But to try to do something else with a
krate opcode is not so safe.

Well, hopefully that explains things a little bit better!  BTW:
Regarding init time and performance time, I would also recommend
looking at James Beauchamp's Music4C and seeing how instruments there
work.  The stages are really very clear, a .note for init time, a
.endnote for code to run when the instrument ends, and .sample that
runs at performance time.  Csound basically has the .note and .sample
time, and I forgot if the dopadr destructor function works at end of
note or end of performance.  It's sort of interesting to think about
that way, that the code you write in Csound ORC gets basically spliced
into different functions running in a linked list at one of those
times.

Hope that helps!
steven


On 10/14/06, David Akbari <dakbari@gmail.com> wrote:
> 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
> > <ugakbari.c><curveTest.py>
>
>
> -------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
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