pvscale

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

pvscale

Tim Mortimer
nothing like replying to a 10 year old thread ... thanks Nabble ...

i make reference to the thread on the Dev list from 2007 ...

http://csound.1045644.n5.nabble.com/pvscale-td1131644.html

this is kind of an issue for me, so, while i'm poking around here again, i thought i'd bring it up. 10 years of water under the bridge & all ...

most of what i do FFT wise involves creating a mask (usually derived from some sort of manipulation / banding of GEN43 or using a 'sieve' to extract bins around particular harmonic ratios ...)

applying the mask using pvsmaska, & then pvscale ...

i often get 'dropouts' across various transpositions, & i assume that the discussion linked to above is at the heart of the problem ... given i am working with an attenuated spectrum anyway, 1 or 2 dropouts in the remaining signal creates at times some fairly glaring ommissions ...

i tend not to go for the partial tracking type opcodes, as usually i am applying slow moving amplitude variation to my 'grouped bins', by writing to a table & applying the modulations at k rate to the fsig ...

i'm not aware of any alternate to table manipulation of fsig that would allow me to replicate this approach - independently modulating amplitudes of individual partials within the total complex resynthesis. Am i wrong in this regard?

the only alternate strategy i have is using SDIF derived data in text file to drive sinewaves (usually 16 ...). This gives more accuracy under transposition, & allows a-rate enveloping effects ('spectral plinky plonk'), but of course pretty much throws the baby out with the bath water in terms of source sound recognition / phase alignment etc ...

if this discussion dies a death then so be it, but ... 1) am i missing anything existing in terms of approach to this 2) is it now worth exploring (2017 ...) an improved opcode implementation of pvscale, either with an algorithm adjusting optional extra parameter, or in the form of a pvscale2 allowing for at least rounding of bin reassignment ...






Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Jeanette C.
Hi Tim,
Aug 23 2017, Tim Mortimer has written:
...
> i'm not aware of any alternate to table manipulation of fsig that would
> allow me to replicate this approach - independently modulating amplitudes of
> individual partials within the total complex resynthesis. Am i wrong in this
> regard?
...
There is pvsftw and pvsftr, which will write bin frequencies and
amplitudes to two function tables and read them back again for
completely free manipulation. But beyond pvscale/pvshift I don't know of
any newer algorithm to pitchshift fsigs, while still being able to
manipulate them in the way you want.

HTH..
Best wishes,

Jeanette

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

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

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Tim Mortimer
>>> pvsftw and pvsftr

I have seen a few mentions of these digging around on the recent posts ...

i have a vague recollection that i read somewhere ... that reconstituting an fsig from table freq / amp data in this way isn't necessarily based upon placing the 'right' frequency & amplitude data in the 'right' bins?

i.e, you can write 500 hz in bin 99, 700 hz in bin ... 37, set the amplitudes accordingly & resynth the sound? i.e. bin index doesn't have to 'match' the FFT analysis range in terms of allocation

this might work as i can reconstitute my 'grouped partials' this way, & hopefully recover what pvscale is losing ...

but then it does beg the Q, if this is possible, why does pvscale just not do this in the first place?

so maybe it's not that easy ...

i will try that out though, especially now that realtime is a lot lower on my list of priorities ...

Thanks for your response ...
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Steven Yi
Hi Tim,

Just another option, you might look at using rfft/rifft with mags/phs
(see the example at:

http://csound.github.io/docs/manual/mags.html

)

It's a bit more low-level but gives you all the flexibility to do with
the analysis data as you wish.

As for writing frequencies, from what I understand, the freq value for
an AMP_FREQ fsig gets used to calculate the phase before converting
back to rect  then on to ifft.  So what bin you write to should
matter.

steven


On Wed, Aug 23, 2017 at 6:07 PM, Tim Mortimer <[hidden email]> wrote:

>>>> pvsftw and pvsftr
>
> I have seen a few mentions of these digging around on the recent posts ...
>
> i have a vague recollection that i read somewhere ... that reconstituting an
> fsig from table freq / amp data in this way isn't necessarily based upon
> placing the 'right' frequency & amplitude data in the 'right' bins?
>
> i.e, you can write 500 hz in bin 99, 700 hz in bin ... 37, set the
> amplitudes accordingly & resynth the sound? i.e. bin index doesn't have to
> 'match' the FFT analysis range in terms of allocation
>
> this might work as i can reconstitute my 'grouped partials' this way, &
> hopefully recover what pvscale is losing ...
>
> but then it does beg the Q, if this is possible, why does pvscale just not
> do this in the first place?
>
> so maybe it's not that easy ...
>
> i will try that out though, especially now that realtime is a lot lower on
> my list of priorities ...
>
> Thanks for your response ...
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/pvscale-tp5757615p5757632.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> [hidden email]
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Tim Mortimer
cheers Steven ... i discovered that issue myself this afternoon ... trying to simply shove frequencies back into their bins of origin but with rescaled frequency values.

my intuition told me that the failure of that naive experiment was down to phase not being reevaluated, so i'm glad my hunch was more or less correct ...

i'll give mags a look ... the good news at least is after 2 days of frustration it looks like i have a csoundQT environment back again & operational ... time / gods willing ...

(2 minutes later ...)

Ok, there's a bit more low level guff to bend my head around, but i see the potential application there most definitely ... i don't think i'll try that in the next few days / weeks, but i'll put in on my task list now for evaluation when i'm feeling a bit more patient & settled again ... i.e i have a list of design objectives, & i'm writing 'mags' down on it ...

Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Tim Mortimer
I link to this response in the interests of thread continuity ... thanks Nathan.

http://csound.1045644.n5.nabble.com/Csnd-PVS-fft-latency-question-tp5757589p5757678.html

I also just discovered pvread in the manual, perhaps overlooked (by me at least) previously due to it's unassuming simplicity.... could be fairly labour intensive, but if the aim is to focus on a manageable number of individual partials & retune them without associated dropouts due to bin reassignment, it could provide something of a brute - force solution ...

Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Nathan Holmes
You're welcome. :)

pvread is another interesting option, true, one that I tend to forget about because it requires a pre-analyzed file. But I also think it should be equivalent to reading the results of just one bin through a table with pvsftw, shouldn't it? That said, it may be easier to use pvread, since you don't need to deal with setting up tables or the "wait until it's okay to read" thing.

Another pre-analyzed solution (but this time based on partial tracking) is the ATS opcodes. You can specify number of partials during resynthesis (and a "starting partial" offset), and beyond that there's ATSpartialtap which returns k-rate amp and freq values for a single partial track. The downside is that the ATSA analysis utility tends to group partials even less coherently than the "partials" opcode, in my experience so far (although maybe I just haven't figured out how to set its parameters properly).

So if you're trying to isolate coherent harmonics of the fundamental, sadly neither "partials" nor ATSA's analysis seem up to the job. (Except perhaps for very clean, stationary, highly periodic sounds.) That's my current pipe dream, by the way: a tool that magically extracts harmonics from moving signals like speech.


You know, if your main goal at the moment is pitch-shifting without dropouts, you could try doing your masking + manipulation with a standard PV fsig, then pvsynth-ing to an a-rate signal, then re-analyzing as a TRACKS PV stream, and finally resynthesizing through resyn (because it has a pitch-scaling parameter). Since resyn works through additive synthesis, it may help avoid the drop-out problem.

But that's getting a bit circuitous, and I imagine it wouldn't be practical if you wanted to do further PV manipulation after the pitch-shift, 'cause then you'd have to reanalyze to a PV-stream again. (Although the low-level FFT/IFFT approach suffers from that same impracticality.)

On Sat, Aug 26, 2017 at 12:59 PM, Tim Mortimer <[hidden email]> wrote:
I link to this response in the interests of thread continuity ... thanks
Nathan.

http://csound.1045644.n5.nabble.com/Csnd-PVS-fft-latency-question-tp5757589p5757678.html

I also just discovered pvread in the manual, perhaps overlooked (by me at
least) previously due to it's unassuming simplicity.... could be fairly
labour intensive, but if the aim is to focus on a manageable number of
individual partials & retune them without associated dropouts due to bin
reassignment, it could provide something of a brute - force solution ...





--
View this message in context: http://csound.1045644.n5.nabble.com/pvscale-tp5757615p5757688.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here
Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Tim Mortimer
Hey Nathan ... thanks for the further input ...

to be honest, with table read & write of hard freq & amp values now the preferred option (& mags ... that's still probably my next move on the subject ...), i am wondering if i should simply look at adsyn / adsynt2 (which i have used a bit doing a sort of 'poor mans SDIF' based routine, based on DATA derived from SPEAR) ... & possibly even marrying that adsyn partials resynthesis with a fsig based residual ... pretty sure i conducted that experiment previously to some effect ... the 'i can't believe it's not ATS' approach (residual frame-iness aside ...)

My use of pvscale really stems from my very early days with csound ... read the manual, had limited knowledge of the underlying processes, that seemed to nominated itself for the task at hand & i've been bashing away with it on & off ever since ...

 i've been approaching this problem from a different angle in the interim, simply by tightening up my interrogation of GEN43 files in Python & writing some more organised & useful classes, slightly less dumb algorithms ... & sort of 'widening the berth' a bit in terms of 'group' assignment of bins ... (all my processes are offline render based now ... the ability to batch import audio on cue into Reaper & then script additional fades, enveloping etc has been a deal-sealer for me, & i think the element i have been missing, as handling complex polyphony & retriggering in csound was just adding too much complexity to my designs ... i could get them working, but the limits of their extensibility were bounded by my reluctance to really design anything more complex. Rendering one note at a time on the other hand ... 'hold my beer' as they say ... ; )

I could never get ATS noise to playback on my old Win XP machine, so abandoned my experiments ... (that was way back however, when i first started dabbling & had a period of heavy activity on this list ...)

I'd like to investigate the Python Loris classes, but i have no idea how to compile the FFT library dependency it sits upon ... & it's not a priority ...

Which, in the survey of alternatives, brings us to 'pvadd' ... pretty sure i've read that manual entry a few times, thinking 'this looks useful', & then being confronted by (no disrespect intended ..) the most bizarrely convoluted & prescriptive set of parameter inputs that i still haven't quite bent my head around ... as someone with a tendency to 'overthinking' things myself, i sympathise ... mind you, the more direct & literal interpretation (give me a table for setting freqs & a table for setting amps) basically becomes operationally synonymous with one of these now numerous listed alternatives ...

Speaking of SPEAR, i actually realised poking around last night that 'Sonic Visualiser' does more than just display, but is actually capable of exporting data in various formats through it's plugins. I am on the cusp of joining their forum (sound the alarms ...) & saying 'hey folks, any SDIF analysis & export planned?', but as this thread is now continuing, i wonder if anyone here is using Sonic Visualiser to export meaningful performance data (rather than just as a visual reference ...) &/or is more actively involved in the SV community ... (i searched their list for SDIF, zero hits ...)

'Vamp plugins' seems to be the name of the game there ... need an SDIF one of those ... with SPEAR having not been updated in 8 years, & my attempts to sound out Mr. Spear greeted with silence, i fear an over reliance upon it might one day bring all this lunacy of mine to a grinding halt ...

Reply | Threaded
Open this post in threaded view
|

Re: [Csnd] pvscale

Nathan Holmes
Sounds like you've been down a lot of the same paths I have! I haven't ever tried the "poor man's SDIF", but I've considered similar possibilities. But speaking of, I'm a little surprised Csound doesn't have any support for SDIF import or conversion other than that sdif2ad utility for the hetro/adsyn format. I think I remember seeing a post from someone saying they might implement an SDIF->pvifd/TRACKS-pv converter, but it doesn't seem to have happened (I assume it has something to do with waning enthusiasm over SDIF as a format in general.).

But yeah, I like to mess around with SPEAR and data exported from SPEAR periodically. It is a shame it hasn't been updated in so long.

I toy with Loris every once in a while. I once spent several days attempting to compile the Windows opcodes with only headaches to show for it. But, by contrast, the Linux Python modules and command line version are pretty easy to set up, so I run those in a virtual Linux machine. It seems to have a somewhat more effective partial tracking system, at least for my purposes (probably related to the fact that it assumes a periodic or quasi-periodic signal, whereas pvifd/partials seems to be more general), and it generates SDIF files. Since Loris tracks harmonics reasonably well, I've had some interesting results by doing a Loris analysis and then importing that into SPEAR.

As long as I'm rambling about tools that are easier to set up on Linux, I'm also reminded of Xavier Serra's sms-tools Python package. It has good harmonic tracking for periodic signals, probably even better than Loris's, but it doesn't seem to provide any ready-made SDIF or partial data export options. Yet I imagine it wouldn't be that hard to write my own conversion/export tool for SPEAR's text format. Or I suppose I could just write a quick Python script to loop through a few partials and render them separately as WAVs, maybe that's the easiest solution for working with isolated harmonics. Hmm.

Never really thought about Sonic Visualiser/VAMP, myself, although I think I came across the idea some time ago when looking up cepstral analysis. Might be something I'll look into more.

You know, I think ATS or ATSA used to be broken in the Windows version of Csound. I seem to remember having difficulties with that too, some years ago. But it's been working fine for me over the last few years worth of Csound updates.


On Sun, Aug 27, 2017 at 11:36 AM, Tim Mortimer <[hidden email]> wrote:
Hey Nathan ... thanks for the further input ...

to be honest, with table read & write of hard freq & amp values now the
preferred option (& mags ... that's still probably my next move on the
subject ...), i am wondering if i should simply look at adsyn / adsynt2
(which i have used a bit doing a sort of 'poor mans SDIF' based routine,
based on DATA derived from SPEAR) ... & possibly even marrying that adsyn
partials resynthesis with a fsig based residual ... pretty sure i conducted
that experiment previously to some effect ... the 'i can't believe it's not
ATS' approach (residual frame-iness aside ...)

My use of pvscale really stems from my very early days with csound ... read
the manual, had limited knowledge of the underlying processes, that seemed
to nominated itself for the task at hand & i've been bashing away with it on
& off ever since ...

 i've been approaching this problem from a different angle in the interim,
simply by tightening up my interrogation of GEN43 files in Python & writing
some more organised & useful classes, slightly less dumb algorithms ... &
sort of 'widening the berth' a bit in terms of 'group' assignment of bins
... (all my processes are offline render based now ... the ability to batch
import audio on cue into Reaper & then script additional fades, enveloping
etc has been a deal-sealer for me, & i think the element i have been
missing, as handling complex polyphony & retriggering in csound was just
adding too much complexity to my designs ... i could get them working, but
the limits of their extensibility were bounded by my reluctance to really
design anything more complex. Rendering one note at a time on the other hand
... 'hold my beer' as they say ... ; )

I could never get ATS noise to playback on my old Win XP machine, so
abandoned my experiments ... (that was way back however, when i first
started dabbling & had a period of heavy activity on this list ...)

I'd like to investigate the Python Loris classes, but i have no idea how to
compile the FFT library dependency it sits upon ... & it's not a priority
...

Which, in the survey of alternatives, brings us to 'pvadd' ... pretty sure
i've read that manual entry a few times, thinking 'this looks useful', &
then being confronted by (no disrespect intended ..) the most bizarrely
convoluted & prescriptive set of parameter inputs that i still haven't quite
bent my head around ... as someone with a tendency to 'overthinking' things
myself, i sympathise ... mind you, the more direct & literal interpretation
(give me a table for setting freqs & a table for setting amps) basically
becomes operationally synonymous with one of these now numerous listed
alternatives ...

Speaking of SPEAR, i actually realised poking around last night that 'Sonic
Visualiser' does more than just display, but is actually capable of
exporting data in various formats through it's plugins. I am on the cusp of
joining their forum (sound the alarms ...) & saying 'hey folks, any SDIF
analysis & export planned?', but as this thread is now continuing, i wonder
if anyone here is using Sonic Visualiser to export meaningful performance
data (rather than just as a visual reference ...) &/or is more actively
involved in the SV community ... (i searched their list for SDIF, zero hits
...)

'Vamp plugins' seems to be the name of the game there ... need an SDIF one
of those ... with SPEAR having not been updated in 8 years, & my attempts to
sound out Mr. Spear greeted with silence, i fear an over reliance upon it
might one day bring all this lunacy of mine to a grinding halt ...





--
View this message in context: http://csound.1045644.n5.nabble.com/pvscale-tp5757615p5757705.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
[hidden email]
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list [hidden email] https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here