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










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

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

Hi Tim,
Aug 23 2017, Tim Mortimer has written:
...
> 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
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

>>> 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
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Tim,

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  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
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

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

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





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

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

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
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

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
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here