Hi Gabriel, I'm taking a look at code in both CsoundAV and Csound and I don't see anywhere where the opcode arguments would get reallocated every k-cycle. I wrote a quick plugin opcode that prints the address of a krate arg: #include typedef struct { OPDS h; MYFLT *kin; } POINTER_TEST; static int kpointer_test(CSOUND *csound, POINTER_TEST *p) { csound->Message(csound, "Pointer Address: %p\n", p->kin); return OK; } #define S(x) sizeof(x) static OENTRY localops[] = { { "pointer_test", S(POINTER_TEST), 2, "", "k", NULL, (SUBR)kpointer_test }, }; LINKAGE Running a test orc with this reports the same memory address used during the entire run. I'm not sure if this is what you are talking about exactly though. I don't quite understand how args space was unique between opcodes if they had the same pointer value set in the opcode arg space, say if they were both using the same krate arg. kperf seems mostly the same to my eyes in both CsoundAV sources and Csound5 and both seem to allocate memory in similar ways. Also, It seems to me that without some kind of thread locking, the possibility exists where if the GL thread is reading or updating values between kcycles, one kcycle could have some of the old values and some of the new. Could you by chance send me a CSD of an orchestra that does not work involving the output args? The example CSD's I tried to download on http://www.csounds.com/csoundav seem to all be broken links. Thanks! steven On 5/30/07, Gabriel Maldonado wrote: > Hi Steven, > thanks for the answer. The problem that has rosen is the new > allocation-remotion mechanism of the opcode arguments. It seems that in > Csound5, the argument space is allocated-removed at each k-cycle for the > subsequent opcodes of an instrument, even during the life of a note. So, > when read by another thread (the OpenGl thread in particular), the > argument value is unpredictable. The solution I attempted to do is to > copy the arguments into doubled variables of the opcode structure during > all k-cycles. For example the GLrotate opcode needs the following > opcode structure (all arguments are k-type): > > typedef struct { /* structure used in CsoundAV */ > OPDS h; > MYFLT *angle, *x,*y,*z; /* input argument values are persistent > with the old Csound engine */ > } GL_ROTATE; > > typedef struct { /* structure I use with Csound5, which solves the > problem only partially */ > OPDS h; > MYFLT *angle, *x,*y,*z; /* unfortunately Csound5 makes this space > non persistent between k-cyles */ > MYFLT angle_, x_, y_, z_; /* the arguments are copied in this > variables at each k-cycle but this doesn't solve all problems */ > > } GL_ROTATE; > > The contents of *angle, *x, *y and *z (that are input arguments) are > copied during each k-cycle to the corresponding angle_, x_, y_ and z_ > variables . This solves partially the problem, at the cost of an > additional k-cycle routine (which slows down a bit the OpenGL opcode), > but it doesn't solve the problem when there are output arguments. There > is a set of OpenGL-related opcodes that have output arguments (allowing > tests, loops, oscillators and math operators that work at OpenGL > frame-rate in a thread different than k-rate). So, by using this I can > run some of my OpenGL .csd orchestras, in Csound5, but I cannot run some > of the most interesting ones (i.e. the ones containing frame-rate loops > and tests). > > If it would be possible to restore the old behavior of opcode argument > memory (eventually making this choice available as an option), Csound5 > would be capable of supporting all of CsoundAV OpenGL features. > > best > > Gabriel > > > > Steven Yi ha scritto: > > 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 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