|
|
|
|
hi mauro -
thanks for having looked into it. actually, i learned from you why
there is a big diference in initialization between
kVar myUdo in1, in2
and
kVar = myUdo:k(in1,in2)
you also pointed me to the manual page for xin/xout which explains it.
so, actually, i don't see the bug so far. i'd say, it is not intuitive,
but it was a decision in implementing the UDO feature. and if it were
to be changed now, it might break already existing code.
best regards -
joachim
On 26/08/18 17:07, Mauro Giubileo wrote:
Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUNDSend bugs reports to
https://github.com/csound/csound/issuesDiscussions of bugs and features can be posted here
|
|
|
One thing to note is that UDOs have both 'k' and 'K' types, with the
latter supposed to update at both init- and perf-times, and the former
supposed to only update at perf-time. I once made a proposal to make
'k' like 'K' [1] but retracted that proposal. I think if 'k' is
operating like 'K' it's a bug, and I would guess it was probably
introduced in Csound 6 when we added the type system. (Further
guessing it would have to do with having to initialize the
input/output variable, something necessary for compound data types
like fsigs and user-defined data types in CS7.)
If anyone has Csound 5 somewhere we could test that theory out.
The scope of the problem may also be particularly difficult to find by
users if writing to a gk variable. Restoring 'k' vs 'K' may cause
issues, but my initial hunch is that it's the right thing to do
(though, more research is necessary).
[1] - http://csound.1045644.n5.nabble.com/UDO-k-vs-K-td5721937.htmlOn Mon, Aug 27, 2018 at 1:58 AM joachim heintz < [hidden email]> wrote:
>
> hi mauro -
>
> thanks for having looked into it. actually, i learned from you why
> there is a big diference in initialization between
>
> kVar myUdo in1, in2
>
> and
>
> kVar = myUdo:k(in1,in2)
>
>
> you also pointed me to the manual page for xin/xout which explains it.
> so, actually, i don't see the bug so far. i'd say, it is not intuitive,
> but it was a decision in implementing the UDO feature. and if it were
> to be changed now, it might break already existing code.
>
> best regards -
>
> joachim
>
>
>
> On 26/08/18 17:07, Mauro Giubileo wrote:
> > Hi, it is my opinion that what you talk about in the section "Hidden
> > initialization via UDOs" actually could be a bug in Csound.
> >
> > I opened an issue here:
> > https://github.com/csound/csound/issues/1000#issue-354101223> >
> > Regards,
> > Mauro
> >
> >
> > Il 2018-08-25 09:46 joachim heintz ha scritto:
> >
> >> hi all -
> >>
> >> after having learned something about this somehow complicated matter,
> >> i have written a new section about "Hidden Initialization of k- and
> >> S-Variables" in the csound floss manual. it is at the end of this
> >> chapter:
> >> http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/> >>
> >> any corrections and suggestions welcome!
> >>
> >> cheers -
> >>
> >> joachim
> >>
> >> Csound mailing list
> >> [hidden email] <mailto: [hidden email]>
> >> 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 [hidden email]
> > <mailto: [hidden email]>
> > 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
> [hidden email]
> 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
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUNDSend bugs reports to
https://github.com/csound/csound/issuesDiscussions of bugs and features can be posted here
|
|
|
Hi Joachim,
after a more careful reading of the reference docs, I continue to think that this is a bug, not a feature by design. This comes out of a somewhat ambiguous definition of what actually happens in such situations.
The docs say:
These opcodes (xin/xout) actually run only at i-time. Performance time copying is done by the user opcode call.
To me, this means that,
at i-time (and only at i-time):
- xin/xout opcodes will copy the input/output parameters.
At k-time:
- xin/xout opcodes will be skipped. The k/a-time copies will be done by the caller statement.
Now the question is: should xin/xout opcodes, during their i-time pass, write values into k/a-type variables too? To me, they should not. The reference docs on xin/xout say nothing about this matter. Of course, now you can think: ok, that's just your opinion... No! It's not just my opinion, being that the reference docs say (about the 'init' opcode):
Note that init provides the only case of an init-time statement being permitted to write into a perf-time (k- or a-rate) result cell;
So, if init should be the ONLY init-time statement that can write into a perf-time variable too, why xin/xout opcodes (xin/xout run only at i-time, so they are i-time statements) should do that too? This is a contradiction...
Now, to me, if the Csound developers don't want to alter the actual behaviour to not risk of breaking existing code, I think at least they should update the reference docs about 'init' opcode and write something like that:
Note that init and xin/xout provide the only cases of an init-time statement being permitted to write into a perf-time (k- or a-rate) result cell;
Best Regards,
Mauro
Il 2018-08-27 07:58 joachim heintz ha scritto:
hi mauro - thanks for having looked into it. actually, i learned from you why there is a big diference in initialization between kVar myUdo in1, in2 and kVar = myUdo:k(in1,in2) you also pointed me to the manual page for xin/xout which explains it. so, actually, i don't see the bug so far. i'd say, it is not intuitive, but it was a decision in implementing the UDO feature. and if it were to be changed now, it might break already existing code. best regards - joachim On 26/08/18 17:07, Mauro Giubileo wrote:
Hi, it is my opinion that what you talk about in the section "Hidden
initialization via UDOs" actually could be a bug in Csound.
I opened an issue here:
https://github.com/csound/csound/issues/1000#issue-354101223
Regards,
Mauro
Il 2018-08-25 09:46 joachim heintz ha scritto:
hi all -
after having learned something about this somehow complicated matter,
i have written a new section about "Hidden Initialization of k- and
S-Variables" in the csound floss manual. it is at the end of this
chapter:
http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/
any corrections and suggestions welcome!
cheers -
joachim
Csound mailing list
[hidden email] <mailto:[hidden email]>
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 [hidden email]
<mailto:[hidden email]>
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 [hidden email] 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
[hidden email]
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
|
|
|
Hi Steven, I didn't know there could be 'k' and 'K' types in an opcode definition, but that just adds more confusion, being that actually 'k' works always as it would be 'K'... The k-type output variables are always copied both at init and performance-time. So, do you think this is a bug too?
Regards,
Mauro
Il 2018-08-27 08:37 Steven Yi ha scritto:
One thing to note is that UDOs have both 'k' and 'K' types, with the latter supposed to update at both init- and perf-times, and the former supposed to only update at perf-time. I once made a proposal to make 'k' like 'K' [1] but retracted that proposal. I think if 'k' is operating like 'K' it's a bug, and I would guess it was probably introduced in Csound 6 when we added the type system. (Further guessing it would have to do with having to initialize the input/output variable, something necessary for compound data types like fsigs and user-defined data types in CS7.) If anyone has Csound 5 somewhere we could test that theory out. The scope of the problem may also be particularly difficult to find by users if writing to a gk variable. Restoring 'k' vs 'K' may cause issues, but my initial hunch is that it's the right thing to do (though, more research is necessary). [1] - http://csound.1045644.n5.nabble.com/UDO-k-vs-K-td5721937.html On Mon, Aug 27, 2018 at 1:58 AM joachim heintz < [hidden email]> wrote:
hi mauro -
thanks for having looked into it. actually, i learned from you why
there is a big diference in initialization between
kVar myUdo in1, in2
and
kVar = myUdo:k(in1,in2)
you also pointed me to the manual page for xin/xout which explains it.
so, actually, i don't see the bug so far. i'd say, it is not intuitive,
but it was a decision in implementing the UDO feature. and if it were
to be changed now, it might break already existing code.
best regards -
joachim
On 26/08/18 17:07, Mauro Giubileo wrote:
Hi, it is my opinion that what you talk about in the section "Hidden
initialization via UDOs" actually could be a bug in Csound.
I opened an issue here:
https://github.com/csound/csound/issues/1000#issue-354101223
Regards,
Mauro
Il 2018-08-25 09:46 joachim heintz ha scritto:
hi all -
after having learned something about this somehow complicated matter,
i have written a new section about "Hidden Initialization of k- and
S-Variables" in the csound floss manual. it is at the end of this
chapter:
http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/
any corrections and suggestions welcome!
cheers -
joachim
Csound mailing list
[hidden email] <mailto:[hidden email]>
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 [hidden email]
<mailto:[hidden email]>
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
[hidden email]
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 [hidden email] 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
[hidden email]
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
|
|
|
That's what I wrote, that I think it's a bug, but needs more research
to verify cause and effects of any changes.
On Tue, Aug 28, 2018 at 6:20 AM Mauro Giubileo
< [hidden email]> wrote:
>
> Hi Steven, I didn't know there could be 'k' and 'K' types in an opcode definition, but that just adds more confusion, being that actually 'k' works always as it would be 'K'... The k-type output variables are always copied both at init and performance-time. So, do you think this is a bug too?
>
> Regards,
> Mauro
>
>
> Il 2018-08-27 08:37 Steven Yi ha scritto:
>
> One thing to note is that UDOs have both 'k' and 'K' types, with the
> latter supposed to update at both init- and perf-times, and the former
> supposed to only update at perf-time. I once made a proposal to make
> 'k' like 'K' [1] but retracted that proposal. I think if 'k' is
> operating like 'K' it's a bug, and I would guess it was probably
> introduced in Csound 6 when we added the type system. (Further
> guessing it would have to do with having to initialize the
> input/output variable, something necessary for compound data types
> like fsigs and user-defined data types in CS7.)
>
> If anyone has Csound 5 somewhere we could test that theory out.
>
> The scope of the problem may also be particularly difficult to find by
> users if writing to a gk variable. Restoring 'k' vs 'K' may cause
> issues, but my initial hunch is that it's the right thing to do
> (though, more research is necessary).
>
> [1] - http://csound.1045644.n5.nabble.com/UDO-k-vs-K-td5721937.html> On Mon, Aug 27, 2018 at 1:58 AM joachim heintz < [hidden email]> wrote:
>
>
> hi mauro -
>
> thanks for having looked into it. actually, i learned from you why
> there is a big diference in initialization between
>
> kVar myUdo in1, in2
>
> and
>
> kVar = myUdo:k(in1,in2)
>
>
> you also pointed me to the manual page for xin/xout which explains it.
> so, actually, i don't see the bug so far. i'd say, it is not intuitive,
> but it was a decision in implementing the UDO feature. and if it were
> to be changed now, it might break already existing code.
>
> best regards -
>
> joachim
>
>
>
> On 26/08/18 17:07, Mauro Giubileo wrote:
>
> Hi, it is my opinion that what you talk about in the section "Hidden
> initialization via UDOs" actually could be a bug in Csound.
>
> I opened an issue here:
> https://github.com/csound/csound/issues/1000#issue-354101223>
> Regards,
> Mauro
>
>
> Il 2018-08-25 09:46 joachim heintz ha scritto:
>
> hi all -
>
> after having learned something about this somehow complicated matter,
> i have written a new section about "Hidden Initialization of k- and
> S-Variables" in the csound floss manual. it is at the end of this
> chapter:
> http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/>
> any corrections and suggestions welcome!
>
> cheers -
>
> joachim
>
> Csound mailing list
> [hidden email] <mailto: [hidden email]>
> 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 [hidden email]
> <mailto: [hidden email]>
> 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
> [hidden email]
> 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
> [hidden email]
> 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 [hidden email] 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
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUNDSend bugs reports to
https://github.com/csound/csound/issuesDiscussions of bugs and features can be posted here
|
|
|
Ah, ok, sorry. :-)
Il 2018-08-28 18:36 Steven Yi ha scritto:
That's what I wrote, that I think it's a bug, but needs more research to verify cause and effects of any changes. On Tue, Aug 28, 2018 at 6:20 AM Mauro Giubileo < [hidden email]> wrote:
Hi Steven, I didn't know there could be 'k' and 'K' types in an opcode definition, but that just adds more confusion, being that actually 'k' works always as it would be 'K'... The k-type output variables are always copied both at init and performance-time. So, do you think this is a bug too?
Regards,
Mauro
Il 2018-08-27 08:37 Steven Yi ha scritto:
One thing to note is that UDOs have both 'k' and 'K' types, with the
latter supposed to update at both init- and perf-times, and the former
supposed to only update at perf-time. I once made a proposal to make
'k' like 'K' [1] but retracted that proposal. I think if 'k' is
operating like 'K' it's a bug, and I would guess it was probably
introduced in Csound 6 when we added the type system. (Further
guessing it would have to do with having to initialize the
input/output variable, something necessary for compound data types
like fsigs and user-defined data types in CS7.)
If anyone has Csound 5 somewhere we could test that theory out.
The scope of the problem may also be particularly difficult to find by
users if writing to a gk variable. Restoring 'k' vs 'K' may cause
issues, but my initial hunch is that it's the right thing to do
(though, more research is necessary).
[1] - http://csound.1045644.n5.nabble.com/UDO-k-vs-K-td5721937.html
On Mon, Aug 27, 2018 at 1:58 AM joachim heintz <[hidden email]> wrote:
hi mauro -
thanks for having looked into it. actually, i learned from you why
there is a big diference in initialization between
kVar myUdo in1, in2
and
kVar = myUdo:k(in1,in2)
you also pointed me to the manual page for xin/xout which explains it.
so, actually, i don't see the bug so far. i'd say, it is not intuitive,
but it was a decision in implementing the UDO feature. and if it were
to be changed now, it might break already existing code.
best regards -
joachim
On 26/08/18 17:07, Mauro Giubileo wrote:
Hi, it is my opinion that what you talk about in the section "Hidden
initialization via UDOs" actually could be a bug in Csound.
I opened an issue here:
https://github.com/csound/csound/issues/1000#issue-354101223
Regards,
Mauro
Il 2018-08-25 09:46 joachim heintz ha scritto:
hi all -
after having learned something about this somehow complicated matter,
i have written a new section about "Hidden Initialization of k- and
S-Variables" in the csound floss manual. it is at the end of this
chapter:
http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/
any corrections and suggestions welcome!
cheers -
joachim
Csound mailing list
[hidden email] <mailto:[hidden email]>
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 [hidden email]
<mailto:[hidden email]>
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
[hidden email]
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
[hidden email]
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 [hidden email] 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 [hidden email] 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
[hidden email]
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
|
|
Locked
