Thanks for the information.

It looks like I went ahead and created an opcode for determining whether an 
fsig is available (actually, whether it is about to become un-available) 
because my hasty search did not find pvsftw.

However, I will leave my new opcode in place, because the pvsftw opcode 
involves writing to an ftable, which is not always necessary.

Regards,
Mike

----- Original Message ----- 
From: "Richard Dobson" 
To: "Developer discussions" 
Sent: Thursday, May 15, 2008 7:48 PM
Subject: Re: [Cs-dev] Linear algebra and fsigs - attention Victor Lazzarini


> [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
> 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