Uninit of opcodes

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Uninit of opcodes

jpff
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Michael Gogins
I have found it best to register opcodes as modules. There is a module deinitialization callback that you can install when you are registering your opcode module. Csound will call it at cleanup time. This is a per-library or per-module callback, not a per-opcode instance callback. The soundfont opcodes now work this way.

Regards,
Mike

-----Original Message-----
From: [hidden email]
Sent: Jun 15, 2005 4:02 PM
To: [hidden email]
Subject: [Cs-dev] Uninit of opcodes

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
In reply to this post by jpff
[hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Steven Yi
In reply to this post by jpff
Hi John,

There two different times for deinitialization, one when a note ends,
and one at the end of a csound run.  Both of these can be found in
Opcodes/fluidOpcodes/fluidOpcodes.cpp.

For the note time deinitialization, csound has to be told that the
opcode wants a deinit run.  In fluidOpcodes.cpp in the function
fluidNoteIopadr, the following code does this:

csound->RegisterDeinitCallback((void *)&csound, (void *)&fluid->h,
                                   &fluidNoteTurnoff);

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

steven


On 6/15/05, [hidden email] <[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
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. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Steven Yi
In reply to this post by Istvan Varga
Oops, sorry John about the somewhat erroneous info on
csoundModuleDestroy!  Istvan, what is the difference between note
turnoff and deactivation?  I had recoded fluidOpcodes to use that
facility and it seemed to run everytime the note turned off, but I had
not tested midi-initiated notes or tied-notes, so am curious about the
differences.

Thanks,
steven

On 6/15/05, Istvan Varga <[hidden email]> wrote:

> [hidden email] 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
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. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
In reply to this post by Steven Yi
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
In reply to this post by Steven Yi
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Steven Yi
Hi Istvan,

Thanks as always for the explanation!  I think the note deactivation
works fine for what is going on in fluidNote, which was my main
concern.  It seems more likely a concern to do note cleanup type
operations rather than operations at note off, so I'd vote to not
implement for now.

Thanks,
steven

On 6/16/05, Istvan Varga <[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
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. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Michael Gogins
In reply to this post by jpff
I also see no need for anything beyond note deactivation at this time, but note off might be useful in the future. So if it is easy maybe do it now, otherwise wait for a need.

Regards,
Mike

-----Original Message-----
From: Steven Yi <[hidden email]>
Sent: Jun 16, 2005 12:12 PM
To: [hidden email]
Subject: Re: [Cs-dev] Uninit of opcodes

Hi Istvan,

Thanks as always for the explanation!  I think the note deactivation
works fine for what is going on in fluidNote, which was my main
concern.  It seems more likely a concern to do note cleanup type
operations rather than operations at note off, so I'd vote to not
implement for now.

Thanks,
steven

On 6/16/05, Istvan Varga <[hidden email]> wrote:

> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
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. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
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. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Csound-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Iain Duncan
In reply to this post by Istvan Varga

> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Anthony Kozar
In reply to this post by Istvan Varga
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
[hidden email]
http://akozar.spymac.net/


On 6/15/05 4:46 PM, Istvan Varga <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Anthony Kozar
On 7/3/05 4:04 PM, Istvan Varga <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

jpff
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Istvan Varga
[hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel
Reply | Threaded
Open this post in threaded view
|

Re: Uninit of opcodes

Michael Gogins
In reply to this post by jpff
I seem to recall that deinit was removed by Istvan Varga.

It doesn't matter who it was. Whoever did it, unilaterally removing a
facility that already exists and is already in use (I had a number of
opcodes using it) simply should not be done. If the developer feels a need
to remove or change code in use they should discuss it.

The callback facility provided by Istvan works, and for some purposes it is
better than deinit was.

In terms of the opcode design and inner loops of Csound, anything that works
on the opcode instance level can as easily be done by a "virtual function"
(an i-, k-, or a-rate call to the opcode) as by a registered callback. In
both cases Csound must inspect a table for a function pointer and call it if
it is not zero. In such cases, the "virtual function" approach is simpler
and therefore it is better.

Regards,
Mike

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Cc: <[hidden email]>
Sent: Monday, July 04, 2005 4:40 AM
Subject: Re: [Cs-dev] Uninit of opcodes


> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>




-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel