[Csnd] PVS fft latency question

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Csnd] PVS fft latency question

Jeanette C.
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
[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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Steven Yi
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. <[hidden email]> 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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Tim Mortimer
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 ...)
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Jeanette C.
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
[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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Tim Mortimer
> 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 ...





Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Steven Yi
In reply to this post by Jeanette C.
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. <[hidden email]> 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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Richard
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. <[hidden email]> 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
>> [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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Steven Yi
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 <[hidden email]> 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. <[hidden email]> 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
>>> [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
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] PVS fft latency question

Nathan Holmes
Tim Mortimer wrote,
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 ..   

It might be getting this thread off-topic a little, but regarding the TRACKS PV stream approach, there is the trsplit opcode, which splits a TRACKS PV stream in two around a frequency. By applying that successively, you could carve out some groups of partials, and then manipulate the amplitudes of each group during resynthesis by modifying the kscal parameter in tradsyn/resyn/sinsyn. (Or by applying an amplitude envelope to the resynthesized output of a group.)

There's also the trlowest and trhighest opcodes, which could be combined with trsplit. (E.g. split a partial track at 300 Hz and then use trlowest on the upper stream to get the lowest partial above 300 Hz.)

Unfortunately, in my experience so far, partials produced this way tend to be really "clicky" from sudden onsets and no release time. Resynthesizing by using the k-rate amp and freq values with e.g. oscil3 (instead of using tradsyn) allows the possibility of smoothing the amplitude yourself, which can help somewhat. Still may not be ideal even with smoothing, but it's another option to play around with.


On Thu, Aug 24, 2017 at 8:48 AM, Steven Yi <[hidden email]> wrote:
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 <[hidden email]> 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. <[hidden email]> 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
>>> [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