Skip to content

pvsftw

Writes amplitude and/or frequency data to function tables.

Syntax

kflag = pvsftw(fsrc, ifna [, ifnf])

kflag pvsftw fsrc, ifna [, ifnf]

Initialization

ifna -- Table number for amplitude data. Use 0 to skip amplitude export.

ifnf -- Table number for frequency data, or phase data when fsrc uses amplitude/phase format. The default is 0, which skips this export.

Each enabled table needs room for N/2 + 1 values, where N is the source FFT size. These include the DC and Nyquist bins. The table's guard point can hold the last value. Setting both table numbers to 0 updates only kflag.

Performance

kflag -- A flag that has the value of 1 when new data is available, 0 otherwise.

fsrc -- A non-sliding spectral signal in amplitude/frequency or amplitude/phase format. Reinitialize pvsftw if the source's FFT size or format changes.

Enables the contents of fsrc to be exchanged with function tables, for custom processing. Except when the frame overlap equals ksmps (which will generally not be the case), the frame data is not updated each control period. The data in ifna, ifnf should only be processed when kflag is set to 1. To process only frequency data, set ifna to zero.

As the functions tables are required only to store data from fsrc, there is no advantage in defining then in the score. They should generally be created in the instrument using ftgen.

By exporting amplitude data, say, from one fsig and importing it into another, basic cross-synthesis (as in pvscross) can be performed, with the option to modify the data beforehand using the table manipulation opodes.

Note that the format data in the source fsig is not written to the tables. This therefore offers a means of transferring amplitude and frequency data between non-identical fsigs. Used this way, these opcodes become potentially pathological, and can be relied upon to produce unexpected results. In such cases, resynthesis using pvsadsyn would almost certainly be required.

To perform a straight copy from one fsig to another one of identical format, the conventional assignment syntax can be used:

fsig1 = fsig2

It is not necessary to use function tables in this case.

Examples

Here is an example of the pvsftw opcode. It uses the file pvsftw.csd.

Example of the pvsftw opcode.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
<CsoundSynthesizer>
<CsOptions>
; Select audio/midi flags here according to platform
-odac  ;;;realtime audio out
;-iadc    ;;;uncomment -iadc if realtime audio input is needed too
; For Non-realtime ouput leave only the line below:
; -o pvsftw.wav -W ;;; for file output any platform
</CsOptions>
<CsInstruments>

sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

; analyze sound file, creating a PVOC-EX file
ires1 system_i 1,{{ pvanal fox.wav fox.pvx }}          ; default settings

instr 1

inbins  =       512
ifn     ftgen   0,0,inbins,10,1         ; make ftable
fsrc    pvsdiskin "fox.pvx", 1, 1       ; read PVOCEX file
kflag   pvsftw  fsrc,ifn                ; export amps to table,
kamp    init    0
if      kflag==0   kgoto contin         ; only proc when frame is ready                                                 
        tablew  kamp,1,ifn              ; kill lowest bins, for obvious effect
        tablew  kamp,2,ifn
        tablew  kamp,3,ifn
        tablew  kamp,4,ifn
; read modified data back to fsrc
        pvsftr  fsrc,ifn
contin:
; and resynth
aout    pvsynth fsrc
        outs    aout, aout

endin

</CsInstruments>
<CsScore>
i 1 0 5.5
e
</CsScore>
</CsoundSynthesizer>

See also

pvsenvftw writes a smoothed spectral envelope instead of the individual bin amplitudes.

Tools for Real-time Spectral Processing (pvs opcodes)

Credits

Author: Richard Dobson
August 2001

New in version 4.13