I seem to remember that the deinit of opcodes was removed.  How does
one do the equivalent action in cs5?
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> I seem to remember that the deinit of opcodes was removed.  How does
> one do the equivalent action in cs5?
> ==John ffitch

It depends on when you want the deinit routine to be called.
There are functions in the API to register a callback to be
called by deact() or csoundReset() (the latter is actually used
by the OSC listener opcodes you are just working on):

   /**
    * Register a function to be called at note deactivation.
    * Should be called from the initialisation routine of an opcode.
    * 'p' is a pointer to the OPDS structure of the opcode, and 'func'
    * is the function to be called, with the same arguments and return
    * value as in the case of opcode init/perf functions.
    * The functions are called in reverse order of registration.
    * Returns zero on success.
    */
   PUBLIC int csoundRegisterDeinitCallback(void *csound, void *p,
                                           int (*func)(void *, void *));

   /**
    * Register a function to be called by csoundReset(), in reverse order
    * of registration, before unloading external modules. The function takes
    * the Csound instance pointer as the first argument, and the pointer
    * passed here as 'userData' as the second, and is expected to return zero
    * on success.
    * The return value of csoundRegisterResetCallback() is zero on success.
    */
   PUBLIC int csoundRegisterResetCallback(void *csound, void *userData,
                                          int (*func)(void *, void *));

There are no callbacks for note turnoff (as opposed to deactivation) and
section end yet, but can be easily added if there is a demand.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:

> For the end-of-run deinitialization, there the module can define
> csoundModuleDestroy.

There is also csoundRegisterResetCallback() for plugins that use the
opcode_size/opcode_init interface. Should be called from the latter.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:

> Oops, sorry John about the somewhat erroneous info on
> csoundModuleDestroy!  Istvan, what is the difference between note
> turnoff and deactivation?

For notes with no release, there is no difference.
Otherwise, on a note-off, the instrument first enters the release
stage, and when that ends, it is deactivated:

     +--------+
     |        |\ release
     |        | \
----+--------+--+------
     |        |  |
  note on  note  deactivate
            off

There is currently no callback for the note-off (you can detect it by
watching the release flag at k-rate), only for deactivation.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> There are no callbacks for note turnoff (as opposed to deactivation) and
> section end yet, but can be easily added if there is a demand.

Here is demand! ;)

Iain


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

>> There are no callbacks for note turnoff (as opposed to deactivation) and
>> section end yet, but can be easily added if there is a demand.
> 
> Here is demand! ;)

For section end or note turnoff ? You can already do the latter with
the usual (albeit not very elegant) method of watching the release flag
at control rate.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am just wondering (aloud) if the fact that these deactivation functions
are called in reverse order of registration will be confusing to the user.
Most things in Csound happen in the order they are written in an instrument.

This will at a minimum reverse that, but potentially could call the deact
funcs in an "undefined" order from the user's perspective (if the opcodes
are not well behaved in when they register).  Also, what happens if opcodes
are re-inited?  Will they have their deacts called more than once if they
register more than once?  This could also change the order of calling, I
assume.

I would be more in favor of a well defined "deactivation pass" that
traverses a chain of opcodes in instrument order, much like the i-pass and
k-pass do.  (And I would consider it icing on the cake if one could just add
the function pointer to an OENTRY entry instead of having to call an API
function).

Just my thoughts ...

(I haven't looked at the code yet, so forgive any mis-assumptions).

Anthony Kozar
anthonykozar@sbcglobal.net
http://akozar.spymac.net/


On 6/15/05 4:46 PM, Istvan Varga  etched in stone:

> /**
> * Register a function to be called at note deactivation.
> * Should be called from the initialisation routine of an opcode.
> * 'p' is a pointer to the OPDS structure of the opcode, and 'func'
> * is the function to be called, with the same arguments and return
> * value as in the case of opcode init/perf functions.
> * The functions are called in reverse order of registration.
> * Returns zero on success.
> */
> PUBLIC int csoundRegisterDeinitCallback(void *csound, void *p,
> int (*func)(void *, void *));



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The deinit callback is not really a new "rate" for instrument control,
but is rather like an equivalent of atexit() for opcodes.
It can be used for deallocating, closing, or terminating some resource that
was allocated, opened, or started at note init time, and is not something
that can be controlled from the orchestra or is generally of much interest
to the user.
The order of calling is not relevant in most cases, but it can be changed
to be done in forward order if that is found to be more useful.
For every successful call of csoundRegisterDeinitCallback(), there will be
one call to the registered function when the note is deactivated, or when
csoundReset() or csoundDestroy() is called in case of abnormal termination
of performance. This also means that registering callbacks repeatedly in
tied or reinited notes will result in accumulating and calling all at once
at note deactivation. To avoid that, the opcode needs to check if it is
already initialized; this is usually needed anyway to avoid repeatedly
allocating (and thus accumulating and temporarily leaking) the resource that
is to be destroyed by the deinit callback.

If a new "d-rate" is found to be useful enough for the added complexity,
it can be implemented; should d-rate and global d-rate variables (with
opcodes and operators supporting such variables), dgoto, and d-rate
conditionals be added too ?

Anthony Kozar wrote:

> I am just wondering (aloud) if the fact that these deactivation functions
> are called in reverse order of registration will be confusing to the user.
> Most things in Csound happen in the order they are written in an instrument.
> 
> This will at a minimum reverse that, but potentially could call the deact
> funcs in an "undefined" order from the user's perspective (if the opcodes
> are not well behaved in when they register).  Also, what happens if opcodes
> are re-inited?  Will they have their deacts called more than once if they
> register more than once?  This could also change the order of calling, I
> assume.
> 
> I would be more in favor of a well defined "deactivation pass" that
> traverses a chain of opcodes in instrument order, much like the i-pass and
> k-pass do.  (And I would consider it icing on the cake if one could just add
> the function pointer to an OENTRY entry instead of having to call an API
> function).


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 7/3/05 4:04 PM, Istvan Varga  etched in stone:

> The deinit callback is not really a new "rate" for instrument control,
> but is rather like an equivalent of atexit() for opcodes.
> It can be used for deallocating, closing, or terminating some resource
[...]

Ah, OK.  There had been discussion before about implementing a "d-rate"
which some people thought had already been done, but wasn't, and should we,
and ...

Clearly, the API call is good for what you intend it to do.
 
> If a new "d-rate" is found to be useful enough for the added complexity,
> it can be implemented; should d-rate and global d-rate variables (with
> opcodes and operators supporting such variables), dgoto, and d-rate
> conditionals be added too ?

I had thought there would be some usefulness to a "d-rate."  The most
obvious example is a clean implementation in the orchestra of a monophonic
instrument that behaves like most MIDI synths do in mono mode.  (i.e.
lifting a key reverts pitch back to any other held notes).  I had thought
that d-rate opcodes would use regular i or k-rate variables but a "dgoto"
would be a distinct possibility.  There would also be MUCH potential for
abuse in a system like this if notes change values of global variables when
they end, etc.  

I would not run out and implement d-rate opcodes immediately unless we can
come up with some other legitimate uses for it or find a way to minimize
abuses.  But it has always _seemed_ to me that there should be many
interesting uses for a d-rate; I just haven't given much thought to what
they actually would be ...

:)

Please forgive my late-night babbling ...

Anthony



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

There was a dealloc rate, but it was renmoved for reasons unknown
==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> There was a dealloc rate, but it was renmoved for reasons unknown

It was not really a "rate" either, even though the function pointer was
in OENTRY, but it still was not possible to make use of it from the
orchestra. It was more like RESET functions, just at end of section and
not end of performance (of course, with a single section score this makes
no difference).


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net