Great! Thanks a lot to John ffitch for working on that so quickly. Please let us know when they are ready in CVS (this new opcodes will come very handy in a present project). How difficult is the SuperCollider-Csound port in general? Maybe someone who has done that before could be interested in porting the SuperCollider PVS opcodes. Cheers, Hector On Dec 11, 2007 2:11 PM, Dr. Richard Boulanger wrote: > Hector et.al. > > It would be really wonderful to have John's new opcode for sure > AND > incredibly SUPER to have ALL the SuperCollider Opcodes in Csound! > (The PV set defined below - and.... whatever else we might be missing > from SuperCollider.) > > -dr.B. > > > On Dec 11, 2007, at 12:42 PM, Hector Centeno wrote: > > > 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" > >>> > >> > >> > > > > > > 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" >