Hey hey,
I've read in the PVS opcodes documentation that the FFT causes the latency as 
set up by the basic analysis parameters, but that there may be further 
latency. By what is this caused, can it be calculated, without having to be 
tested by some form of measurement?

Best wishes,

Jeanette

--------
* website: http://juliencoder.de - for summer is a state of sound
* SoundCloud: https://soundcloud.com/jeanette_c

Cinderella's got to go <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
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 Jeanette,

I didn't see anyone reply to this, so I'll take a stab at it.
(Hopefully if I'm wrong, it will attract those more knowledgeable than
me to correct me. :) )

I see that the manual mentions the signal is delayed by the window
size (http://csound.github.io/docs/manual/SpectralRealTime.html)
(though I would have thought the signal would be delayed by the hop
size... let's just keep going with Window Size here...).  Either way,
the amount of time could be calculated by the size of window divided
by sampling rate.  So if size is 1024 samples, and sr is 44100, then
delay is ~0.023 seconds. Additionally, because of Csound's f-sig
implementation, it is going to require that hop size divides evenly by
ksmps, or things will jitter a bit, adding further latency.

Hope that helps!
steven




On Fri, Aug 18, 2017 at 9:59 AM, Jeanette C.  wrote:
> Hey hey,
> I've read in the PVS opcodes documentation that the FFT causes the latency
> as set up by the basic analysis parameters, but that there may be further
> latency. By what is this caused, can it be calculated, without having to be
> tested by some form of measurement?
>
> Best wishes,
>
> Jeanette
>
> --------
> * website: http://juliencoder.de - for summer is a state of sound
> * SoundCloud: https://soundcloud.com/jeanette_c
>
> Cinderella's got to go <3
> (Britney Spears)
>
> Csound mailing list
> Csound@listserv.heanet.ie
> 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
Csound@listserv.heanet.ie
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

My understanding / implementation is working on the principle that the delay
is
(table size) + (overlap*2) samples

in my case generally 4096 + (128*2) = 4352 samples -. about 90 msecs @ sr =
48000

(overlap & hop being interchangeable, i think ... i'm a bit rusty ...)

i wasn't sure if the gist of the question was are there other contributing
factors however... 

as a blanket rule however, this is how i calculate delay offset, & the 1 or
2 times i've checked it, its been correct ...

Jeanette it seems you are into FFT stuff & a lot of your basic ideas seem
similar to mine (tracking partials & manipulating them ...) How are you
getting on performing this in csound? Are you finding any approaches
particularly fruitful? (the limitations of my approach are basically sounded
out in the 'pvscale' thread i started earlier today ... i create masks
assigning parts of the signal to groups & manipulate the amplitudes of the
groups in a table ... partial tracking etc doesn't seem to give me
sufficient access to amplitude manipulation of the spectrum ... unless
someone would like to suggest a strategy / opcode combination to the
contrary ...)



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-PVS-fft-latency-question-tp5757589p5757622.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
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 Tim,
Aug 23 2017, Tim Mortimer has written:
> (table size) + (overlap*2) samples
...
What is the table size in your example? The control-rate, as Steven
mentioned in his explanation?

Best wishes,
(the rest off-list, it gets rather personal in the approach :) )

Jeanette
>

--------
* website: http://juliencoder.de - for summer is a state of sound
* SoundCloud: https://soundcloud.com/jeanette_c

I'm so curious, what do you think of me <3
(Britney Spears)

Csound mailing list
Csound@listserv.heanet.ie
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

> What is the table size in your example?

4096 ... i.e. resulting in a 2048 bin analysis ...

hence 4096 + (2*128, being the 'hopsize' ...) 

that's the number of samples ... divide by sample rate to get delay in
seconds ...

>>> control rate ...

oh, ok, had to read Steven's post again ... usually my ksmps = my hopsize (i
believe you get a message saying 'no can do' if you try & run a csd at a
ksmps less than the hop size ... anyway, i do recall not being able to
reduce my kr beyond a certain value, & generally my fsig .csds are sitting
on ksmps = 128 ... perhaps that accounts for the neatness of my delay value
calculations ...)

that's probably all i can offer on that one ... which is why i dithered on
replying in the first place (obviously i have been lurking here on & off
over the last few days after a lengthy absence ...) - but did want to
supplement Steven's response by mentioning the 2*hopsize offset ...









--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-PVS-fft-latency-question-tp5757589p5757633.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
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

Sorry, the hop-size should be evenly divisible by ksmps. So if the hop
(or overlap) is every 32 samples, and you have ksmps = 64, I'm pretty
sure you'd have a problem as the fsig would not get updated correctly
(you'd get every other hop).  If hop is something like 192 and ksmps =
64, you'd get awkward issues with the adding part starting at the
wrong sample.  Generally it's not a huge problem as most situations
people use for ksmps/hopsize work out fine. (It's been a while since I
looked, but I think internally a change to make fsig be a vector of
analyses rather than a scalar would allow it to work with any ksmps,
but the additional processing might not be worth it...)



On Wed, Aug 23, 2017 at 5:56 PM, Jeanette C.  wrote:
> Hi Tim,
> Aug 23 2017, Tim Mortimer has written:
>>
>> (table size) + (overlap*2) samples
>
> ...
> What is the table size in your example? The control-rate, as Steven
> mentioned in his explanation?
>
> Best wishes,
> (the rest off-list, it gets rather personal in the approach :) )
>
> Jeanette
>>
>>
>
> --------
> * website: http://juliencoder.de - for summer is a state of sound
> * SoundCloud: https://soundcloud.com/jeanette_c
>
> I'm so curious, what do you think of me <3
> (Britney Spears)
>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> 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
Csound@listserv.heanet.ie
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

It has been such a long time since I looked at the pvs code (or used 
it!) that my memory of it must be suspect, but as I recall there is a 
little bit of code (a "tick function") that simply invokes frame 
generation when enough samples have been accumulated. The one 
requirement was that ksamps must be <= overlap, but otherwise there was 
no requirement of any simple relationship such as evenly divisible. In 
all cases frames are generated (and resyntheised) periodically, and 
while clearly CPU load fluctuates at the analysis rate, I would not 
expect an "odd" size of ksamps to affect general pvoc latency. It is not 
the case, for example, that the pvoc engine requires to be fed 
ksamps-sized blocks of samples; "generate_frame" etc is called within an 
internal sample loop, so ksamps can in principle (within the above 
constraint) be any value.

Richard Dobson


On 23/08/2017 23:23, Steven Yi wrote:
> Sorry, the hop-size should be evenly divisible by ksmps. So if the hop
> (or overlap) is every 32 samples, and you have ksmps = 64, I'm pretty
> sure you'd have a problem as the fsig would not get updated correctly
> (you'd get every other hop).  If hop is something like 192 and ksmps =
> 64, you'd get awkward issues with the adding part starting at the
> wrong sample.  Generally it's not a huge problem as most situations
> people use for ksmps/hopsize work out fine. (It's been a while since I
> looked, but I think internally a change to make fsig be a vector of
> analyses rather than a scalar would allow it to work with any ksmps,
> but the additional processing might not be worth it...)
> 
> 
> 
> On Wed, Aug 23, 2017 at 5:56 PM, Jeanette C.  wrote:
>> Hi Tim,
>> Aug 23 2017, Tim Mortimer has written:
>>>
>>> (table size) + (overlap*2) samples
>>
>> ...
>> What is the table size in your example? The control-rate, as Steven
>> mentioned in his explanation?
>>
>> Best wishes,
>> (the rest off-list, it gets rather personal in the approach :) )
>>
>> Jeanette
>>>
>>>
>>
>> --------
>> * website: http://juliencoder.de - for summer is a state of sound
>> * SoundCloud: https://soundcloud.com/jeanette_c
>>
>> I'm so curious, what do you think of me <3
>> (Britney Spears)
>>
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> 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
> Csound@listserv.heanet.ie
> 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
Csound@listserv.heanet.ie
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 Richard,

You're memory serves you well, and my understanding of that area of
the code failed me. :) I had missed the part about the outptr and its
use when I last looked through this code, so my error about ksmps
divisibility limitations (apologies all for the bad information!).

However, I think it would still be possible to permit ksmps > hop size
if we changed to use a vector within fsigs rather than scalar.  The
idea I had was to have a ksmps-sized array of data pointers that
pointed to an fsig data. Most of the pointers would be pointing to the
same data address until a new window was calculated, and that would
allow multiple windows per ksmps buffer.  I suppose that's sort of
where I left it as it would take some reworking of code, and I don't
know how often would it arise that one would need ksmps > hop size
(perhaps if using a mix of large ksmps, sample accurate, and
mulicore?).

Thanks again for the correction!
steven


On Thu, Aug 24, 2017 at 7:24 AM, Richard Dobson  wrote:
> It has been such a long time since I looked at the pvs code (or used it!)
> that my memory of it must be suspect, but as I recall there is a little bit
> of code (a "tick function") that simply invokes frame generation when enough
> samples have been accumulated. The one requirement was that ksamps must be
> <= overlap, but otherwise there was no requirement of any simple
> relationship such as evenly divisible. In all cases frames are generated
> (and resyntheised) periodically, and while clearly CPU load fluctuates at
> the analysis rate, I would not expect an "odd" size of ksamps to affect
> general pvoc latency. It is not the case, for example, that the pvoc engine
> requires to be fed ksamps-sized blocks of samples; "generate_frame" etc is
> called within an internal sample loop, so ksamps can in principle (within
> the above constraint) be any value.
>
> Richard Dobson
>
>
>
> On 23/08/2017 23:23, Steven Yi wrote:
>>
>> Sorry, the hop-size should be evenly divisible by ksmps. So if the hop
>> (or overlap) is every 32 samples, and you have ksmps = 64, I'm pretty
>> sure you'd have a problem as the fsig would not get updated correctly
>> (you'd get every other hop).  If hop is something like 192 and ksmps =
>> 64, you'd get awkward issues with the adding part starting at the
>> wrong sample.  Generally it's not a huge problem as most situations
>> people use for ksmps/hopsize work out fine. (It's been a while since I
>> looked, but I think internally a change to make fsig be a vector of
>> analyses rather than a scalar would allow it to work with any ksmps,
>> but the additional processing might not be worth it...)
>>
>>
>>
>> On Wed, Aug 23, 2017 at 5:56 PM, Jeanette C.  wrote:
>>>
>>> Hi Tim,
>>> Aug 23 2017, Tim Mortimer has written:
>>>>
>>>>
>>>> (table size) + (overlap*2) samples
>>>
>>>
>>> ...
>>> What is the table size in your example? The control-rate, as Steven
>>> mentioned in his explanation?
>>>
>>> Best wishes,
>>> (the rest off-list, it gets rather personal in the approach :) )
>>>
>>> Jeanette
>>>>
>>>>
>>>>
>>>
>>> --------
>>> * website: http://juliencoder.de - for summer is a state of sound
>>> * SoundCloud: https://soundcloud.com/jeanette_c
>>>
>>> I'm so curious, what do you think of me <3
>>> (Britney Spears)
>>>
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> 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
>> Csound@listserv.heanet.ie
>> 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
> Csound@listserv.heanet.ie
> 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
Csound@listserv.heanet.ie
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