An fsig always contains one window's worth of data and never more than
that. If you want to process an input fsig, you check its frame count 
against
an internal count and see if it is more recent.

 if (p->lastframe < p->fin->framecount) {
     for (i = 0; i < framesize; i += 2) {
        // process the frame
        ...
     }
     p->fout->framecount = p->lastframe = p->fin->framecount;
   }

Victor

> It does not make sense to implement this for the linear algebra opcodes, 
> but I need to understand how to make the array operations synchronize with 
> the f-sig variables. Is it ever the case that the f-sigs change at the 
> same rate as k-rate, or an integral multiple or divisor of k-rate? If so, 
> what is the governing relation so that a user of linear algebra with f-sig 
> variables can remain synchronized with them?  If there is an integral 
> ratio between the f-sig rate and k-rate, then the user can program linear 
> algebra operations at that ratio, e.g. if an f-sig changes 1/2 as often as 
> k-rate, then the user can operate on that f-sig only every other k-period 
> (obviously, it has to be just the right period!).
>
> Does doing this make sense? Does one fsig ever contain more than one 
> window's worth of data?
>
> Thanks,
> Mike
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I can't judge if it is practically relevant here, but one special case 
to be aware of is the sliding pvoc variant (overlap = 1) added recently 
by John Fitch following the work we described at ICMC last year; in this 
case the analysis frame is updated each sample, with the obvious 
consequences for krate processing (John can fill in the details). This 
form is hugely CPU-intensive, and is included "because we can" rather 
than in expectation of heavy usage. We guesstimate that ~at least~ an 
8-core machine fully exercised (somehow) will be needed to run it in 
real time. That said, it could prove very interesting to see what linear 
algebra opcodes can offer for sliding pvoc processing.

The pvsftw opcode sets an output krate flag when a new frame is 
available; this offers a means of synchronising general krate processes 
with a pvs stream at orchestra level, as an alternative to expressly 
reading an fsig as an input parameter.

Richard Dobson




victor wrote:
> An fsig always contains one window's worth of data and never more than
> that. If you want to process an input fsig, you check its frame count 
> against
> an internal count and see if it is more recent.
> 
>  if (p->lastframe < p->fin->framecount) {
>      for (i = 0; i < framesize; i += 2) {
>         // process the frame
>         ...
>      }
>      p->fout->framecount = p->lastframe = p->fin->framecount;
>    }
> 
> Victor
> 
>> It does not make sense to implement this for the linear algebra opcodes, 
>> but I need to understand how to make the array operations synchronize with 
>> the f-sig variables. Is it ever the case that the f-sigs change at the 
>> same rate as k-rate, or an integral multiple or divisor of k-rate? If so, 
>> what is the governing relation so that a user of linear algebra with f-sig 
>> variables can remain synchronized with them?  If there is an integral 
>> ratio between the f-sig rate and k-rate, then the user can program linear 
>> algebra operations at that ratio, e.g. if an f-sig changes 1/2 as often as 
>> k-rate, then the user can operate on that f-sig only every other k-period 
>> (obviously, it has to be just the right period!).
>>
>> Does doing this make sense? Does one fsig ever contain more than one 
>> window's worth of data?
>>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

[sending again]

I can't judge if it is practically relevant here, but one special case
to be aware of is the sliding pvoc variant (overlap = 1) added recently
by John Fitch following the work we described at ICMC last year; in this
case the analysis frame is updated each sample, with the obvious
consequences for krate processing (John can fill in the details). This
form is hugely CPU-intensive, and is included "because we can" rather
than in expectation of heavy usage. We guesstimate that ~at least~ an
8-core machine fully exercised (somehow) will be needed to run it in
real time. That said, it could prove very interesting to see what linear
algebra opcodes can offer for sliding pvoc processing.

The pvsftw opcode sets an output krate flag when a new frame is
available; this offers a means of synchronising general krate processes
with a pvs stream at orchestra level, as an alternative to expressly
reading an fsig as an input parameter.

Richard Dobson




victor wrote:
> An fsig always contains one window's worth of data and never more than
> that. If you want to process an input fsig, you check its frame count 
> against
> an internal count and see if it is more recent.
> 
>  if (p->lastframe < p->fin->framecount) {
>      for (i = 0; i < framesize; i += 2) {
>         // process the frame
>         ...
>      }
>      p->fout->framecount = p->lastframe = p->fin->framecount;
>    }
> 
> Victor
> 
>> It does not make sense to implement this for the linear algebra opcodes, 
>> but I need to understand how to make the array operations synchronize with 
>> the f-sig variables. Is it ever the case that the f-sigs change at the 
>> same rate as k-rate, or an integral multiple or divisor of k-rate? If so, 
>> what is the governing relation so that a user of linear algebra with f-sig 
>> variables can remain synchronized with them?  If there is an integral 
>> ratio between the f-sig rate and k-rate, then the user can program linear 
>> algebra operations at that ratio, e.g. if an f-sig changes 1/2 as often as 
>> k-rate, then the user can operate on that f-sig only every other k-period 
>> (obviously, it has to be just the right period!).
>>
>> Does doing this make sense? Does one fsig ever contain more than one 
>> window's worth of data?
>>



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net