Tim Mortimer:
> continuing from 1 or 2 recent threads that seemed to converge onto similar
> territory...
>
> 2) if 1) is in fact true (that all single cycle wavs will be understood as
> harmonic weights) then GEN30 starts to make a lot more sense..

It is true. But do not expect that the Fourier partials are necessarily what 
you hear. They interfere with other, usually, and that does produce the 
tones that you actually hear.

> I wonder though - rather than make a whole bunch of gen30's active up to 
> the
> nyquist for each possible "note" or key - wouldnt it make more sense to
> simply report the values found via gen 30 in a format that represents 
> simply
> an amplitude & freq value for each reported partial?
>
> The data could then be made accessible to adsynt & arbitrary rescaling of
> partial weights could be undertaken (as well as an easy algorithm
> constructed to silence all partials beyond the nyquist just like gbuzz
> enables.....)
>
> why am i so obsesed with this? partly because of the nyquist issue, but
> partly also because i want to interpolate spectral analysis information to
> change the colour & partial weight of any given oscillator over the 
> keyboard
> spread / pitch range... (just as i want to do with my resynthesis based
> instruments...)

The pvs family of opcodes do this kind of thing, quite well in my 
experience, and you can build the coefficients to drive pvs. You can put the 
coefficients into an ftable and use pvsftr to get the data from the table 
into an fsig.

Note: in my limited use of these opcodes, mainly to help other composers, I 
have been quite impressed. They "take apart" time/frequency 
analysis/resynthesis into a bunch of building blocks that you can control at 
krate, patch together in different combinations, and so on. You can read or 
write data from or to either arate signals or analysis files.

I think, but I have not tried it, that you can create or read an fsig, 
stream it to a PVOC-EX file, and use the PV_EXPORT utility to translate it 
into human-readable text; it works going from text back to PVOC-EX and then 
fsig as well.

> As usual then, SPEAR seems to be the answer to my spectral analysis &
> reworking problems - but that's at the mercy of external forces, & expiry
> dates on installations, & as even Max has SDIF capability with some cnmat
> externals or some such, (compared to the "straitjacket" of adsyn & the
> limitations of hetro (16bit from memory?) i think this whole point does 
> need
> attention.
>
> As i have repeated through now mantra like repetitions - the accessibility
> to analysis data itself purely as "data" in txt format has the potential 
> to
> facilitate pretty much all the resynthesis forms (including pvx) as it
> enables purely arbitrary or customised partial v noise identification, & 
> the
> possibility of identifying "formants" &/or "bandwidth enhancing" any
> partials if the amplitude of neighbouring bins seems to indicate any
> excessive weighting...
>
> generic text based reporting of FFT analysis would open the doors to
> enabling any resynthesis file format to be "fashioned" by specifying
> parameters for the resynthesis file (pvx, loris, additive, ats partials &
> noise..), creating it & then offering it to the appropriate opcode for
> conversion to fsig or asig as appropriate...

I agree about the desirability of direct text import/export. But for now you 
can obtain this by putting the pvs fsig into a table with pvsftw and writing 
the table in a loop to a text file, if you like.

There also is a pvs fsig bus facility.

When I complete the linear algebra opcodes, you will be able to manipulate 
fsigs using all normal linear algebra operations, since the fsig will be a 
vector of complex numbers as far as the linear algebra opcodes are 
concerned. You will be able to convolve, e.g., by multiplying fsigs.

Regards,
Mike