Csound Csound-dev Csound-tekno Search About

[Csnd] Re: pvs oscillator collection? (potentially "hello Victor" again..)

Date2008-01-24 09:04
Fromvictor
Subject[Csnd] Re: pvs oscillator collection? (potentially "hello Victor" again..)
Not sure what your question is really?

pvsosc is a very simple thing: it creates frames with harmonics
according to a certain shape.

You could I suppose generate various waveshapes by combining
its pulse-wave output with pvsmaska.

Victor

----- Original Message ----- 
From: "Tim Mortimer" 
To: 
Sent: Thursday, January 24, 2008 5:02 AM
Subject: [Csnd] pvs oscillator collection? (potentially "hello Victor" 
again..)


>
> How much data are the oscillators in pvsosc based upon, & if i wanted to
> shoot some .pvx analysis files of oscillator shapes of my own (that were 
> say
> simple cycles of 1024 or 512 or 2048 samples in length) what would be the
> simplest & best way to do that - can i capture all the info theoretically 
> in
> "a single frame" & save it to .pvx?
>
> percieved advantages:
>
> * no nyquist issues on oscillator based synthesis (as the GEN30 
> "workaround"
> is based on an FFT analysis anyway...)
> * further pvx processing possibilities / merger of synthesis & sample
> resynthesis
> * effectively makes concurrent fsig oscillator signal streams "phase
> syncronous" if being reproduced under the same parameter conditions
> (overlap, bin count etc...) ??? (Victor? Anyone?)
>
> percieved disadvantages:
>
> may result in a less "pure" or representative synthesis on large
> transposition values of the signal upward or downward (which would have to
> use pvsscale assumedly...)
>
> has anyone gone down this route at all using pvx to achieve phase syncrous
> concurrent signals for crossfadeing ?
>
> as far as FM goes, i could always do it & then create an fsig stream based
> on it using pvsanal
>
> the whole reason for the desire to pre-analyse the others oscillators is 
> to
> avoid nyquist flippage on (hopefully phase synceable, & hence
> crossfadeable..) square-like wave shapes...
>
> but then assumedly any nyquist defying square shape will also pollute any
> subsequent fft analysis?
>
> but then how does gen30 "solve the problem"?
>
> please help me understand!
>
> many thanks...
>
>
>
>
> -- 
> View this message in context: 
> http://www.nabble.com/pvs-oscillator-collection--%28potentially-%22hello-Victor%22-again..%29-tp15058819p15058819.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 


Date2008-01-24 10:05
FromTim Mortimer
Subject[Csnd] Re: pvs oscillator collection? (potentially "hello Victor" again..)
Sorry, try again:

My question is:

if im simply wishing to fft analyse a single "oscillation" of a wave (that
is for convenience say 2048 samples long...) can i perform a valid &
accurate fft analysis using 2048 bins that is 1 frame in length, & save this
single frame as a .pvx file to use?

if so, what analysis settings would best enable this (no overlaps etc?)

i then suggested that this process might in fact be somehow synonymous with
the whole idea & modus operandi of gen30, in as far as it would enable
alaising of "pointy" waveshapes to be avoided, & relies on fft analysis of
the sample/ oscillator to achieve this end...

that's why i went on to ask about how gen30 achieves this avoidance of
nyquist foldover post analysis, if the input shape was prone to produce some
sort of foldover in the first place (ie if you gen30 something that
essentially looks like an impulse, aren't you just getting out an fft
analysis that includes any potential nyquist reflections?

hope that's clearer...


Victor.Lazzarini wrote:
> 
> Not sure what your question is really?
> 
> pvsosc is a very simple thing: it creates frames with harmonics
> according to a certain shape.
> 
> You could I suppose generate various waveshapes by combining
> its pulse-wave output with pvsmaska.
> 
> Victor
> 
> ----- Original Message ----- 
> From: "Tim Mortimer" 
> To: 
> Sent: Thursday, January 24, 2008 5:02 AM
> Subject: [Csnd] pvs oscillator collection? (potentially "hello Victor" 
> again..)
> 
> 
>>
>> How much data are the oscillators in pvsosc based upon, & if i wanted to
>> shoot some .pvx analysis files of oscillator shapes of my own (that were 
>> say
>> simple cycles of 1024 or 512 or 2048 samples in length) what would be the
>> simplest & best way to do that - can i capture all the info theoretically 
>> in
>> "a single frame" & save it to .pvx?
>>
>> percieved advantages:
>>
>> * no nyquist issues on oscillator based synthesis (as the GEN30 
>> "workaround"
>> is based on an FFT analysis anyway...)
>> * further pvx processing possibilities / merger of synthesis & sample
>> resynthesis
>> * effectively makes concurrent fsig oscillator signal streams "phase
>> syncronous" if being reproduced under the same parameter conditions
>> (overlap, bin count etc...) ??? (Victor? Anyone?)
>>
>> percieved disadvantages:
>>
>> may result in a less "pure" or representative synthesis on large
>> transposition values of the signal upward or downward (which would have
>> to
>> use pvsscale assumedly...)
>>
>> has anyone gone down this route at all using pvx to achieve phase
>> syncrous
>> concurrent signals for crossfadeing ?
>>
>> as far as FM goes, i could always do it & then create an fsig stream
>> based
>> on it using pvsanal
>>
>> the whole reason for the desire to pre-analyse the others oscillators is 
>> to
>> avoid nyquist flippage on (hopefully phase synceable, & hence
>> crossfadeable..) square-like wave shapes...
>>
>> but then assumedly any nyquist defying square shape will also pollute any
>> subsequent fft analysis?
>>
>> but then how does gen30 "solve the problem"?
>>
>> please help me understand!
>>
>> many thanks...
>>
>>
>>
>>
>> -- 
>> View this message in context: 
>> http://www.nabble.com/pvs-oscillator-collection--%28potentially-%22hello-Victor%22-again..%29-tp15058819p15058819.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound" 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/pvs-oscillator-collection--%28potentially-%22hello-Victor%22-again..%29-tp15058819p15061935.html
Sent from the Csound - General mailing list archive at Nabble.com.


Date2008-01-24 10:43
FromRichard Dobson
Subject[Csnd] Re: Re: pvs oscillator collection? (potentially "hello Victor" again..)
Tim Mortimer wrote:
> Sorry, try again:
> 
> My question is:
> 
> if im simply wishing to fft analyse a single "oscillation" of a wave (that
> is for convenience say 2048 samples long...) can i perform a valid &
> accurate fft analysis using 2048 bins that is 1 frame in length, & save this
> single frame as a .pvx file to use?
> 

Sorry, mostly lurking as head full of other stuff at the moment. I would 
tend to regard that as a plain FFT - somehwat meaningless to convert it 
to full pvoc amp/freq as freq is the phase difference from one frame to 
the next, and by definition you only have the one frame.


The PVOCEX (.pvx) file format does not support a literal single frame - 
it is based on CARL pvoc where there is always a zero (empty) first 
frame (which I guess kind of gives you a starting amp/freq basis). There 
is a potential advantage to this, though I haven't published it (yet) - 
to use a .pvx file with just one frame to represent an single-frame 
impulse respsonse (in raw COMPLEX format) for convolution purposes. I 
have a private build of my "pvocex2" program that does just this. Now 
that we have partitioned convolution this single-frame method is 
obsolete (the latency is of the duration of the frame, which will 
typically be a very large one), unless some other virtue can be 
identified for it.  In any case, were single-frame pvx files to become 
relevant to users, we should really extend PVOCEX to define it formally 
(as a new format type).

So you would need to write 2 frames to the file, the empty first one, 
and then your second one. But I would question whether this was the best 
use of a pvx file per se.

Note that you can create aliasing in a pvoc frame simply by writing an 
excessive frequency value in the topmost bins. In the general case, of 
course, if the aliasing is already present in  the time-domain signal 
(such as a raw square wave) it will show up very vividly in the FFT.




Richard Dobson