Csound Csound-dev Csound-tekno Search About

[Cs-dev] i(k1 OP k2)

Date2012-01-28 14:26
FromTito Latini
Subject[Cs-dev] i(k1 OP k2)
AttachmentsNone  

Date2012-01-28 15:06
FromSteven Yi
SubjectRe: [Cs-dev] i(k1 OP k2)
This is interesting.  I'm trying to imagine if there are any backwards
incompatibilities.  A side effect of this is that it would seem then
that one wouldn't need to to use 'init' for k- and a-vars and could
use 'kval = 0' and have it be valid in the initial i-pass.

I'm wondering though, the init pass is a curious thing, especially
with if-then's.  I'm wondering about something like:

kstate init 0

if (kstate == 0) then
  ...do something...
  kstate = 1

else
  kstate = 2

endif

if there is a change to do i-time assignment and expression changes,
wouldn't kstate = 2 after the init-pass?  I'm thinking that k-rate
if-then's would have their opcodes still initialized in init pass.

On Sat, Jan 28, 2012 at 9:26 AM, Tito Latini  wrote:
> I have found a solution for the i() problem in csound list.
> This is worth for the general case
>
>  ivar = FN(k1 OP k2)
>
> This is what currently happens:
>
> i(k1 `op` k2)
>
>  -> k0 op.kk k1 k2
>     i(k0)
>
> but in entry.c, all OP.kk don't have a init function. For example:
>
>  { "add.kk",  S(AOP), 2, "k", "kk", NULL, addkk }
>
> therefore k0 is 0 during the first init pass and fn(k0) fails.
> The simplest solution is
>
>  { "add.kk",  S(AOP), 3, "k", "kk", addkk, addkk }
>
> Idem for FN.k
>
> In this way we can write
>
>  i(k1 + k3 * abs(k4 / k6) OP FN(k7 ...) ...)
>
> This solution costs an operation during the init pass with the normal
> k-rate operations.
>
> Besides, after the changes, it'is simple to add this syntax
>
>  ivar = k1 OP k2 OP .. FN(...) ...
>
> The alternative is to change `create_expression` in
> csound_orc_expression.c, OP.ii and FN.i if the function is i(), or if
> the left side of `=' is an i-variable, but it requires more changes.
>
> tito
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2012-01-28 15:39
FromTito Latini
SubjectRe: [Cs-dev] i(k1 OP k2)
AttachmentsNone  

Date2012-01-28 15:47
FromTito Latini
SubjectRe: [Cs-dev] i(k1 OP k2)
AttachmentsNone  

Date2012-01-28 16:03
FromSteven Yi
SubjectRe: [Cs-dev] i(k1 OP k2)
I think this is still not correct.  The tricky thing is that it seems
correct, but the problem is being masked.  All of the opcodes in the
chain get init methods called if there are krate if-then's.  The if
doesn't get performed until k-time (I believe). You're printing
istate1 but that's not the variable that's really important here, but
the kstate.  If after i-pass, with your changes, I imagine kstate
would be 100, due to it having an init method now.

On Sat, Jan 28, 2012 at 10:47 AM, Tito Latini  wrote:
> Ah no, it seems correct because
>
> 
> 
>
> instr 1
> kstate init 1
> if (kstate == 0) then
>  istate1 = 1
>  kstate = 10
> else
>  kstate = 100
> endif
>
> print istate1
>
> endin
> 
> 
> i1 0 1
> 
> 
>
> csound test.csd
> ...
> instr 1:  istate1 = 1.000
> ...
>
> In general, we have to also modify "=.k" (minit for init and krate)
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2012-01-28 16:03
Fromjpff@cs.bath.ac.uk
SubjectRe: [Cs-dev] i(k1 OP k2)
I am very unhappy about this.  it is a general rule that k-rate values are
not valued in the i-pass.  It is true that gk variables MAY have a value
but that is not guaranteed.  This is a semantic change that seems wrong
top me
==John

> Ah no, it seems correct because
>
> 
> 
>
> instr 1
> kstate init 1
> if (kstate == 0) then
>   istate1 = 1
>   kstate = 10
> else
>   kstate = 100
> endif
>
> print istate1
>
> endin
> 
> 
> i1 0 1
> 
> 
>
> csound test.csd
> ...
> instr 1:  istate1 = 1.000
> ...
>
> In general, we have to also modify "=.k" (minit for init and krate)
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2012-01-28 16:12
FromTito Latini
SubjectRe: [Cs-dev] i(k1 OP k2)
AttachmentsNone  

Date2012-01-28 17:29
FromSteven Yi
SubjectRe: [Cs-dev] i(k1 OP k2)
Hi Tito,

Yes, it is normal, but certainly awkward.  The general advice I give
is never to mix i-time code with k-time code when using if-then.  In
practice, I think most people do this, so this scenario doesn't come
up often, but it's incredibly awkward when it does come up.

On the other hand, I need to review about when if-then's are evaluated
at i-time and when they are not.  The manual (from
http://csounds.com/manual/html/if.html
) says:

Note
Note that if the condition uses a k-rate variable (for instance, “if
kval > 0”), the if...goto or if...then statement will be ignored
during the i-time pass. This allows for opcode initialization, even if
the k-rate variable has already been assigned an appropriate value by
an earlier init statement.

I had to do a strange the thing with a UDO I was working on a while
back using an i-rate if-then together with a k-rate if-then just to
initialize a bank of recursive UDO's and optionally have adjustable
recursion at performance time.  It's not very transparent stuff
unfortunately.

On Sat, Jan 28, 2012 at 11:12 AM, Tito Latini  wrote:
> Ok, I now have a doubt; is this behavior normal?
> (code without changes)
>
> kval init 1
>
> if (kval == 0) then
>  ivar = 123
> endif
>
> print ivar
>
>
> result:
> ...
> instr 1: ivar = 123.000
> ...
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Date2012-01-28 18:21
FromTito Latini
SubjectRe: [Cs-dev] i(k1 OP k2)
AttachmentsNone  

Date2012-01-30 15:44
FromAndres Cabrera
SubjectRe: [Cs-dev] i(k1 OP k2)
AttachmentsNone  None  
Hi John,

I think this is good, and especially it should be consistent, otherwise it can be very confusing as it is now.

But I'm wondering, this would mean that many k-rate only opcodes (like invalue) would need to have a version added that works at init time.

In any case I think this should definitely be defined and fixed. It really makes doing complex work in Csound much harder and error prone than it could be. I don't mind if it is chosen to have all k-rate opcodes update values at initialization, or none of them.

Another option might be having some sort of syntax to run the initialization and a single control pass for an opcode and store the values in i-type variables. But this might be overkill.

Cheers,
Andrés

On Sat, Jan 28, 2012 at 4:03 PM, <jpff@cs.bath.ac.uk> wrote:

I am very unhappy about this.  it is a general rule that k-rate values are
not valued in the i-pass.  It is true that gk variables MAY have a value
but that is not guaranteed.  This is a semantic change that seems wrong
top me
==John

> Ah no, it seems correct because
>
> <CsoundSynthesizer>
> <CsInstruments>
>
> instr 1
> kstate init 1
> if (kstate == 0) then
>   istate1 = 1
>   kstate = 10
> else
>   kstate = 100
> endif
>
> print istate1
>
> endin
> </CsInstruments>
> <CsScore>
> i1 0 1
> </CsScore>
> </CsoundSynthesizer>
>
> csound test.csd
> ...
> instr 1:  istate1 = 1.000
> ...
>
> In general, we have to also modify "=.k" (minit for init and krate)
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel