Hi All,

I wanted to send an update about UDO Array Args:

* I implemented a[] args working with setksmps.  There's some special
code there for both a- and a[]- vars that does the sliding through the
audio vector.  (Perhaps something to abstract out at another time).
I'd welcome a review of the code in insert.c:useropcd1().

* I fixed a general issue with the local ksmps != 1 and also != global
ksmps.  The size for memcpy() was incorrect (it was using just the
local ksmps but not multiplying by sizeof(MYFLT).  I don't know if
that was an existing issue or one I introduced during development.
Either way, it's working now. :)

* I implemented code for --sample-accurate and a[] UDO args.  I think
it's working, but I heard some pops at the beginnings of notes, but I
think this was using setksmps.  I get the impression from the code
that there is a problem there anyways, that an opcode might try to
handle offset/early itself, but the calling context in useropcd1/2
also is doing some kind of offset/early handling and that there may be
a conflict.  It's a bit beyond me at the moment so I've left it for
now.

As it is, I think the UDO array feature is complete in that arrays are
working both with and without setksmps.  I think the other two tasks I
had put down related to this--which is namely type checking xin/xout,
and error reporting for UDO definitions as a whole--can be pushed to
another task that can be scheduled for 6.04.0.  The type information
that is now held with the UDO is a big step forward for that, but I
estimate it will take a fair amount of code to get the type checking
correct and I'm not sure it can be done before 6.03.0 goes out.  (I've
opened issue #310 and assigned to myself for this.)

Otherwise, the 6.03.0 milestone[1] currently has 6 open issues. I will
be focusing my Csound work time to working on 6.03 issues until the
release date.

Thanks!
steven

[1] - https://github.com/csound/csound/issues?milestone=10&state=open

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I wonder why/if sample accurate needs to be handled at all at this level, as it’s normally 
handled at the opcode level (e.g. we don’t have any special code at the instrument level
to handle it, since opcodes are more or less instruments internally).

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 4 Apr 2014, at 18:06, Steven Yi  wrote:

> * I implemented code for --sample-accurate and a[] UDO args.  I think
> it's working, but I heard some pops at the beginnings of notes, but I
> think this was using setksmps.  I get the impression from the code
> that there is a problem there anyways, that an opcode might try to
> handle offset/early itself, but the calling context in useropcd1/2
> also is doing some kind of offset/early handling and that there may be
> a conflict.  It's a bit beyond me at the moment so I've left it for
> now.


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm not sure either, but there was code there for a-sigs so I followed
that.  I see that the code is already adjusting the early/offset for
the instr instance when setksmps is used.  Maybe we can just remove
that code for asigs/a[]?

On Fri, Apr 4, 2014 at 1:26 PM, Victor Lazzarini
 wrote:
> I wonder why/if sample accurate needs to be handled at all at this level, as it's normally
> handled at the opcode level (e.g. we don't have any special code at the instrument level
> to handle it, since opcodes are more or less instruments internally).
>
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 4 Apr 2014, at 18:06, Steven Yi  wrote:
>
>> * I implemented code for --sample-accurate and a[] UDO args.  I think
>> it's working, but I heard some pops at the beginnings of notes, but I
>> think this was using setksmps.  I get the impression from the code
>> that there is a problem there anyways, that an opcode might try to
>> handle offset/early itself, but the calling context in useropcd1/2
>> also is doing some kind of offset/early handling and that there may be
>> a conflict.  It's a bit beyond me at the moment so I've left it for
>> now.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

oh yes, I think the only case where we need to worry about it is when we have local ksmps. I remember now.
Is that what you’ve implemented?

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 4 Apr 2014, at 18:40, Steven Yi  wrote:

> I'm not sure either, but there was code there for a-sigs so I followed
> that.  I see that the code is already adjusting the early/offset for
> the instr instance when setksmps is used.  Maybe we can just remove
> that code for asigs/a[]?
> 
> On Fri, Apr 4, 2014 at 1:26 PM, Victor Lazzarini
>  wrote:
>> I wonder why/if sample accurate needs to be handled at all at this level, as it's normally
>> handled at the opcode level (e.g. we don't have any special code at the instrument level
>> to handle it, since opcodes are more or less instruments internally).
>> 
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 4 Apr 2014, at 18:06, Steven Yi  wrote:
>> 
>>> * I implemented code for --sample-accurate and a[] UDO args.  I think
>>> it's working, but I heard some pops at the beginnings of notes, but I
>>> think this was using setksmps.  I get the impression from the code
>>> that there is a problem there anyways, that an opcode might try to
>>> handle offset/early itself, but the calling context in useropcd1/2
>>> also is doing some kind of offset/early handling and that there may be
>>> a conflict.  It's a bit beyond me at the moment so I've left it for
>>> now.
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I *think* so. :)  I followed the same code for a-var's, but I applied
it to all of the a-sigs within an a[] in the same way.

On Fri, Apr 4, 2014 at 1:47 PM, Victor Lazzarini
 wrote:
> oh yes, I think the only case where we need to worry about it is when we have local ksmps. I remember now.
> Is that what you've implemented?
>
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 4 Apr 2014, at 18:40, Steven Yi  wrote:
>
>> I'm not sure either, but there was code there for a-sigs so I followed
>> that.  I see that the code is already adjusting the early/offset for
>> the instr instance when setksmps is used.  Maybe we can just remove
>> that code for asigs/a[]?
>>
>> On Fri, Apr 4, 2014 at 1:26 PM, Victor Lazzarini
>>  wrote:
>>> I wonder why/if sample accurate needs to be handled at all at this level, as it's normally
>>> handled at the opcode level (e.g. we don't have any special code at the instrument level
>>> to handle it, since opcodes are more or less instruments internally).
>>>
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 4 Apr 2014, at 18:06, Steven Yi  wrote:
>>>
>>>> * I implemented code for --sample-accurate and a[] UDO args.  I think
>>>> it's working, but I heard some pops at the beginnings of notes, but I
>>>> think this was using setksmps.  I get the impression from the code
>>>> that there is a problem there anyways, that an opcode might try to
>>>> handle offset/early itself, but the calling context in useropcd1/2
>>>> also is doing some kind of offset/early handling and that there may be
>>>> a conflict.  It's a bit beyond me at the moment so I've left it for
>>>> now.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Then we’re good.
========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 4 Apr 2014, at 18:48, Steven Yi  wrote:

> I *think* so. :)  I followed the same code for a-var's, but I applied
> it to all of the a-sigs within an a[] in the same way.
> 
> On Fri, Apr 4, 2014 at 1:47 PM, Victor Lazzarini
>  wrote:
>> oh yes, I think the only case where we need to worry about it is when we have local ksmps. I remember now.
>> Is that what you've implemented?
>> 
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>> 
>> 
>> 
>> 
>> On 4 Apr 2014, at 18:40, Steven Yi  wrote:
>> 
>>> I'm not sure either, but there was code there for a-sigs so I followed
>>> that.  I see that the code is already adjusting the early/offset for
>>> the instr instance when setksmps is used.  Maybe we can just remove
>>> that code for asigs/a[]?
>>> 
>>> On Fri, Apr 4, 2014 at 1:26 PM, Victor Lazzarini
>>>  wrote:
>>>> I wonder why/if sample accurate needs to be handled at all at this level, as it's normally
>>>> handled at the opcode level (e.g. we don't have any special code at the instrument level
>>>> to handle it, since opcodes are more or less instruments internally).
>>>> 
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> NUI Maynooth, Ireland
>>>> victor dot lazzarini at nuim dot ie
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 4 Apr 2014, at 18:06, Steven Yi  wrote:
>>>> 
>>>>> * I implemented code for --sample-accurate and a[] UDO args.  I think
>>>>> it's working, but I heard some pops at the beginnings of notes, but I
>>>>> think this was using setksmps.  I get the impression from the code
>>>>> that there is a problem there anyways, that an opcode might try to
>>>>> handle offset/early itself, but the calling context in useropcd1/2
>>>>> also is doing some kind of offset/early handling and that there may be
>>>>> a conflict.  It's a bit beyond me at the moment so I've left it for
>>>>> now.
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Awesome, thanks!

On Fri, Apr 4, 2014 at 1:58 PM, Victor Lazzarini
 wrote:
> Then we're good.
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 4 Apr 2014, at 18:48, Steven Yi  wrote:
>
>> I *think* so. :)  I followed the same code for a-var's, but I applied
>> it to all of the a-sigs within an a[] in the same way.
>>
>> On Fri, Apr 4, 2014 at 1:47 PM, Victor Lazzarini
>>  wrote:
>>> oh yes, I think the only case where we need to worry about it is when we have local ksmps. I remember now.
>>> Is that what you've implemented?
>>>
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 4 Apr 2014, at 18:40, Steven Yi  wrote:
>>>
>>>> I'm not sure either, but there was code there for a-sigs so I followed
>>>> that.  I see that the code is already adjusting the early/offset for
>>>> the instr instance when setksmps is used.  Maybe we can just remove
>>>> that code for asigs/a[]?
>>>>
>>>> On Fri, Apr 4, 2014 at 1:26 PM, Victor Lazzarini
>>>>  wrote:
>>>>> I wonder why/if sample accurate needs to be handled at all at this level, as it's normally
>>>>> handled at the opcode level (e.g. we don't have any special code at the instrument level
>>>>> to handle it, since opcodes are more or less instruments internally).
>>>>>
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> NUI Maynooth, Ireland
>>>>> victor dot lazzarini at nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4 Apr 2014, at 18:06, Steven Yi  wrote:
>>>>>
>>>>>> * I implemented code for --sample-accurate and a[] UDO args.  I think
>>>>>> it's working, but I heard some pops at the beginnings of notes, but I
>>>>>> think this was using setksmps.  I get the impression from the code
>>>>>> that there is a problem there anyways, that an opcode might try to
>>>>>> handle offset/early itself, but the calling context in useropcd1/2
>>>>>> also is doing some kind of offset/early handling and that there may be
>>>>>> a conflict.  It's a bit beyond me at the moment so I've left it for
>>>>>> now.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net