Thanks for your responses, I'm looking for a very CPU efficient way of doing it because this "bandpassing" would be part of other processes in a realtime instrument, that's why I'm trying to avoid ftable writing. What John ffitch proposes sounds great: root wrote: > I do not have a suggestion as how to do it now, but a new opcode to do a > bandpass on an f-signal would be VERY easy to code. Something like > fsigout pvsband fsigin, klower, khigher > which zeros outside range and copies within. > With added slope parameters as Richard Dobson suggests. That would be exactly what I'm looking for. pvsadsyn wouldn't make it because it does re-synthesis and I want to keep everything in fsigs for further processing. I was looking at the SuperCollider manual and some of the pv transformation tools available seem very helpful, it would be nice to have a port of them to Csound. This is from the SuperCollider manual, some of them we already have in Csound (just in case there are any Csound programmers interested in expanding the PV opcodes in Csound): [PV_Add] complex addition [PV_BinScramble] scramble bins [PV_BinShift] shift and stretch bin position [PV_BinWipe] combine low and high bins from two inputs [PV_BrickWall] zero bins [PV_ConformalMap] complex plane attack [PV_Copy] copy an FFT buffer [PV_CopyPhase] copy magnitudes and phases [PV_Diffuser] random phase shifting [PV_LocalMax] pass bins which are a local maximum [PV_MagAbove] pass bins above a threshold [PV_MagBelow] pass bins below a threshold [PV_MagClip] clip bins to a threshold [PV_MagFreeze] freeze magnitudes [PV_MagMul] multiply magnitudes [PV_MagNoise] multiply magnitudes by noise [PV_MagShift] shift and stretch magnitude bin position [PV_MagSmear] average magnitudes across bins [PV_MagSquared] square magnitudes [PV_Max] maximum magnitude [PV_Min] minimum magnitude [PV_Mul] complex multiply [PV_PhaseShift] [PV_PhaseShift270] shift phase by 270 degrees [PV_PhaseShift90] shift phase by 90 degrees [PV_RandComb] pass random bins [PV_RandWipe] crossfade in random bin order [PV_RectComb] make gaps in spectrum [PV_RectComb2] make gaps in spectrum Cheers, Hector On Dec 11, 2007 7:58 AM, peiman khosravi wrote: > I have used pvsadsyn for this purpose as you can define te number of bins > and the starting point for resynthesis of fsig signals. The problem is of > course knowing the frequency region of each bin. As chuck mentioned I think > it would be similar with pvsmaska, as the bandwidth of each bin depends on > your fft windowing size (is that right!?). So if you are synthesising the > first say 10 bins of an fsig with a window size of 512 you are covering a > much wider frequency range than you would be with a window size of 1024 > (higher frequency resolution). Don't ask me the maths though! The easiest > way would be to use pvsbufread as it does the calculation for you and > accepts frequency numbers for lowest and highest resynthesis bounds. If you > are not using this for live stuff then I don't see how a very short delay > would be a problem, you are always going to get the fft delay anyway so > perfect synching with the original audio signal is not possible unless you > delay the original signal too by the right amount. > > As Richard mentioned it would be amazingly helpful to have a smoothing > function too for filtering :-) > > Best > Peiman > > > > On 11/12/2007, Chuckk Hubbard wrote: > > On Dec 11, 2007 7:35 AM, Hector Centeno wrote: > > > > > I've been looking for the most efficient way of "bandpass" filtering > > > bins in a fsig for a realtime instrument. What I want to do is to be > > > able to split an fsig into different fsigs containing diferent bin > > > sections (for independent processing). I guess I could use the pvsftr > > > and pvsftw opcodes together with the vectorial opcodes to alter the > > > table, but I was wondering if I'm missing any other way of doing it > > > more CPU efficient without having to rewrite tables (I want to be able > > > to change the ranges realtime). Also I thought about using pvstencil > > > > I thought of pvsmaska, but that uses ftables too. There is pvsfilter; > > I suppose you could generate a signal with pure sines of the right > > frequencies, pvsanal it, and pvsfilter the two fsigs. I would guess > > pvsmaska is more efficient. I'm afraid I still don't completely > > understand Csound's frequency-amplitude pairs. I read some of the > > documentation offered when I asked about it, but from what I could > > tell it was still referring to equally spaced bins, where pvsvoc > > implies that the frequencies of one fsig can differ from those of > > another fsig of the same size. Point being that, if you don't know > > what frequencies the bins of your signal will have, how do you know > > what frequencies to use for sines to analyze to get the desired > > filter? And my suspicion being that the bins have fixed frequency > > values, and "amp-freq" pair refers to "freq" being the same for all > > fsigs of the same size... > > > > Anyway I would personally use pvsmaska; I don't know how a k-rate > > specification would even work, if it has to specify 512 or however > > many values per control period. pvsbufread has upper and lower limits > > of which frequencies to include... > > > > > On the request side: It could be nice to have an opcode for doing > > > this, one that simply takes a fsig and two k-rate parameters for the > > > lowest and highest bin and outputs another fsig containing only those > > > bins with the rest zeroed. > > > > Sounds like pvsbufread. I haven't played with it to know how much > > delay is necessary, but maybe I will today... > > > > -Chuckk > > > > -- > > http://www.badmuthahubbard.com > > > > > > Send bugs reports to this list. > > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" > > > >