Hi Gabriel,

If I understand your question correctly, all of the opcode arguments
are connected up to variables during compilation time by otran and
oload.  There's some code in there that uses a local and global lookup
table that is cleared at the end of compilation and before runtime.
If I remember correctly, otran creates the tables for global and per
instrument and assigns index numbers, then oload malloc's a large
block of memory using the number of indexes * sizeof k -, a-, and
other vars, then using the indexes assigns the block of memory to use
to each variable and opcode.

There are some limitations due to this erasure of information for what
block of memory corresponds to what variable. John and I had talked
before about implementing a different allocation system that maintains
the lookup table for variables so that variables and opcodes could be
dynamically added and removed into instrument chains though
unfortunately little time to explore further implementation.

For the openGL opcodes, would it work to introduce a variable cache
that updates its values from the active variables at the end of every
k-pass?  Maybe a global flag could be used to indicate if caching is
desired and the openGL opcodes could turn that on if used so it
wouldn't impact csound running when not using openGL.  The openGL
opcodes could then make a copy of the variable cache during their
update cycle so they have a snapshot of variables state during a
single kpass. (Not sure if this would be feasible as I'm just thinking
from the top of my head).

Thanks!
steven

On 5/29/07, Gabriel Maldonado <g.maldonado@tiscalinet.it> wrote:
> Hi all,
> I want to port the CsoundAV OpenGL opcodes to Csound5, in the form of an
> external opcode library, but I found some problems that prevent to do
> it, at least without incurring into big limitations and hassles for me
> and the final user.
> The problem is that CsoundAV (which is based on Csound4 engine or older
> one) uses a unique memory address for each opcode argument working at
> k-rate, whose contents remains untouched between k-cycle and is not
> overwritten by subsequent opcodes of the orchestra. This allows the
> OpenGL routines (which runs in another thread) to read the contents of
> such arguments correctly at any time. Csound5, instead, seems to share
> the same opcode argument space between different subsequent ocpodes,
> probably because of some speed optimization. But in such a way, when the
> opcode arguments are accessed by the OpenGL routines, their content is
> corrupted.
>
> I attempted to search and find the code that allocates the memory space
> of opcode argument and manage their contents in Csound5, but I have been
> not able to do that. I intend to build a special version of Csound5 that
> use the old way to manage opcode addresses, in order to make the OpenGL
> routines to work correctly like CsoundAV.
>
> Can someone help me to find where the opcode argument space is managed?
>
> Thanks in advance...
>
> Gabriel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net