I was thinking we could perhaps add phase locking to pvsfread to  
improve timescaling quality. What would be your opinion (perhaps  
Richard Dobson might have something to say).

Regards

Victor

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sure; OK by me, One of the many things I have never got round to looking 
at; though I did incorporate some experimental "bin-bunching" p/l code 
into the  SPV. Not sure if that got into the Csound implementation, and 
doubtless needs all manner of development and refinement. Relevant 
perhaps even more to pitch shifting, of course,  time-scaling not being 
available or feasible with the sliding form.

With respect specifically to pvsfread, might it in principle also be 
possible to incorporate one or other time-frequency reassigment 
(transient detection) methods?

Richard Dobson


On 30/01/2010 15:35, Victor Lazzarini wrote:
> I was thinking we could perhaps add phase locking to pvsfread to
> improve timescaling quality. What would be your opinion (perhaps
> Richard Dobson might have something to say).
>
> Regards
>
> Victor
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I guess for transient detection to be useful, it would need to control  
timescaling directly, by temporarily blocking timescaling. Since  
pvfsread does not know anything about timescaling (it takes in time  
positions), we would need a version that controls timescale directly,  
instead.

Is the bin-punching code in pvsanal? I have not seen it there? I am  
thinking here more in terms of the jumping version, but I guess it's  
good to be placed in both versions. This code might be the starting  
point.

I have an idea of how phase locking works, but I have not yet thought  
too much about how to implement. I guess I'll go back to the  
references and start from there. Or perhaps I should ask  someone else  
in my lab to look at it (but I am curious on how to do it, so I might  
learn it myself).

I'll probably come back here to ask for opinions.

Regards

Victor

On 30 Jan 2010, at 16:04, Richard Dobson wrote:

> Sure; OK by me, One of the many things I have never got round to  
> looking
> at; though I did incorporate some experimental "bin-bunching" p/l code
> into the  SPV. Not sure if that got into the Csound implementation,  
> and
> doubtless needs all manner of development and refinement. Relevant
> perhaps even more to pitch shifting, of course,  time-scaling not  
> being
> available or feasible with the sliding form.
>
> With respect specifically to pvsfread, might it in principle also be
> possible to incorporate one or other time-frequency reassigment
> (transient detection) methods?
>
> Richard Dobson
>
>
> On 30/01/2010 15:35, Victor Lazzarini wrote:
>> I was thinking we could perhaps add phase locking to pvsfread to
>> improve timescaling quality. What would be your opinion (perhaps
>> Richard Dobson might have something to say).
>>
>> Regards
>>
>> Victor
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 30/01/2010 17:18, Victor Lazzarini wrote:
..
> Is the bin-punching code in pvsanal? I have not seen it there?

looks like it isn't. It was in a separate program from my mainstream spv 
code. Probably just as well, it has some obvious shortcuts, such as not 
properly computing the interpolated true centre frequency of a peak, but 
simply taking that of the loudest bin.

>
> I have an idea of how phase locking works, but I have not yet thought
> too much about how to implement.

In brief, my code (for pitch shifting) does this:

stepping through the amp/freq frame:
    find local peak: (defined as the group of bins
       framed by a  pair of troughs)
    find centre frequency of this peak
    compute the required linear shift value using centre frequency and
     requested pitch shift
    add this shift identically to all bins in this group.


It's a very simple algorithm with the SPV as all bins have the full 
bandwidth, so I don't have to deal with putting frequencies in the 
"right" bin. I made two versions, one just comparing the single bin 
above and below the "current" bin; and another comparing the pair of 
bins above and below; I forget what differences there were, but at last 
with my test sources the differences were surprisingly minor. I still 
got smearing on percussive sources, but it at least ~seemed~ to be a bit 
less than with conventional (straight multiplicative) shifting. 
Certainly not worse.

So that is my interpretation of phase locking with amp/freq frames: you 
are shifting a set of bins corresponding to a source frequency 
component, and the distance in Hz between them should be kept constant 
as the group is shifted.

As a sheer guess, presumably something similar needs to be done for 
time-scaling, such as: instead of computing the new phase independently 
for each bin, for a detected peak the phase difference should be the 
same for all bins in that group.

Or something. Some sort of transient detection must really be involved 
for clean timescaling, as somewhat obviously a stretched attack is by 
definition somewhat softer than the original. So I do expect phase 
locking for timescaling to be more involved than pitch scaling.




Richard Dobson



------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Do you think there is a way of doing phase locking in AMP-FREQ format  
(ie., in the case of csound before pvsynth does its job), or is it  
something we should do at the integration point?

Victor

On 30 Jan 2010, at 18:22, Richard Dobson wrote:

> On 30/01/2010 17:18, Victor Lazzarini wrote:
> ..
>> Is the bin-punching code in pvsanal? I have not seen it there?
>
> looks like it isn't. It was in a separate program from my mainstream  
> spv
> code. Probably just as well, it has some obvious shortcuts, such as  
> not
> properly computing the interpolated true centre frequency of a peak,  
> but
> simply taking that of the loudest bin.
>
>>
>> I have an idea of how phase locking works, but I have not yet thought
>> too much about how to implement.
>
> In brief, my code (for pitch shifting) does this:
>
> stepping through the amp/freq frame:
>    find local peak: (defined as the group of bins
>       framed by a  pair of troughs)
>    find centre frequency of this peak
>    compute the required linear shift value using centre frequency and
>     requested pitch shift
>    add this shift identically to all bins in this group.
>
>
> It's a very simple algorithm with the SPV as all bins have the full
> bandwidth, so I don't have to deal with putting frequencies in the
> "right" bin. I made two versions, one just comparing the single bin
> above and below the "current" bin; and another comparing the pair of
> bins above and below; I forget what differences there were, but at  
> last
> with my test sources the differences were surprisingly minor. I still
> got smearing on percussive sources, but it at least ~seemed~ to be a  
> bit
> less than with conventional (straight multiplicative) shifting.
> Certainly not worse.
>
> So that is my interpretation of phase locking with amp/freq frames:  
> you
> are shifting a set of bins corresponding to a source frequency
> component, and the distance in Hz between them should be kept constant
> as the group is shifted.
>
> As a sheer guess, presumably something similar needs to be done for
> time-scaling, such as: instead of computing the new phase  
> independently
> for each bin, for a detected peak the phase difference should be the
> same for all bins in that group.
>
> Or something. Some sort of transient detection must really be involved
> for clean timescaling, as somewhat obviously a stretched attack is by
> definition somewhat softer than the original. So I do expect phase
> locking for timescaling to be more involved than pitch scaling.
>
>
>
>
> Richard Dobson
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I guess implementing this would improve the pitch scaling in pvscale.  
Currently it does not check for peaks, just shifts all bins (and  
reposition them) by the requested amount. I can certainly have a  stab  
at it.

Thanks for the tips.

Victor

On 30 Jan 2010, at 18:22, Richard Dobson wrote:

> In brief, my code (for pitch shifting) does this:
>
> stepping through the amp/freq frame:
>    find local peak: (defined as the group of bins
>       framed by a  pair of troughs)
>    find centre frequency of this peak
>    compute the required linear shift value using centre frequency and
>     requested pitch shift
>    add this shift identically to all bins in this group.


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sorry to come in like this but...

I would be happy to pay for phase locking to be added to pvs! It would  
make csound the best FFT tool around, even better than it is right now!

This is an amazing idea. It would be very very nice if phase locking  
could somehow be integrated in the pvsftw and pvsftr too.

Thanks!

Peiman

On 30 Jan 2010, at 15:35, Victor Lazzarini wrote:

> I was thinking we could perhaps add phase locking to pvsfread to
> improve timescaling quality. What would be your opinion (perhaps
> Richard Dobson might have something to say).
>
> Regards
>
> Victor
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think the main thing to think here is to see where phase locking  
should occur, at analysis,
transformation or resynthesis.

If say we decide it's in resynthesis, then we would implement it as an  
option to pvsynth. So you can turn it on whenever it makes sense to  
use it. That way this could be applied to any of the signal processes  
implemented in pvs format.

Victor

On 30 Jan 2010, at 18:56, Peiman Khosravi wrote:

> Sorry to come in like this but...
>
> I would be happy to pay for phase locking to be added to pvs! It would
> make csound the best FFT tool around, even better than it is right  
> now!
>
> This is an amazing idea. It would be very very nice if phase locking
> could somehow be integrated in the pvsftw and pvsftr too.
>
> Thanks!
>
> Peiman
>
> On 30 Jan 2010, at 15:35, Victor Lazzarini wrote:
>
>> I was thinking we could perhaps add phase locking to pvsfread to
>> improve timescaling quality. What would be your opinion (perhaps
>> Richard Dobson might have something to say).
>>
>> Regards
>>
>> Victor
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That sound like a great addition.

Thanks

Peiman

On 30 Jan 2010, at 19:04, Victor Lazzarini wrote:

> I think the main thing to think here is to see where phase locking
> should occur, at analysis,
> transformation or resynthesis.
>
> If say we decide it's in resynthesis, then we would implement it as an
> option to pvsynth. So you can turn it on whenever it makes sense to
> use it. That way this could be applied to any of the signal processes
> implemented in pvs format.
>
> Victor
>
> On 30 Jan 2010, at 18:56, Peiman Khosravi wrote:
>
>> Sorry to come in like this but...
>>
>> I would be happy to pay for phase locking to be added to pvs! It  
>> would
>> make csound the best FFT tool around, even better than it is right
>> now!
>>
>> This is an amazing idea. It would be very very nice if phase locking
>> could somehow be integrated in the pvsftw and pvsftr too.
>>
>> Thanks!
>>
>> Peiman
>>
>> On 30 Jan 2010, at 15:35, Victor Lazzarini wrote:
>>
>>> I was thinking we could perhaps add phase locking to pvsfread to
>>> improve timescaling quality. What would be your opinion (perhaps
>>> Richard Dobson might have something to say).
>>>
>>> Regards
>>>
>>> Victor
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term
>>> contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, for pvsfread, the analysis has already been done; which is, in 
part, the problem, as it will very likely be amp/freq; and I have a 
nasty suspicion it needs to be done at the analysis stage, as it 
involves (as I have speculated the process) a modified phase 
accumulation algorithm. If it is possible to wind this back, so to 
speak, it may be possible to do it in pvsfread whenever frames are being 
interpolated for time-scaling purposes. Unfortunately that sounds like 
quite a big "if".  Maybe it can be done at resynthesis, when one is 
going back to real/imag anyway, but I am far from certain about that. 
All the extant descriptions of this for time-scaling seem to consider 
only a single all-in-one process. This may be one of those situations 
where the modular scheme of pvs may actually not help.


Richard Dobson


On 30/01/2010 19:04, Victor Lazzarini wrote:
> I think the main thing to think here is to see where phase locking
> should occur, at analysis,
> transformation or resynthesis.
>
> If say we decide it's in resynthesis, then we would implement it as an
> option to pvsynth. So you can turn it on whenever it makes sense to
> use it. That way this could be applied to any of the signal processes
> implemented in pvs format.
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I do not see that it would be appropriate (or even possible) for the 
table read/write opcodes, as they are inherently "low-level" raw 
transfers. Phase locking is specifically associated with (in this 
instance) time-scaling, i.e. the presence of some scaling parameter; 
and, as we are speculating, by the time frames are even in amp/phase 
format, it may be "too late" (or alternatively, "too early"). By the 
time the data is even in amp/phase format, the assumptions about the 
frequency evolution of each bin have been made and acted on.

How is it implemented in PD?


Richard Dobson

On 30/01/2010 18:56, Peiman Khosravi wrote:
> Sorry to come in like this but...
[tempting notion snipped...]
>
> This is an amazing idea. It would be very very nice if phase locking
> could somehow be integrated in the pvsftw and pvsftr too.
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The PD implementation I know of is a fft->lock->scale->ifft, so the  
phase locking is integrated into the analysis process. But his data is  
kept in re-im form, he only transforms it to amp-freq (phase delta) on  
the go before he calculates what the output frame has to be.
I'ts  a bit cumbersome to look at.

But for us what this means is that locking seems to be tied up with  
the timescaling process, but as the data is not analysed into amp-freq  
beforehand, it might be hard to implement in the pvs model.

Victor


On 30 Jan 2010, at 19:55, Richard Dobson wrote:

> I do not see that it would be appropriate (or even possible) for the
> table read/write opcodes, as they are inherently "low-level" raw
> transfers. Phase locking is specifically associated with (in this
> instance) time-scaling, i.e. the presence of some scaling parameter;
> and, as we are speculating, by the time frames are even in amp/phase
> format, it may be "too late" (or alternatively, "too early"). By the
> time the data is even in amp/phase format, the assumptions about the
> frequency evolution of each bin have been made and acted on.
>
> How is it implemented in PD?
>
>
> Richard Dobson
>
> On 30/01/2010 18:56, Peiman Khosravi wrote:
>> Sorry to come in like this but...
> [tempting notion snipped...]
>>
>> This is an amazing idea. It would be very very nice if phase locking
>> could somehow be integrated in the pvsftw and pvsftr too.
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is it out of the question to add phase data to the amp-freq pairs?

Best

Peiman

On 30 Jan 2010, at 20:47, Victor Lazzarini wrote:

> The PD implementation I know of is a fft->lock->scale->ifft, so the
> phase locking is integrated into the analysis process. But his data is
> kept in re-im form, he only transforms it to amp-freq (phase delta) on
> the go before he calculates what the output frame has to be.
> I'ts  a bit cumbersome to look at.
>
> But for us what this means is that locking seems to be tied up with
> the timescaling process, but as the data is not analysed into amp-freq
> beforehand, it might be hard to implement in the pvs model.
>
> Victor
>
>
> On 30 Jan 2010, at 19:55, Richard Dobson wrote:
>
>> I do not see that it would be appropriate (or even possible) for the
>> table read/write opcodes, as they are inherently "low-level" raw
>> transfers. Phase locking is specifically associated with (in this
>> instance) time-scaling, i.e. the presence of some scaling parameter;
>> and, as we are speculating, by the time frames are even in amp/phase
>> format, it may be "too late" (or alternatively, "too early"). By the
>> time the data is even in amp/phase format, the assumptions about the
>> frequency evolution of each bin have been made and acted on.
>>
>> How is it implemented in PD?
>>
>>
>> Richard Dobson
>>
>> On 30/01/2010 18:56, Peiman Khosravi wrote:
>>> Sorry to come in like this but...
>> [tempting notion snipped...]
>>>
>>> This is an amazing idea. It would be very very nice if phase locking
>>> could somehow be integrated in the pvsftw and pvsftr too.
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Perhaps what is needed is an opcode such as might be called "pvssfread", 
which specifically reads a soundfile and integrates time-scaling with 
the analysis, with the output being a standard fsig.  Nice if it 
supported multi-channel, i.e. delivered multiple output fsigs. How 
flexible and variable such an opcode could be is perhaps the Interesting 
Question.

Richard Dobson

On 30/01/2010 20:47, Victor Lazzarini wrote:
> The PD implementation I know of is a fft->lock->scale->ifft, so the
> phase locking is integrated into the analysis process. But his data is
> kept in re-im form, he only transforms it to amp-freq (phase delta) on
> the go before he calculates what the output frame has to be.
> I'ts a bit cumbersome to look at.
>
> But for us what this means is that locking seems to be tied up with the
> timescaling process, but as the data is not analysed into amp-freq
> beforehand, it might be hard to implement in the pvs model.
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, pvsifd already does that, as it outputs both amp+freq and amp 
+phase. This could be used perhaps.

On 30 Jan 2010, at 20:55, Peiman Khosravi wrote:

> Is it out of the question to add phase data to the amp-freq pairs?
>
> Best
>
> Peiman
>
> On 30 Jan 2010, at 20:47, Victor Lazzarini wrote:
>
>> The PD implementation I know of is a fft->lock->scale->ifft, so the
>> phase locking is integrated into the analysis process. But his data  
>> is
>> kept in re-im form, he only transforms it to amp-freq (phase delta)  
>> on
>> the go before he calculates what the output frame has to be.
>> I'ts  a bit cumbersome to look at.
>>
>> But for us what this means is that locking seems to be tied up with
>> the timescaling process, but as the data is not analysed into amp- 
>> freq
>> beforehand, it might be hard to implement in the pvs model.
>>
>> Victor
>>
>>
>> On 30 Jan 2010, at 19:55, Richard Dobson wrote:
>>
>>> I do not see that it would be appropriate (or even possible) for the
>>> table read/write opcodes, as they are inherently "low-level" raw
>>> transfers. Phase locking is specifically associated with (in this
>>> instance) time-scaling, i.e. the presence of some scaling parameter;
>>> and, as we are speculating, by the time frames are even in amp/phase
>>> format, it may be "too late" (or alternatively, "too early"). By the
>>> time the data is even in amp/phase format, the assumptions about the
>>> frequency evolution of each bin have been made and acted on.
>>>
>>> How is it implemented in PD?
>>>
>>>
>>> Richard Dobson
>>>
>>> On 30/01/2010 18:56, Peiman Khosravi wrote:
>>>> Sorry to come in like this but...
>>> [tempting notion snipped...]
>>>>
>>>> This is an amazing idea. It would be very very nice if phase  
>>>> locking
>>>> could somehow be integrated in the pvsftw and pvsftr too.
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term
>>> contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 30/01/2010 20:55, Peiman Khosravi wrote:
> Is it out of the question to add phase data to the amp-freq pairs?
>

Probably. Since we are talking about the PVOCEX file format, which I 
have no taste for changing. And the whole 'phase' aspect of pvoc is the 
~accumulation~ of phase frame by frame. Probably the standard amp/freq 
format is simply not useful, for phase-locked time-scaling. And from 
what Victor said about PD, any amp/freq representation is strictly post 
time-scaling, and somewhat temporary. Time-scaling is in this sense 
paradigmatically different from pitch scaling.

Richard Dobson


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 30/01/2010 21:09, Victor Lazzarini wrote:
> Well, pvsifd already does that, as it outputs both amp+freq and amp
> +phase. This could be used perhaps.
>

I wondered about that; but it seems that for phase-locked time-scaling 
we really do need to be able to get at the FFT data ~before~ even the 
conversion to accumulated phase. I assumed your phase output was 
similarly accumulated, but if it is 'raw', maybe there is scope.

Richard Dobson


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That is a good idea.

Looking at Miller's PD code, it's interesting to see the way it's  
implemented. I'll summarise:

1. Input comes in the form of two overlapped windows (1/4 frame overlap)
2. The phases of the previous output are kept.
3. The 1st input window phases are subtracted from the previous output  
ones
4. These phases are locked (explained below) (or not)
5. The output then is composed of 2nd input magnitudes, and the sum of
the phases from step 4 (containing either locked phases or the  
previous output phases minus the 1st input phases) and the 2nd input  
phases.

The input can jump to different positions in the soundfile. So,  
locking apart, what he seems to do is to accumulate phase differences  
just as in our process (the phase differences between a frame and its  
1/4-frame-overlap previous). Interestingly, there is no interpolation  
of magnitudes and frequencies as in pvsfread.

The locking is implemented as follows: the signal at point 4 above,  
composed of the difference between 1st input phases and current output  
and 1st input magnitudes is taken in re, im format. The complex data  
of each bin is added to the two adjacent bins. The comments say this  
result will tend toward the bin with the strongest magnitude (but I  
have to work this out in my head, I am not sure I immediately reach  
the same conclusion, do you?).

He also says that if input and output inter-bin phase relationships  
are in parallel, then this will not change any phases, which makes  
sense, but I have to work this out in my head too.

It looks as if we need to know the inter-bin phase relationships of  
the input and then try to fix the output phases to match these.

Does any of this make sense to you?

Victor









On 30 Jan 2010, at 21:08, Richard Dobson wrote:

> Perhaps what is needed is an opcode such as might be called  
> "pvssfread",
> which specifically reads a soundfile and integrates time-scaling with
> the analysis, with the output being a standard fsig.  Nice if it
> supported multi-channel, i.e. delivered multiple output fsigs. How
> flexible and variable such an opcode could be is perhaps the  
> Interesting
> Question.
>
> Richard Dobson
>
> On 30/01/2010 20:47, Victor Lazzarini wrote:
>> The PD implementation I know of is a fft->lock->scale->ifft, so the
>> phase locking is integrated into the analysis process. But his data  
>> is
>> kept in re-im form, he only transforms it to amp-freq (phase delta)  
>> on
>> the go before he calculates what the output frame has to be.
>> I'ts a bit cumbersome to look at.
>>
>> But for us what this means is that locking seems to be tied up with  
>> the
>> timescaling process, but as the data is not analysed into amp-freq
>> beforehand, it might be hard to implement in the pvs model.
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sorry if this suggestion is non-sense. If there is no time-scaling  
going on then what is needed is the ability to take the phase data out  
of pvsifd and add it to to the f-signal prior to re-synthesis right?  
This should then work for transposing and other arbitrary bin-by-bin  
processes.

On 30 Jan 2010, at 21:09, Victor Lazzarini wrote:

> Well, pvsifd already does that, as it outputs both amp+freq and amp
> +phase. This could be used perhaps.
>
> On 30 Jan 2010, at 20:55, Peiman Khosravi wrote:
>
>> Is it out of the question to add phase data to the amp-freq pairs?
>>
>> Best
>>
>> Peiman
>>
>> On 30 Jan 2010, at 20:47, Victor Lazzarini wrote:
>>
>>> The PD implementation I know of is a fft->lock->scale->ifft, so the
>>> phase locking is integrated into the analysis process. But his data
>>> is
>>> kept in re-im form, he only transforms it to amp-freq (phase delta)
>>> on
>>> the go before he calculates what the output frame has to be.
>>> I'ts  a bit cumbersome to look at.
>>>
>>> But for us what this means is that locking seems to be tied up with
>>> the timescaling process, but as the data is not analysed into amp-
>>> freq
>>> beforehand, it might be hard to implement in the pvs model.
>>>
>>> Victor
>>>
>>>
>>> On 30 Jan 2010, at 19:55, Richard Dobson wrote:
>>>
>>>> I do not see that it would be appropriate (or even possible) for  
>>>> the
>>>> table read/write opcodes, as they are inherently "low-level" raw
>>>> transfers. Phase locking is specifically associated with (in this
>>>> instance) time-scaling, i.e. the presence of some scaling  
>>>> parameter;
>>>> and, as we are speculating, by the time frames are even in amp/ 
>>>> phase
>>>> format, it may be "too late" (or alternatively, "too early"). By  
>>>> the
>>>> time the data is even in amp/phase format, the assumptions about  
>>>> the
>>>> frequency evolution of each bin have been made and acted on.
>>>>
>>>> How is it implemented in PD?
>>>>
>>>>
>>>> Richard Dobson
>>>>
>>>> On 30/01/2010 18:56, Peiman Khosravi wrote:
>>>>> Sorry to come in like this but...
>>>> [tempting notion snipped...]
>>>>>
>>>>> This is an amazing idea. It would be very very nice if phase
>>>>> locking
>>>>> could somehow be integrated in the pvsftw and pvsftr too.
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The Planet: dedicated and managed hosting, cloud storage,  
>>>> colocation
>>>> Stay online with enterprise data centers and the best network in  
>>>> the
>>>> business
>>>> Choose flexible plans and management services without long-term
>>>> contracts
>>>> Personal 24x7 support from experience hosting pros just a phone  
>>>> call
>>>> away.
>>>> http://p.sf.net/sfu/theplanet-com
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term
>>> contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, they are raw. The original signal phases, which will differ from  
the integrated ones (disregarding an offset) only if there is data  
modification. They are meant to provide a amp-freq-phase to cubic  
phase interpolation (additive) resynthesis, but there might be some  
further applications to them.

Victor

On 30 Jan 2010, at 21:22, Richard Dobson wrote:

> On 30/01/2010 21:09, Victor Lazzarini wrote:
>> Well, pvsifd already does that, as it outputs both amp+freq and amp
>> +phase. This could be used perhaps.
>>
>
> I wondered about that; but it seems that for phase-locked time-scaling
> we really do need to be able to get at the FFT data ~before~ even the
> conversion to accumulated phase. I assumed your phase output was
> similarly accumulated, but if it is 'raw', maybe there is scope.
>
> Richard Dobson
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Not a straight addition, though. Freqs are phase deltas, so these are  
summed up to give the current output phase. What we need to do perhaps  
is to find a way of making sure the process preserves inter-bin phases  
relationships, which might be measured from the input phases.

The only way I see this working for timescaling is using pvsbuffer  
(which is of course possible).

Victor


On 30 Jan 2010, at 21:37, Peiman Khosravi wrote:

> Sorry if this suggestion is non-sense. If there is no time-scaling
> going on then what is needed is the ability to take the phase data out
> of pvsifd and add it to to the f-signal prior to re-synthesis right?
> This should then work for transposing and other arbitrary bin-by-bin
> processes.
>
> On 30 Jan 2010, at 21:09, Victor Lazzarini wrote:
>
>> Well, pvsifd already does that, as it outputs both amp+freq and amp
>> +phase. This could be used perhaps.
>>
>> On 30 Jan 2010, at 20:55, Peiman Khosravi wrote:
>>
>>> Is it out of the question to add phase data to the amp-freq pairs?
>>>
>>> Best
>>>
>>> Peiman
>>>
>>> On 30 Jan 2010, at 20:47, Victor Lazzarini wrote:
>>>
>>>> The PD implementation I know of is a fft->lock->scale->ifft, so the
>>>> phase locking is integrated into the analysis process. But his data
>>>> is
>>>> kept in re-im form, he only transforms it to amp-freq (phase delta)
>>>> on
>>>> the go before he calculates what the output frame has to be.
>>>> I'ts  a bit cumbersome to look at.
>>>>
>>>> But for us what this means is that locking seems to be tied up with
>>>> the timescaling process, but as the data is not analysed into amp-
>>>> freq
>>>> beforehand, it might be hard to implement in the pvs model.
>>>>
>>>> Victor
>>>>
>>>>
>>>> On 30 Jan 2010, at 19:55, Richard Dobson wrote:
>>>>
>>>>> I do not see that it would be appropriate (or even possible) for
>>>>> the
>>>>> table read/write opcodes, as they are inherently "low-level" raw
>>>>> transfers. Phase locking is specifically associated with (in this
>>>>> instance) time-scaling, i.e. the presence of some scaling
>>>>> parameter;
>>>>> and, as we are speculating, by the time frames are even in amp/
>>>>> phase
>>>>> format, it may be "too late" (or alternatively, "too early"). By
>>>>> the
>>>>> time the data is even in amp/phase format, the assumptions about
>>>>> the
>>>>> frequency evolution of each bin have been made and acted on.
>>>>>
>>>>> How is it implemented in PD?
>>>>>
>>>>>
>>>>> Richard Dobson
>>>>>
>>>>> On 30/01/2010 18:56, Peiman Khosravi wrote:
>>>>>> Sorry to come in like this but...
>>>>> [tempting notion snipped...]
>>>>>>
>>>>>> This is an amazing idea. It would be very very nice if phase
>>>>>> locking
>>>>>> could somehow be integrated in the pvsftw and pvsftr too.
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> The Planet: dedicated and managed hosting, cloud storage,
>>>>> colocation
>>>>> Stay online with enterprise data centers and the best network in
>>>>> the
>>>>> business
>>>>> Choose flexible plans and management services without long-term
>>>>> contracts
>>>>> Personal 24x7 support from experience hosting pros just a phone
>>>>> call
>>>>> away.
>>>>> http://p.sf.net/sfu/theplanet-com
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The Planet: dedicated and managed hosting, cloud storage,  
>>>> colocation
>>>> Stay online with enterprise data centers and the best network in  
>>>> the
>>>> business
>>>> Choose flexible plans and management services without long-term
>>>> contracts
>>>> Personal 24x7 support from experience hosting pros just a phone  
>>>> call
>>>> away.
>>>> http://p.sf.net/sfu/theplanet-com
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term
>>> contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 30/01/2010 21:34, Victor Lazzarini wrote:
> That is a good idea.
>...
> The locking is implemented as follows: the signal at point 4 above,
> composed of the difference between 1st input phases and current output
> and 1st input magnitudes is taken in re, im format. The complex data of
> each bin is added to the two adjacent bins. The comments say this result
> will tend toward the bin with the strongest magnitude (but I have to
> work this out in my head, I am not sure I immediately reach the same
> conclusion, do you?).
>

Hmm, I should probably take more time to look at that (but can't right 
now); but anything involving addition (even if in the complex plane) 
implies some sort of averaging process, whioch may be less than optimal. 
We must remember that the patented Laroche-Dolson method expressly 
claimed it to be an improvement on the Puckette phase-locking. Maybe 
that is one of the areas. Creative Labs used it to reduce the overlap to 
50%; saved CPU, but (having tried it when I had a CL card) the smearing 
was still much in evidence. I kind of went in the opposite direction 
with the SPV!

> He also says that if input and output inter-bin phase relationships are
> in parallel, then this will not change any phases, which makes sense,
> but I have to work this out in my head too.
>
> It looks as if we need to know the inter-bin phase relationships of the
> input and then try to fix the output phases to match these.
>
> Does any of this make sense to you?
>

That bit does; it is (I think) what I mean by bin bunching. At a peak, 
all the associated bins have almost the same frequency; i.e. the 
difference in Hz between adsjacent bins is very small. Ultimately this 
is limited by the narrow bandwidth of a bin. Higher-freq partials have 
more bins associated with them hence more precision. So that translates 
into almost the same phase difference.  These small differences are a 
case (in the resynthesis) of adding N sinusoids of almost identical 
frequencies but differnet phases; the result is (in theory) the same 
frequency with some different phase. Time-scaling requires to evolve 
that phase "in parallel" over a longer/shorter time. In principle the 
bunching seen in the input needs to be replicated in the output.

This may also relate to some of the SDIF-style additive partial track 
formats where both frequency and phase are written for each frame 
(sounds like your format does much the same); so that the phase value 
says where you should be, however you have progressed the frequency 
itself. Perhaps somehow you have to "correct" the frequency evolution 
between frames (which otherwise is more or less free-wheeling) to arrive 
at the target phase at the target time. Perhaops this measn that some 
bins have to rush along a bit, while other lag. It's like runners racing 
over hurdles. They can do whatever they like between hurdles, but must 
always jump over them together. ??

Can't think about this more deeply, now, teaching myself Objective-C 
(and Cocoa) at the moment!


Richard Dobson


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The reference is Miller's Phase Vocoder patch example in the PD audio  
examples. Your second paragraph makes sense, as the result will then  
be phases in adjacent bins that tend to the largest one. It's clearer  
now, thanks. There will be a clustering around the peaks.

Victor

On 30 Jan 2010, at 21:55, fons@kokkinizita.net wrote:

> Hi Victor,
>
>> Looking at Miller's PD code, it's interesting to see the way it's
>> implemented. I'll summarise:
>
> Would you have a pointer to this ?
>
>> The locking is implemented as follows: the signal at point 4 above,
>> composed of the difference between 1st input phases and current  
>> output
>> and 1st input magnitudes is taken in re, im format. The complex data
>> of each bin is added to the two adjacent bins. The comments say this
>> result will tend toward the bin with the strongest magnitude (but I
>> have to work this out in my head, I am not sure I immediately reach
>> the same conclusion, do you?).
>
> (This may be completely misleading)
>
> Adding to adjacent bins amounts to a convolution in the F-domain,
> which is equivalent to windowing in the T-domain. How this relates
> to the problem at hand is a mystery to me ATM...
>
> If you add two complex numbers, the argument of the sum will
> be close the argument of the largest one if the magnitude
> difference is significant  - just look at it as a sum of
> vectors to see this.
>
> Ciao,
>
> -- 
> FA
>
> O tu, che porte, correndo si ?
> E guerra e morte !
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, I have some experience with this. Without timescaling, you would  
use freqs and phases to do a (cubic) interpolation, which fixes the  
phase difference to nicely fit the target phase. However, with  
timescaling, this becomes more complicated and there is no easy way of  
fitting the interpolation to a target phase (I tried some ideas but no  
success, I still have to study the problem from an algebraic point of  
view). What some systems do is to use the phases only at track birth  
(as in the resyn opcode).

One thing just occurred to me: the phase locking issue would not arise  
in sinusoidal track systems, would it? Given than bins are substituted  
by tracks, there would not be more than one track for a given  
frequency and the phasiness problem disappears. What do you think?


Victor


On 30 Jan 2010, at 22:16, Richard Dobson wrote:

> This may also relate to some of the SDIF-style additive partial track
> formats where both frequency and phase are written for each frame
> (sounds like your format does much the same); so that the phase value
> says where you should be, however you have progressed the frequency
> itself. Perhaps somehow you have to "correct" the frequency evolution
> between frames (which otherwise is more or less free-wheeling) to  
> arrive
> at the target phase at the target time. Perhaops this measn that some
> bins have to rush along a bit, while other lag. It's like runners  
> racing
> over hurdles. They can do whatever they like between hurdles, but must
> always jump over them together. ??


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I suppose the question then is, how close do they get to that maximum 
magnitude bin? (Or perhaps rather, to the true peak of the group, which 
may be somewhere between bins). The reference to windowing in the time 
domain does suggest this describes a form of averaging, as a window such 
as Hann etc is a form of lowpass filter. Except that in this case it is 
not full-blown frequency-domain convolution (such as is used in the 
SPV), but something local to each peak.

And there is still the question of peaks that exceed the bandwidth of 
the bins (in the hopping pvoc) so that bins which "should" be close 
together are actually relatively widely separated (determined by the 
overlap) - the essence of the drum smearing problem. Those more distant 
bins presumably also need to be phase-locked, while staying where they 
are (relatively). My related asssumption is that for the low 
frequencies, all the bins from DC up to the end of the first peak need 
to be considered as one group and phase-locked, in the absence of any 
information to determine otherwise.  When we consider that in a typical 
pvoc frame the first three bins might span DC to 86Hz; quite a lot of 
drum activity (and organ pedals) may be represented by those three bins, 
which no amount of phase locking can preserve.



Richard Dobson


On 30/01/2010 22:25, Victor Lazzarini wrote:
> The reference is Miller's Phase Vocoder patch example in the PD audio
> examples. Your second paragraph makes sense, as the result will then
> be phases in adjacent bins that tend to the largest one. It's clearer
> now, thanks. There will be a clustering around the peaks.
>
> Victor
>
> On 30 Jan 2010, at 21:55, fons@kokkinizita.net wrote:
>
>> Hi Victor,
>>
>>> Looking at Miller's PD code, it's interesting to see the way it's
>>> implemented. I'll summarise:
>>
>> Would you have a pointer to this ?
>>
>>> The locking is implemented as follows: the signal at point 4 above,
>>> composed of the difference between 1st input phases and current
>>> output
>>> and 1st input magnitudes is taken in re, im format. The complex data
>>> of each bin is added to the two adjacent bins. The comments say this
>>> result will tend toward the bin with the strongest magnitude (but I
>>> have to work this out in my head, I am not sure I immediately reach
>>> the same conclusion, do you?).
>>
>> (This may be completely misleading)
>>
>> Adding to adjacent bins amounts to a convolution in the F-domain,
>> which is equivalent to windowing in the T-domain. How this relates
>> to the problem at hand is a mystery to me ATM...
>>
>> If you add two complex numbers, the argument of the sum will
>> be close the argument of the largest one if the magnitude
>> difference is significant  - just look at it as a sum of
>> vectors to see this.
>>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For pitched tones, it can work very well indeed. I was impressed how 
SNDAN (implementing classic MQ analysis) could handle complex sources 
with a lot of noise (including speech), with a host of little tracks 
that emerged and died in rapid succession. Not infallible though; the 
problems with this are what led to the modern techniques of 
sines+noise/residual, track reassignment, etc, as partial tracking 
famously has a problem with transient sounds of indeterminate pitch. It 
has in this context to be remembered that where people casually ask for 
time-scaling, they really want ~tempo~ scaling, with drum hits 
essentially unchanged even for large changes. I can't see any form of 
phase locking or plain partial tracking achieving that. And we want all 
this in real-time too, with minimum latency. I haven't spent anything 
like enough time with those more modern tools to make any sort of 
informed comparison.

Richard Dobson


On 30/01/2010 22:39, Victor Lazzarini wrote:
..
>
> One thing just occurred to me: the phase locking issue would not arise
> in sinusoidal track systems, would it? Given than bins are substituted
> by tracks, there would not be more than one track for a given frequency
> and the phasiness problem disappears. What do you think?
>
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

My idea for this is that a transient/attack detection could control  
timescaling, so that at those moments, there is an interruption of any  
timescaling effect, This can be immediately compensated by a slightly  
larger amount of timescaling to deliver the average tempo scaling  
desired. This could be implemented in a version of pvsfread that took  
a tempo scaling parameter.

I guess a simple and fast transient/attack detection could be  
implemented by comparing power or amplitude spectra at adjacent  
frames. If a jump occurs, we have an attack worth preserving.

Some artifacts due to the speed-up-slow-down process might arise in  
cases where the amount of tempo scaling is substantial.

Victor

On 30 Jan 2010, at 23:16, Richard Dobson wrote:

> For pitched tones, it can work very well indeed. I was impressed how
> SNDAN (implementing classic MQ analysis) could handle complex sources
> with a lot of noise (including speech), with a host of little tracks
> that emerged and died in rapid succession. Not infallible though; the
> problems with this are what led to the modern techniques of
> sines+noise/residual, track reassignment, etc, as partial tracking
> famously has a problem with transient sounds of indeterminate pitch.  
> It
> has in this context to be remembered that where people casually ask  
> for
> time-scaling, they really want ~tempo~ scaling, with drum hits
> essentially unchanged even for large changes. I can't see any form of
> phase locking or plain partial tracking achieving that. And we want  
> all
> this in real-time too, with minimum latency. I haven't spent anything
> like enough time with those more modern tools to make any sort of
> informed comparison.
>
> Richard Dobson
>
>
> On 30/01/2010 22:39, Victor Lazzarini wrote:
> ..
>>
>> One thing just occurred to me: the phase locking issue would not  
>> arise
>> in sinusoidal track systems, would it? Given than bins are  
>> substituted
>> by tracks, there would not be more than one track for a given  
>> frequency
>> and the phasiness problem disappears. What do you think?
>>
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have been thinking of this overnight and I reached a few conclusions  
(which might be wrong...). We might be able to apply phase locking to  
a pv stream. Here is my proposal:

1. Miller's phase locking locks the phase deltas according to the  
latest magnitudes.
2. His 3-bin summing is a 3-bin weighted average of phase deltas.

For us, this can work as follows. We have the latest magnitudes and we  
have the
phase deltas in Hz (frequencies), so:

1. On the current frame, use the current magnitudes to alter the  
frequencies.
2. Do a weighted average of frequencies, using the magnitudes as the  
weight

e.g.

freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n+1])
freq[n] /= (mag[n-1] + mag[n] + mag[n+1]


Do this as an opcode, which can be inserted anywhere in the signal  
chain to provide phase coherence where it's needed.

It seems simple enough, but then again Miller's solution does not seem  
too involved. It does not seem to depend on phases but on phase  
deltas, so we gain nothing by preserving the original phase.

Victor






On 30 Jan 2010, at 23:02, Richard Dobson wrote:

> I suppose the question then is, how close do they get to that maximum
> magnitude bin? (Or perhaps rather, to the true peak of the group,  
> which
> may be somewhere between bins). The reference to windowing in the time
> domain does suggest this describes a form of averaging, as a window  
> such
> as Hann etc is a form of lowpass filter. Except that in this case it  
> is
> not full-blown frequency-domain convolution (such as is used in the
> SPV), but something local to each peak.
>
> And there is still the question of peaks that exceed the bandwidth of
> the bins (in the hopping pvoc) so that bins which "should" be close
> together are actually relatively widely separated (determined by the
> overlap) - the essence of the drum smearing problem. Those more  
> distant
> bins presumably also need to be phase-locked, while staying where they
> are (relatively). My related asssumption is that for the low
> frequencies, all the bins from DC up to the end of the first peak need
> to be considered as one group and phase-locked, in the absence of any
> information to determine otherwise.  When we consider that in a  
> typical
> pvoc frame the first three bins might span DC to 86Hz; quite a lot of
> drum activity (and organ pedals) may be represented by those three  
> bins,
> which no amount of phase locking can preserve.
>
>
>
> Richard Dobson
>
>
> On 30/01/2010 22:25, Victor Lazzarini wrote:
>> The reference is Miller's Phase Vocoder patch example in the PD audio
>> examples. Your second paragraph makes sense, as the result will then
>> be phases in adjacent bins that tend to the largest one. It's clearer
>> now, thanks. There will be a clustering around the peaks.
>>
>> Victor
>>
>> On 30 Jan 2010, at 21:55, fons@kokkinizita.net wrote:
>>
>>> Hi Victor,
>>>
>>>> Looking at Miller's PD code, it's interesting to see the way it's
>>>> implemented. I'll summarise:
>>>
>>> Would you have a pointer to this ?
>>>
>>>> The locking is implemented as follows: the signal at point 4 above,
>>>> composed of the difference between 1st input phases and current
>>>> output
>>>> and 1st input magnitudes is taken in re, im format. The complex  
>>>> data
>>>> of each bin is added to the two adjacent bins. The comments say  
>>>> this
>>>> result will tend toward the bin with the strongest magnitude (but I
>>>> have to work this out in my head, I am not sure I immediately reach
>>>> the same conclusion, do you?).
>>>
>>> (This may be completely misleading)
>>>
>>> Adding to adjacent bins amounts to a convolution in the F-domain,
>>> which is equivalent to windowing in the T-domain. How this relates
>>> to the problem at hand is a mystery to me ATM...
>>>
>>> If you add two complex numbers, the argument of the sum will
>>> be close the argument of the largest one if the magnitude
>>> difference is significant  - just look at it as a sum of
>>> vectors to see this.
>>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, I am all for simple solutions! I suppose the proof will be in the 
listening. I am slightly sceptical as this does not incorporate anything 
relating to a time scaling factor; what effect would it have on a 
standard fsig where no time-scaling has been involved? My intuition is 
that this is a sort of general spectral sharpening process (so to speak, 
increasing contrast) that might well act in some remedial way where some 
phasing has developed, but is a fixed process (no user-variable 
parameters in the formulation you give). For use with time-scaling, for 
de-smearing, I would expect at least some parameter or weighting related 
to the time-scale factor (which is where frame[n-1] and even frame[n-2] 
might come into it), and possibly a slope, so that the effect can be 
made  frequency-sensitive. i.e. more "focus" at LF where we have few 
bins to play with, to maybe none at all at HF where we have an excess of 
bins. Perhaps the weighting needs to be applied not only over freq[n+-1] 
but over all bins within a peak, with special care over the first block 
from DC to the first trough.

This could be done as a user-defined opcode via pvsftr/w as an immediate 
test, before rolling into a full opcode.


Richard Dobson

On 31/01/2010 09:28, Victor Lazzarini wrote:
> I have been thinking of this overnight and I reached a few conclusions
> (which might be wrong...). We might be able to apply phase locking to a
> pv stream. Here is my proposal:
>
> 1. Miller's phase locking locks the phase deltas according to the latest
> magnitudes.
> 2. His 3-bin summing is a 3-bin weighted average of phase deltas.
>
> For us, this can work as follows. We have the latest magnitudes and we
> have the
> phase deltas in Hz (frequencies), so:
>
> 1. On the current frame, use the current magnitudes to alter the
> frequencies.
> 2. Do a weighted average of frequencies, using the magnitudes as the weight
>
> e.g.
>
> freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n+1])
> freq[n] /= (mag[n-1] + mag[n] + mag[n+1]
>
>
> Do this as an opcode, which can be inserted anywhere in the signal chain
> to provide phase coherence where it's needed.
>
> It seems simple enough, but then again Miller's solution does not seem
> too involved. It does not seem to depend on phases but on phase deltas,
> so we gain nothing by preserving the original phase.
>
> Victor
>


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is close to how it works in Audiosculpt I believe.



On 30 Jan 2010, at 23:27, Victor Lazzarini wrote:

> My idea for this is that a transient/attack detection could control
> timescaling, so that at those moments, there is an interruption of any
> timescaling effect, This can be immediately compensated by a slightly
> larger amount of timescaling to deliver the average tempo scaling
> desired. This could be implemented in a version of pvsfread that took
> a tempo scaling parameter.
>
> I guess a simple and fast transient/attack detection could be
> implemented by comparing power or amplitude spectra at adjacent
> frames. If a jump occurs, we have an attack worth preserving.
>
> Some artifacts due to the speed-up-slow-down process might arise in
> cases where the amount of tempo scaling is substantial.
>
> Victor
>
> On 30 Jan 2010, at 23:16, Richard Dobson wrote:
>
>> For pitched tones, it can work very well indeed. I was impressed how
>> SNDAN (implementing classic MQ analysis) could handle complex sources
>> with a lot of noise (including speech), with a host of little tracks
>> that emerged and died in rapid succession. Not infallible though; the
>> problems with this are what led to the modern techniques of
>> sines+noise/residual, track reassignment, etc, as partial tracking
>> famously has a problem with transient sounds of indeterminate pitch.
>> It
>> has in this context to be remembered that where people casually ask
>> for
>> time-scaling, they really want ~tempo~ scaling, with drum hits
>> essentially unchanged even for large changes. I can't see any form of
>> phase locking or plain partial tracking achieving that. And we want
>> all
>> this in real-time too, with minimum latency. I haven't spent anything
>> like enough time with those more modern tools to make any sort of
>> informed comparison.
>>
>> Richard Dobson
>>
>>
>> On 30/01/2010 22:39, Victor Lazzarini wrote:
>> ..
>>>
>>> One thing just occurred to me: the phase locking issue would not
>>> arise
>>> in sinusoidal track systems, would it? Given than bins are
>>> substituted
>>> by tracks, there would not be more than one track for a given
>>> frequency
>>> and the phasiness problem disappears. What do you think?
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

As a complete DSP novice but a full-time user of pvs opcodes I would  
suggest that transient preservation for time-scaling should be  
implemented in addition to general phase-locking of pv stream. This  
way there should at least theoretically be an improvement to pitch  
shifting and other arbitrary algorithms.

Thanks

Peiman

On 31 Jan 2010, at 10:46, Richard Dobson wrote:

> Well, I am all for simple solutions! I suppose the proof will be in  
> the
> listening. I am slightly sceptical as this does not incorporate  
> anything
> relating to a time scaling factor; what effect would it have on a
> standard fsig where no time-scaling has been involved? My intuition is
> that this is a sort of general spectral sharpening process (so to  
> speak,
> increasing contrast) that might well act in some remedial way where  
> some
> phasing has developed, but is a fixed process (no user-variable
> parameters in the formulation you give). For use with time-scaling,  
> for
> de-smearing, I would expect at least some parameter or weighting  
> related
> to the time-scale factor (which is where frame[n-1] and even  
> frame[n-2]
> might come into it), and possibly a slope, so that the effect can be
> made  frequency-sensitive. i.e. more "focus" at LF where we have few
> bins to play with, to maybe none at all at HF where we have an  
> excess of
> bins. Perhaps the weighting needs to be applied not only over freq[n 
> +-1]
> but over all bins within a peak, with special care over the first  
> block
> from DC to the first trough.
>
> This could be done as a user-defined opcode via pvsftr/w as an  
> immediate
> test, before rolling into a full opcode.
>
>
> Richard Dobson
>
> On 31/01/2010 09:28, Victor Lazzarini wrote:
>> I have been thinking of this overnight and I reached a few  
>> conclusions
>> (which might be wrong...). We might be able to apply phase locking  
>> to a
>> pv stream. Here is my proposal:
>>
>> 1. Miller's phase locking locks the phase deltas according to the  
>> latest
>> magnitudes.
>> 2. His 3-bin summing is a 3-bin weighted average of phase deltas.
>>
>> For us, this can work as follows. We have the latest magnitudes and  
>> we
>> have the
>> phase deltas in Hz (frequencies), so:
>>
>> 1. On the current frame, use the current magnitudes to alter the
>> frequencies.
>> 2. Do a weighted average of frequencies, using the magnitudes as  
>> the weight
>>
>> e.g.
>>
>> freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n+1])
>> freq[n] /= (mag[n-1] + mag[n] + mag[n+1]
>>
>>
>> Do this as an opcode, which can be inserted anywhere in the signal  
>> chain
>> to provide phase coherence where it's needed.
>>
>> It seems simple enough, but then again Miller's solution does not  
>> seem
>> too involved. It does not seem to depend on phases but on phase  
>> deltas,
>> so we gain nothing by preserving the original phase.
>>
>> Victor
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

You are right that this does not incorporate anything to do with  
timescaling. However, it's the way Miller's locking works, it does not  
care what timescaling or if timescaling is at all involved.
That's why I thought it might work for us.

Perhaps what you describe is more related to transient smearing?  
Anyway, I need to read a little more to see the other solutions.

Victor


On 31 Jan 2010, at 10:46, Richard Dobson wrote:

> Well, I am all for simple solutions! I suppose the proof will be in  
> the
> listening. I am slightly sceptical as this does not incorporate  
> anything
> relating to a time scaling factor; what effect would it have on a
> standard fsig where no time-scaling has been involved? My intuition is
> that this is a sort of general spectral sharpening process (so to  
> speak,
> increasing contrast) that might well act in some remedial way where  
> some
> phasing has developed, but is a fixed process (no user-variable
> parameters in the formulation you give). For use with time-scaling,  
> for
> de-smearing, I would expect at least some parameter or weighting  
> related
> to the time-scale factor (which is where frame[n-1] and even  
> frame[n-2]
> might come into it), and possibly a slope, so that the effect can be
> made  frequency-sensitive. i.e. more "focus" at LF where we have few
> bins to play with, to maybe none at all at HF where we have an  
> excess of
> bins. Perhaps the weighting needs to be applied not only over freq[n 
> +-1]
> but over all bins within a peak, with special care over the first  
> block
> from DC to the first trough.
>
> This could be done as a user-defined opcode via pvsftr/w as an  
> immediate
> test, before rolling into a full opcode.
>
>
> Richard Dobson
>
> On 31/01/2010 09:28, Victor Lazzarini wrote:
>> I have been thinking of this overnight and I reached a few  
>> conclusions
>> (which might be wrong...). We might be able to apply phase locking  
>> to a
>> pv stream. Here is my proposal:
>>
>> 1. Miller's phase locking locks the phase deltas according to the  
>> latest
>> magnitudes.
>> 2. His 3-bin summing is a 3-bin weighted average of phase deltas.
>>
>> For us, this can work as follows. We have the latest magnitudes and  
>> we
>> have the
>> phase deltas in Hz (frequencies), so:
>>
>> 1. On the current frame, use the current magnitudes to alter the
>> frequencies.
>> 2. Do a weighted average of frequencies, using the magnitudes as  
>> the weight
>>
>> e.g.
>>
>> freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n+1])
>> freq[n] /= (mag[n-1] + mag[n] + mag[n+1]
>>
>>
>> Do this as an opcode, which can be inserted anywhere in the signal  
>> chain
>> to provide phase coherence where it's needed.
>>
>> It seems simple enough, but then again Miller's solution does not  
>> seem
>> too involved. It does not seem to depend on phases but on phase  
>> deltas,
>> so we gain nothing by preserving the original phase.
>>
>> Victor
>>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, Iyou are right. We'll tackle one at a time, though. The 'sync  
channels'  box in the audiosculpt windows I think are to do with  
locking, or are they not?

Victor


On 31 Jan 2010, at 11:34, Peiman Khosravi wrote:

> As a complete DSP novice but a full-time user of pvs opcodes I would
> suggest that transient preservation for time-scaling should be
> implemented in addition to general phase-locking of pv stream. This
> way there should at least theoretically be an improvement to pitch
> shifting and other arbitrary algorithms.
>
> Thanks
>
> Peiman
>
> On 31 Jan 2010, at 10:46, Richard Dobson wrote:
>
>> Well, I am all for simple solutions! I suppose the proof will be in
>> the
>> listening. I am slightly sceptical as this does not incorporate
>> anything
>> relating to a time scaling factor; what effect would it have on a
>> standard fsig where no time-scaling has been involved? My intuition  
>> is
>> that this is a sort of general spectral sharpening process (so to
>> speak,
>> increasing contrast) that might well act in some remedial way where
>> some
>> phasing has developed, but is a fixed process (no user-variable
>> parameters in the formulation you give). For use with time-scaling,
>> for
>> de-smearing, I would expect at least some parameter or weighting
>> related
>> to the time-scale factor (which is where frame[n-1] and even
>> frame[n-2]
>> might come into it), and possibly a slope, so that the effect can be
>> made  frequency-sensitive. i.e. more "focus" at LF where we have few
>> bins to play with, to maybe none at all at HF where we have an
>> excess of
>> bins. Perhaps the weighting needs to be applied not only over freq[n
>> +-1]
>> but over all bins within a peak, with special care over the first
>> block
>> from DC to the first trough.
>>
>> This could be done as a user-defined opcode via pvsftr/w as an
>> immediate
>> test, before rolling into a full opcode.
>>
>>
>> Richard Dobson
>>
>> On 31/01/2010 09:28, Victor Lazzarini wrote:
>>> I have been thinking of this overnight and I reached a few
>>> conclusions
>>> (which might be wrong...). We might be able to apply phase locking
>>> to a
>>> pv stream. Here is my proposal:
>>>
>>> 1. Miller's phase locking locks the phase deltas according to the
>>> latest
>>> magnitudes.
>>> 2. His 3-bin summing is a 3-bin weighted average of phase deltas.
>>>
>>> For us, this can work as follows. We have the latest magnitudes and
>>> we
>>> have the
>>> phase deltas in Hz (frequencies), so:
>>>
>>> 1. On the current frame, use the current magnitudes to alter the
>>> frequencies.
>>> 2. Do a weighted average of frequencies, using the magnitudes as
>>> the weight
>>>
>>> e.g.
>>>
>>> freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n+1])
>>> freq[n] /= (mag[n-1] + mag[n] + mag[n+1]
>>>
>>>
>>> Do this as an opcode, which can be inserted anywhere in the signal
>>> chain
>>> to provide phase coherence where it's needed.
>>>
>>> It seems simple enough, but then again Miller's solution does not
>>> seem
>>> too involved. It does not seem to depend on phases but on phase
>>> deltas,
>>> so we gain nothing by preserving the original phase.
>>>
>>> Victor
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think the "channel" refers to the number of channels in the input  
sound-file and is probably related to some sort of temporal syncing of  
the transients found in the different channels (e.g. left/right). I've  
never tried that option but will give it a go to see what the result  
is. As far as I know audiosculpt doesn't have phase-locking.

Best

Peiman

On 31 Jan 2010, at 16:02, Victor Lazzarini wrote:

> yes, Iyou are right. We'll tackle one at a time, though. The 'sync
> channels'  box in the audiosculpt windows I think are to do with
> locking, or are they not?
>
> Victor
>
>
> On 31 Jan 2010, at 11:34, Peiman Khosravi wrote:
>
>> As a complete DSP novice but a full-time user of pvs opcodes I would
>> suggest that transient preservation for time-scaling should be
>> implemented in addition to general phase-locking of pv stream. This
>> way there should at least theoretically be an improvement to pitch
>> shifting and other arbitrary algorithms.
>>
>> Thanks
>>
>> Peiman
>>
>> On 31 Jan 2010, at 10:46, Richard Dobson wrote:
>>
>>> Well, I am all for simple solutions! I suppose the proof will be in
>>> the
>>> listening. I am slightly sceptical as this does not incorporate
>>> anything
>>> relating to a time scaling factor; what effect would it have on a
>>> standard fsig where no time-scaling has been involved? My intuition
>>> is
>>> that this is a sort of general spectral sharpening process (so to
>>> speak,
>>> increasing contrast) that might well act in some remedial way where
>>> some
>>> phasing has developed, but is a fixed process (no user-variable
>>> parameters in the formulation you give). For use with time-scaling,
>>> for
>>> de-smearing, I would expect at least some parameter or weighting
>>> related
>>> to the time-scale factor (which is where frame[n-1] and even
>>> frame[n-2]
>>> might come into it), and possibly a slope, so that the effect can be
>>> made  frequency-sensitive. i.e. more "focus" at LF where we have few
>>> bins to play with, to maybe none at all at HF where we have an
>>> excess of
>>> bins. Perhaps the weighting needs to be applied not only over freq[n
>>> +-1]
>>> but over all bins within a peak, with special care over the first
>>> block
>>> from DC to the first trough.
>>>
>>> This could be done as a user-defined opcode via pvsftr/w as an
>>> immediate
>>> test, before rolling into a full opcode.
>>>
>>>
>>> Richard Dobson
>>>
>>> On 31/01/2010 09:28, Victor Lazzarini wrote:
>>>> I have been thinking of this overnight and I reached a few
>>>> conclusions
>>>> (which might be wrong...). We might be able to apply phase locking
>>>> to a
>>>> pv stream. Here is my proposal:
>>>>
>>>> 1. Miller's phase locking locks the phase deltas according to the
>>>> latest
>>>> magnitudes.
>>>> 2. His 3-bin summing is a 3-bin weighted average of phase deltas.
>>>>
>>>> For us, this can work as follows. We have the latest magnitudes and
>>>> we
>>>> have the
>>>> phase deltas in Hz (frequencies), so:
>>>>
>>>> 1. On the current frame, use the current magnitudes to alter the
>>>> frequencies.
>>>> 2. Do a weighted average of frequencies, using the magnitudes as
>>>> the weight
>>>>
>>>> e.g.
>>>>
>>>> freq[n] = (freq[n-1]*amp[n-1] + freq[n]*amp[n] + freq[n+1]*amp[n 
>>>> +1])
>>>> freq[n] /= (mag[n-1] + mag[n] + mag[n+1]
>>>>
>>>>
>>>> Do this as an opcode, which can be inserted anywhere in the signal
>>>> chain
>>>> to provide phase coherence where it's needed.
>>>>
>>>> It seems simple enough, but then again Miller's solution does not
>>>> seem
>>>> too involved. It does not seem to depend on phases but on phase
>>>> deltas,
>>>> so we gain nothing by preserving the original phase.
>>>>
>>>> Victor
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The Planet: dedicated and managed hosting, cloud storage, colocation
>>> Stay online with enterprise data centers and the best network in the
>>> business
>>> Choose flexible plans and management services without long-term
>>> contracts
>>> Personal 24x7 support from experience hosting pros just a phone call
>>> away.
>>> http://p.sf.net/sfu/theplanet-com
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Planet: dedicated and managed hosting, cloud storage, colocation
>> Stay online with enterprise data centers and the best network in the
>> business
>> Choose flexible plans and management services without long-term
>> contracts
>> Personal 24x7 support from experience hosting pros just a phone call
>> away.
>> http://p.sf.net/sfu/theplanet-com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 31/01/2010 16:00, Victor Lazzarini wrote:
> You are right that this does not incorporate anything to do with
> timescaling. However, it's the way Miller's locking works, it does not
> care what timescaling or if timescaling is at all involved.
> That's why I thought it might work for us.
>
> Perhaps what you describe is more related to transient smearing? Anyway,
> I need to read a little more to see the other solutions.
>

A propos of which, there is this CiteSeer entry:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.8498

Has a comprehensive list of references, including the Dolson-Laroche 
paper. The paper this page features is no longer at the cited url (the 
usual citeseer problem), but can be found here:

http://iem.at/projekte/dsp/hammer/view

With the full document title and author name, one can usually find it 
via Google if it is available at all.


Richard Dobson


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 31/01/2010 16:00, Victor Lazzarini wrote:
> You are right that this does not incorporate anything to do with
> timescaling. However, it's the way Miller's locking works, it does not
> care what timescaling or if timescaling is at all involved.
> That's why I thought it might work for us.
>
> Perhaps what you describe is more related to transient smearing? Anyway,
> I need to read a little more to see the other solutions.
>

It's also worth noting that, as I understand them (and as summarised in 
Hammer's paper)  the described solutions concern the method of 
time-scaling by changing the hop size. In pvsfread etc timescaling is 
achieved by (simple) frame interpolation; which may lead to the need to 
modify those hop-based solutions. It seems reasonable to suspect that 
the linear frame interpolation itself contributes to the smearing, and 
some higher-order scheme may well be indicated.

Richar Dobson


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Just an update on this

1. Phase locking:
I figured out we would need a current phase measurement after all. I  
have worked out
what Miller's locking is:

Ph_out  = Ph_in(n) +  lock(Ph_out - Ph_in(n-1))

where Ph_out is the current output phase, Ph_in(n) is the current  
input frame and
Ph_in(n-1) is a frame 1/4-length behind it.

What we have stored in our system is (disregarding the units this is  
in):

freq = Ph_in(n) - Ph_in(n-1)

We can work out then something like this

Ph_out =  freq - Ph_in(n-1)  + lock(Ph_out - Ph_in(n-1))

The trouble is that we still need a measurement for Ph_in(n-1). I had  
hoped I could recuperate the original phase by integration and then  
use it in one the expressions above, but I have not yet found a  
solution.

2. Transient detection: I made some tests to see if a simple tracking  
of frame magnitude changes would detect attacks and it does seem to do  
it, we have to adjust thresholds to fine tune it, My question is  
whether a frame-by-frame measurement suffices or whether it should  
involve a longer time-span (by comparing more than one frame ahead  
with the current one).


Victor









On 31 Jan 2010, at 16:46, Richard Dobson wrote:

> On 31/01/2010 16:00, Victor Lazzarini wrote:
>> You are right that this does not incorporate anything to do with
>> timescaling. However, it's the way Miller's locking works, it does  
>> not
>> care what timescaling or if timescaling is at all involved.
>> That's why I thought it might work for us.
>>
>> Perhaps what you describe is more related to transient smearing?  
>> Anyway,
>> I need to read a little more to see the other solutions.
>>
>
> It's also worth noting that, as I understand them (and as summarised  
> in
> Hammer's paper)  the described solutions concern the method of
> time-scaling by changing the hop size. In pvsfread etc timescaling is
> achieved by (simple) frame interpolation; which may lead to the need  
> to
> modify those hop-based solutions. It seems reasonable to suspect that
> the linear frame interpolation itself contributes to the smearing, and
> some higher-order scheme may well be indicated.
>
> Richar Dobson
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net