I'm having a go at making an opcode again. Come across a snag.

I have two i-rate input arguments, that aren't passing properly into my opcode.
This is my set of inputs in the struct:

    MYFLT *carIn, *modIn, threshLo, threshHi;                 // input args

That's 2 a-rate, followed by the 2 i-rate in question. I am doing
nothing with them in the init function, and in the performance
function I am only doing this before trying to use them:

    MYFLT iSideThreshLo = p->threshLo;
    MYFLT iSideThreshHi = p->threshHi;

I am passing 0.2 and 0.6 for these parameters in my csd, but when I
monitor the values in my opcode, they look like this:

p->threshLo = 1.69618e-316
p->threshHi = 1.69618e-316
iSideThreshLo = 1.69618e-316
iSideThreshHi = 1.69618e-316

I guess that I need to do some more to initialise them or something,
but I can't figure it out, even when having a look through some
existing opcode source.

Any ideas?

Pete

I'm pretty sure threshHi and threshlo should also be pointers.

ah ok, are they all pointers then? arrays and single value variables alike?

On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
> I'm pretty sure threshHi and threshlo should also be pointers.
>
>
> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
> wrote:
>>
>> I'm having a go at making an opcode again. Come across a snag.
>>
>> I have two i-rate input arguments, that aren't passing properly into my
>> opcode.
>> This is my set of inputs in the struct:
>>
>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>> args
>>
>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>> nothing with them in the init function, and in the performance
>> function I am only doing this before trying to use them:
>>
>>     MYFLT iSideThreshLo = p->threshLo;
>>     MYFLT iSideThreshHi = p->threshHi;
>>
>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>> monitor the values in my opcode, they look like this:
>>
>> p->threshLo = 1.69618e-316
>> p->threshHi = 1.69618e-316
>> iSideThreshLo = 1.69618e-316
>> iSideThreshHi = 1.69618e-316
>>
>> I guess that I need to do some more to initialise them or something,
>> but I can't figure it out, even when having a look through some
>> existing opcode source.
>>
>> Any ideas?
>>
>> Pete
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

boom! that worked, cheers man :D any problem likely to arise from
keeping the varialbes within my performance function as non-pointers?

ie iSideThreshHi and iSideThreshLo

On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
 wrote:
> ah ok, are they all pointers then? arrays and single value variables alike?
>
> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>> I'm pretty sure threshHi and threshlo should also be pointers.
>>
>>
>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
>> wrote:
>>>
>>> I'm having a go at making an opcode again. Come across a snag.
>>>
>>> I have two i-rate input arguments, that aren't passing properly into my
>>> opcode.
>>> This is my set of inputs in the struct:
>>>
>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>>> args
>>>
>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>> nothing with them in the init function, and in the performance
>>> function I am only doing this before trying to use them:
>>>
>>>     MYFLT iSideThreshLo = p->threshLo;
>>>     MYFLT iSideThreshHi = p->threshHi;
>>>
>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>> monitor the values in my opcode, they look like this:
>>>
>>> p->threshLo = 1.69618e-316
>>> p->threshHi = 1.69618e-316
>>> iSideThreshLo = 1.69618e-316
>>> iSideThreshHi = 1.69618e-316
>>>
>>> I guess that I need to do some more to initialise them or something,
>>> but I can't figure it out, even when having a look through some
>>> existing opcode source.
>>>
>>> Any ideas?
>>>
>>> Pete
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio

Yes, all opcode input and output arguments are set as MYFLT* and are
treated as addresses to data structures.  For i- and k- arguments,
they can be immediately dereferenced as MYFLT values.  For a-, it
should be treated as a MYFLT array.  Other variable types need casting
to their related data structure (e.g., PVSDAT, STRINGDAT, etc.).

Within a performance function, it's not only not a problem, but also
recommended to first copy values to a local variables to the function.
The general pattern for opcode performance functions (and really,
audio plugin systems in general) is:

* your state data structure holds state for between runs
* during a run, copy all values to local variables on the stack
* perform audio processing using local variables
* save state once again from the local variables for the next run

Using local variables will generally be faster than having to hop
around the heap.

On Fri, Mar 4, 2016 at 8:26 AM, Peter Burgess
 wrote:
> boom! that worked, cheers man :D any problem likely to arise from
> keeping the varialbes within my performance function as non-pointers?
>
> ie iSideThreshHi and iSideThreshLo
>
> On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
>  wrote:
>> ah ok, are they all pointers then? arrays and single value variables alike?
>>
>> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>>> I'm pretty sure threshHi and threshlo should also be pointers.
>>>
>>>
>>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
>>> wrote:
>>>>
>>>> I'm having a go at making an opcode again. Come across a snag.
>>>>
>>>> I have two i-rate input arguments, that aren't passing properly into my
>>>> opcode.
>>>> This is my set of inputs in the struct:
>>>>
>>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>>>> args
>>>>
>>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>>> nothing with them in the init function, and in the performance
>>>> function I am only doing this before trying to use them:
>>>>
>>>>     MYFLT iSideThreshLo = p->threshLo;
>>>>     MYFLT iSideThreshHi = p->threshHi;
>>>>
>>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>>> monitor the values in my opcode, they look like this:
>>>>
>>>> p->threshLo = 1.69618e-316
>>>> p->threshHi = 1.69618e-316
>>>> iSideThreshLo = 1.69618e-316
>>>> iSideThreshHi = 1.69618e-316
>>>>
>>>> I guess that I need to do some more to initialise them or something,
>>>> but I can't figure it out, even when having a look through some
>>>> existing opcode source.
>>>>
>>>> Any ideas?
>>>>
>>>> Pete
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>> be posted here
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Awesome! thanks very much, that's all pretty clear now :D

On Fri, Mar 4, 2016 at 1:46 PM, Steven Yi  wrote:
> Yes, all opcode input and output arguments are set as MYFLT* and are
> treated as addresses to data structures.  For i- and k- arguments,
> they can be immediately dereferenced as MYFLT values.  For a-, it
> should be treated as a MYFLT array.  Other variable types need casting
> to their related data structure (e.g., PVSDAT, STRINGDAT, etc.).
>
> Within a performance function, it's not only not a problem, but also
> recommended to first copy values to a local variables to the function.
> The general pattern for opcode performance functions (and really,
> audio plugin systems in general) is:
>
> * your state data structure holds state for between runs
> * during a run, copy all values to local variables on the stack
> * perform audio processing using local variables
> * save state once again from the local variables for the next run
>
> Using local variables will generally be faster than having to hop
> around the heap.
>
> On Fri, Mar 4, 2016 at 8:26 AM, Peter Burgess
>  wrote:
>> boom! that worked, cheers man :D any problem likely to arise from
>> keeping the varialbes within my performance function as non-pointers?
>>
>> ie iSideThreshHi and iSideThreshLo
>>
>> On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
>>  wrote:
>>> ah ok, are they all pointers then? arrays and single value variables alike?
>>>
>>> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>>>> I'm pretty sure threshHi and threshlo should also be pointers.
>>>>
>>>>
>>>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
>>>> wrote:
>>>>>
>>>>> I'm having a go at making an opcode again. Come across a snag.
>>>>>
>>>>> I have two i-rate input arguments, that aren't passing properly into my
>>>>> opcode.
>>>>> This is my set of inputs in the struct:
>>>>>
>>>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>>>>> args
>>>>>
>>>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>>>> nothing with them in the init function, and in the performance
>>>>> function I am only doing this before trying to use them:
>>>>>
>>>>>     MYFLT iSideThreshLo = p->threshLo;
>>>>>     MYFLT iSideThreshHi = p->threshHi;
>>>>>
>>>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>>>> monitor the values in my opcode, they look like this:
>>>>>
>>>>> p->threshLo = 1.69618e-316
>>>>> p->threshHi = 1.69618e-316
>>>>> iSideThreshLo = 1.69618e-316
>>>>> iSideThreshHi = 1.69618e-316
>>>>>
>>>>> I guess that I need to do some more to initialise them or something,
>>>>> but I can't figure it out, even when having a look through some
>>>>> existing opcode source.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Pete
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>         https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>> Csound mailing list Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>> be posted here
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

On a slightly different subject, does it matter if I use vectors in
the performance function for the opcode? I am assuming I can't use
them in the struct.

On Fri, Mar 4, 2016 at 1:48 PM, Peter Burgess
 wrote:
> Awesome! thanks very much, that's all pretty clear now :D
>
> On Fri, Mar 4, 2016 at 1:46 PM, Steven Yi  wrote:
>> Yes, all opcode input and output arguments are set as MYFLT* and are
>> treated as addresses to data structures.  For i- and k- arguments,
>> they can be immediately dereferenced as MYFLT values.  For a-, it
>> should be treated as a MYFLT array.  Other variable types need casting
>> to their related data structure (e.g., PVSDAT, STRINGDAT, etc.).
>>
>> Within a performance function, it's not only not a problem, but also
>> recommended to first copy values to a local variables to the function.
>> The general pattern for opcode performance functions (and really,
>> audio plugin systems in general) is:
>>
>> * your state data structure holds state for between runs
>> * during a run, copy all values to local variables on the stack
>> * perform audio processing using local variables
>> * save state once again from the local variables for the next run
>>
>> Using local variables will generally be faster than having to hop
>> around the heap.
>>
>> On Fri, Mar 4, 2016 at 8:26 AM, Peter Burgess
>>  wrote:
>>> boom! that worked, cheers man :D any problem likely to arise from
>>> keeping the varialbes within my performance function as non-pointers?
>>>
>>> ie iSideThreshHi and iSideThreshLo
>>>
>>> On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
>>>  wrote:
>>>> ah ok, are they all pointers then? arrays and single value variables alike?
>>>>
>>>> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>>>>> I'm pretty sure threshHi and threshlo should also be pointers.
>>>>>
>>>>>
>>>>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
>>>>> wrote:
>>>>>>
>>>>>> I'm having a go at making an opcode again. Come across a snag.
>>>>>>
>>>>>> I have two i-rate input arguments, that aren't passing properly into my
>>>>>> opcode.
>>>>>> This is my set of inputs in the struct:
>>>>>>
>>>>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>>>>>> args
>>>>>>
>>>>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>>>>> nothing with them in the init function, and in the performance
>>>>>> function I am only doing this before trying to use them:
>>>>>>
>>>>>>     MYFLT iSideThreshLo = p->threshLo;
>>>>>>     MYFLT iSideThreshHi = p->threshHi;
>>>>>>
>>>>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>>>>> monitor the values in my opcode, they look like this:
>>>>>>
>>>>>> p->threshLo = 1.69618e-316
>>>>>> p->threshHi = 1.69618e-316
>>>>>> iSideThreshLo = 1.69618e-316
>>>>>> iSideThreshHi = 1.69618e-316
>>>>>>
>>>>>> I guess that I need to do some more to initialise them or something,
>>>>>> but I can't figure it out, even when having a look through some
>>>>>> existing opcode source.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Pete
>>>>>>
>>>>>> --
>>>>>> http://algorythmradio.com
>>>>>> https://soundcloud.com/algorythmradio
>>>>>>
>>>>>> Csound mailing list
>>>>>> Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>> Send bugs reports to
>>>>>>         https://github.com/csound/csound/issues
>>>>>> Discussions of bugs and features can be posted here
>>>>>
>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>>> be posted here
>>>>
>>>>
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
>
> --
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio

Look at th AUXCH structure for variable sized vectors.  Overwise C vectors 
are OK in the struct to mintain state.  Or have I misunderstood the 
question?

==John ff

On Fri, 4 Mar 2016, Peter Burgess wrote:

> On a slightly different subject, does it matter if I use vectors in
> the performance function for the opcode? I am assuming I can't use
> them in the struct.
>
> On Fri, Mar 4, 2016 at 1:48 PM, Peter Burgess
>  wrote:
>> Awesome! thanks very much, that's all pretty clear now :D
>>
>> On Fri, Mar 4, 2016 at 1:46 PM, Steven Yi  wrote:
>>> Yes, all opcode input and output arguments are set as MYFLT* and are
>>> treated as addresses to data structures.  For i- and k- arguments,
>>> they can be immediately dereferenced as MYFLT values.  For a-, it
>>> should be treated as a MYFLT array.  Other variable types need casting
>>> to their related data structure (e.g., PVSDAT, STRINGDAT, etc.).
>>>
>>> Within a performance function, it's not only not a problem, but also
>>> recommended to first copy values to a local variables to the function.
>>> The general pattern for opcode performance functions (and really,
>>> audio plugin systems in general) is:
>>>
>>> * your state data structure holds state for between runs
>>> * during a run, copy all values to local variables on the stack
>>> * perform audio processing using local variables
>>> * save state once again from the local variables for the next run
>>>
>>> Using local variables will generally be faster than having to hop
>>> around the heap.
>>>
>>> On Fri, Mar 4, 2016 at 8:26 AM, Peter Burgess
>>>  wrote:
>>>> boom! that worked, cheers man :D any problem likely to arise from
>>>> keeping the varialbes within my performance function as non-pointers?
>>>>
>>>> ie iSideThreshHi and iSideThreshLo
>>>>
>>>> On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
>>>>  wrote:
>>>>> ah ok, are they all pointers then? arrays and single value variables alike?
>>>>>
>>>>> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>>>>>> I'm pretty sure threshHi and threshlo should also be pointers.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess 
>>>>>> wrote:
>>>>>>>
>>>>>>> I'm having a go at making an opcode again. Come across a snag.
>>>>>>>
>>>>>>> I have two i-rate input arguments, that aren't passing properly into my
>>>>>>> opcode.
>>>>>>> This is my set of inputs in the struct:
>>>>>>>
>>>>>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 // input
>>>>>>> args
>>>>>>>
>>>>>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>>>>>> nothing with them in the init function, and in the performance
>>>>>>> function I am only doing this before trying to use them:
>>>>>>>
>>>>>>>     MYFLT iSideThreshLo = p->threshLo;
>>>>>>>     MYFLT iSideThreshHi = p->threshHi;
>>>>>>>
>>>>>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>>>>>> monitor the values in my opcode, they look like this:
>>>>>>>
>>>>>>> p->threshLo = 1.69618e-316
>>>>>>> p->threshHi = 1.69618e-316
>>>>>>> iSideThreshLo = 1.69618e-316
>>>>>>> iSideThreshHi = 1.69618e-316
>>>>>>>
>>>>>>> I guess that I need to do some more to initialise them or something,
>>>>>>> but I can't figure it out, even when having a look through some
>>>>>>> existing opcode source.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Pete
>>>>>>>
>>>>>>> --
>>>>>>> http://algorythmradio.com
>>>>>>> https://soundcloud.com/algorythmradio
>>>>>>>
>>>>>>> Csound mailing list
>>>>>>> Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>> Send bugs reports to
>>>>>>>         https://github.com/csound/csound/issues
>>>>>>> Discussions of bugs and features can be posted here
>>>>>>
>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>>> https://github.com/csound/csound/issues Discussions of bugs and features can
>>>>>> be posted here
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>>
>>>>
>>>>
>>>> --
>>>> http://algorythmradio.com
>>>> https://soundcloud.com/algorythmradio
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>
>
>
> -- 
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I was specifically thinking of the c++ vectors that have some
functions for reorganising the arrays. I don't know anything about C
vectors, so I can't say whether you misunderstood the question or not,
lol.

As it happens though, I have just written my own array reorganisation
function. It was pretty simple, so I should have just stopped being
lazy and done it in the first place really ;)

Pete

On Fri, Mar 4, 2016 at 3:31 PM, jpff  wrote:
> Look at th AUXCH structure for variable sized vectors.  Overwise C vectors
> are OK in the struct to mintain state.  Or have I misunderstood the
> question?
>
> ==John ff
>
>
> On Fri, 4 Mar 2016, Peter Burgess wrote:
>
>> On a slightly different subject, does it matter if I use vectors in
>> the performance function for the opcode? I am assuming I can't use
>> them in the struct.
>>
>> On Fri, Mar 4, 2016 at 1:48 PM, Peter Burgess
>>  wrote:
>>>
>>> Awesome! thanks very much, that's all pretty clear now :D
>>>
>>> On Fri, Mar 4, 2016 at 1:46 PM, Steven Yi  wrote:
>>>>
>>>> Yes, all opcode input and output arguments are set as MYFLT* and are
>>>> treated as addresses to data structures.  For i- and k- arguments,
>>>> they can be immediately dereferenced as MYFLT values.  For a-, it
>>>> should be treated as a MYFLT array.  Other variable types need casting
>>>> to their related data structure (e.g., PVSDAT, STRINGDAT, etc.).
>>>>
>>>> Within a performance function, it's not only not a problem, but also
>>>> recommended to first copy values to a local variables to the function.
>>>> The general pattern for opcode performance functions (and really,
>>>> audio plugin systems in general) is:
>>>>
>>>> * your state data structure holds state for between runs
>>>> * during a run, copy all values to local variables on the stack
>>>> * perform audio processing using local variables
>>>> * save state once again from the local variables for the next run
>>>>
>>>> Using local variables will generally be faster than having to hop
>>>> around the heap.
>>>>
>>>> On Fri, Mar 4, 2016 at 8:26 AM, Peter Burgess
>>>>  wrote:
>>>>>
>>>>> boom! that worked, cheers man :D any problem likely to arise from
>>>>> keeping the varialbes within my performance function as non-pointers?
>>>>>
>>>>> ie iSideThreshHi and iSideThreshLo
>>>>>
>>>>> On Fri, Mar 4, 2016 at 1:22 PM, Peter Burgess
>>>>>  wrote:
>>>>>>
>>>>>> ah ok, are they all pointers then? arrays and single value variables
>>>>>> alike?
>>>>>>
>>>>>> On Fri, Mar 4, 2016 at 1:21 PM, Steven Yi  wrote:
>>>>>>>
>>>>>>> I'm pretty sure threshHi and threshlo should also be pointers.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 4, 2016, 8:19 AM Peter Burgess
>>>>>>> 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm having a go at making an opcode again. Come across a snag.
>>>>>>>>
>>>>>>>> I have two i-rate input arguments, that aren't passing properly into
>>>>>>>> my
>>>>>>>> opcode.
>>>>>>>> This is my set of inputs in the struct:
>>>>>>>>
>>>>>>>>     MYFLT *carIn, *modIn, threshLo, threshHi;                 //
>>>>>>>> input
>>>>>>>> args
>>>>>>>>
>>>>>>>> That's 2 a-rate, followed by the 2 i-rate in question. I am doing
>>>>>>>> nothing with them in the init function, and in the performance
>>>>>>>> function I am only doing this before trying to use them:
>>>>>>>>
>>>>>>>>     MYFLT iSideThreshLo = p->threshLo;
>>>>>>>>     MYFLT iSideThreshHi = p->threshHi;
>>>>>>>>
>>>>>>>> I am passing 0.2 and 0.6 for these parameters in my csd, but when I
>>>>>>>> monitor the values in my opcode, they look like this:
>>>>>>>>
>>>>>>>> p->threshLo = 1.69618e-316
>>>>>>>> p->threshHi = 1.69618e-316
>>>>>>>> iSideThreshLo = 1.69618e-316
>>>>>>>> iSideThreshHi = 1.69618e-316
>>>>>>>>
>>>>>>>> I guess that I need to do some more to initialise them or something,
>>>>>>>> but I can't figure it out, even when having a look through some
>>>>>>>> existing opcode source.
>>>>>>>>
>>>>>>>> Any ideas?
>>>>>>>>
>>>>>>>> Pete
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://algorythmradio.com
>>>>>>>> https://soundcloud.com/algorythmradio
>>>>>>>>
>>>>>>>> Csound mailing list
>>>>>>>> Csound@listserv.heanet.ie
>>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>>>>> Send bugs reports to
>>>>>>>>         https://github.com/csound/csound/issues
>>>>>>>> Discussions of bugs and features can be posted here
>>>>>>>
>>>>>>>
>>>>>>> Csound mailing list Csound@listserv.heanet.ie
>>>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>>>>>> https://github.com/csound/csound/issues Discussions of bugs and
>>>>>>> features can
>>>>>>> be posted here
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://algorythmradio.com
>>>>>> https://soundcloud.com/algorythmradio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://algorythmradio.com
>>>>> https://soundcloud.com/algorythmradio
>>>>>
>>>>> Csound mailing list
>>>>> Csound@listserv.heanet.ie
>>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>>> Send bugs reports to
>>>>>         https://github.com/csound/csound/issues
>>>>> Discussions of bugs and features can be posted here
>>>>
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>         https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>>
>>>
>>>
>>> --
>>> http://algorythmradio.com
>>> https://soundcloud.com/algorythmradio
>>
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here