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

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

Hi Steven,
excuse me for the delay of my reply, but I was investigating the problem.

After further study, I realized that there is no big difference in the 
way both Csound4 and Csound5 manage the argument space, the bogus values 
were caused by the accessing difference I was using in CsoundAV with 
respect to CsoundAV5. In CsoundAV5 I suppressed the additional variable 
type t-rate (frame rate) and used k-rate only. The problem rises only 
when using the output of frame-rate opcodes used in k-rate formulas. By 
an accurate .csd design it is possible to avoid this problem.

Now I have converted several OpenGL .csd examples from CsoundAV to 
CsoundAV5 syntax (i.e. without t-rate and taking attention to k-rate 
formulas). They work very well with OpenGL alone, but when I use 
realtime audio besides OpenGL graphics, I noticed that the graphics 
moves jerkily. Maybe this problem could depend on current portaudio 
implementation of Csound5, which seems to me to use the blocking 
portaudio API (as I can see in the source file rtpa.c). Actually, even 
in normal .csd, realtime audio of Csound5 is far less responsive of that 
of CsoundAV (which uses host-driven portaudio with ASIO). Do you know if 
some attempt to use a host-driven mechanism has been developed for 
realtime audio in Csound5 in contrast with the blocking mechanism?

btw: I will soon release CsoundAV5 alpha and the last version of 
CsoundAV so people can make a comparison...

Thanks and best regards

Gabriel

Steven Yi ha scritto:
> 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

But on Windows, portaudio (rtpa.c) uses a callback mechanism  by
default. It does not use a blocking interface. What do you mean exactly?

Portaudio with ASIO is very responsive as far as I can
tell here, giving me latencies down to 32, 64 samples.

Mind you, you can implement your own IO (which is for instance what
MacCsound does), all you need is to use
csoundSetHostImplementedAudioIO()  and then deal with the
spin/spout buffers yourself. The portaudio module is then ignored.


Victor

At 11:42 11/06/2007, you wrote:
>Hi Steven,
>excuse me for the delay of my reply, but I was investigating the problem.
>
>After further study, I realized that there is no big difference in the
>way both Csound4 and Csound5 manage the argument space, the bogus values
>were caused by the accessing difference I was using in CsoundAV with
>respect to CsoundAV5. In CsoundAV5 I suppressed the additional variable
>type t-rate (frame rate) and used k-rate only. The problem rises only
>when using the output of frame-rate opcodes used in k-rate formulas. By
>an accurate .csd design it is possible to avoid this problem.
>
>Now I have converted several OpenGL .csd examples from CsoundAV to
>CsoundAV5 syntax (i.e. without t-rate and taking attention to k-rate
>formulas). They work very well with OpenGL alone, but when I use
>realtime audio besides OpenGL graphics, I noticed that the graphics
>moves jerkily. Maybe this problem could depend on current portaudio
>implementation of Csound5, which seems to me to use the blocking
>portaudio API (as I can see in the source file rtpa.c). Actually, even
>in normal .csd, realtime audio of Csound5 is far less responsive of that
>of CsoundAV (which uses host-driven portaudio with ASIO). Do you know if
>some attempt to use a host-driven mechanism has been developed for
>realtime audio in Csound5 in contrast with the blocking mechanism?
>
>btw: I will soon release CsoundAV5 alpha and the last version of
>CsoundAV so people can make a comparison...
>
>Thanks and best regards
>
>Gabriel
>
>Steven Yi ha scritto:
> > 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
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth


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

HI Gabriel,

I'm looking forward to this, and I hope we can soon synchoronize
CsoundAV and canonical, which will make it easier and more efficient for
both branches to maintain, bug fix and improve opcodes.
I'm curious, what version of csound5 are you basing csoundAV on?

Cheers,
Andrés

Gabriel Maldonado wrote:
> Hi Steven,
> excuse me for the delay of my reply, but I was investigating the problem.
>
> After further study, I realized that there is no big difference in the 
> way both Csound4 and Csound5 manage the argument space, the bogus values 
> were caused by the accessing difference I was using in CsoundAV with 
> respect to CsoundAV5. In CsoundAV5 I suppressed the additional variable 
> type t-rate (frame rate) and used k-rate only. The problem rises only 
> when using the output of frame-rate opcodes used in k-rate formulas. By 
> an accurate .csd design it is possible to avoid this problem.
>
> Now I have converted several OpenGL .csd examples from CsoundAV to 
> CsoundAV5 syntax (i.e. without t-rate and taking attention to k-rate 
> formulas). They work very well with OpenGL alone, but when I use 
> realtime audio besides OpenGL graphics, I noticed that the graphics 
> moves jerkily. Maybe this problem could depend on current portaudio 
> implementation of Csound5, which seems to me to use the blocking 
> portaudio API (as I can see in the source file rtpa.c). Actually, even 
> in normal .csd, realtime audio of Csound5 is far less responsive of that 
> of CsoundAV (which uses host-driven portaudio with ASIO). Do you know if 
> some attempt to use a host-driven mechanism has been developed for 
> realtime audio in Csound5 in contrast with the blocking mechanism?
>
> btw: I will soon release CsoundAV5 alpha and the last version of 
> CsoundAV so people can make a comparison...
>
> Thanks and best regards
>
> 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

Csound 5.4

cheers

Gabriel

Andres Cabrera ha scritto:
> I'm curious, what version of csound5 are you basing csoundAV on?
>
> Cheers,
> Andrés
>
>
>   
>   

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

oops! I intended 5.04 (not 5.4 obviously)...

Gabriel Maldonado ha scritto:
> Csound 5.4
>
> cheers
>
> Gabriel
>
> Andres Cabrera ha scritto:
>   
>> I'm curious, what version of csound5 are you basing csoundAV on?
>>
>> Cheers,
>> Andrés
>>
>>
>>   
>>   
>>     
>
> -------------------------------------------------------------------------
> 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