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.

Would one need a pvsbandreject as well?

==John ff

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.
> 


I would suggest adding a "slope" or "transition" parameter as well, so 
that the sides of the band need not be vertical - which can play havoc 
with phases, frequencies, etc.


Richard Dobson

I have committed code the the CVS to do the simple bandpass; code is 
indeed simple.  I do need to test it which I have not done yet.

Richard Dobson is in my university studio as I type so am about to go and 
ask him for more detail on his suggestion.

==John

On Tue, 11 Dec 2007, jpff@cs.bath.ac.uk wrote:

> Richard Dobson is in my university studio as I type so am about to go and 
> ask him for more detail on his suggestion.
> 


After a short discussion I have a clear model and a better implementation 
designed.  Will try to write this evening/overnight.

Thanks for the idea.

I think a bandreject will also happen as it is useful

==John
 

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"

Hector Centeno wrote:
> 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
> 


Hmm, having taken a look at the latest verison of SC:  I don't think we 
can properly call those "PVS" opcodes, as the frames are not of pvoc 
mag/freq pairs but raw FFT real/imag frames, so really they are "FFS" - 
Fast Fourier Streaming opcodes. Do people generally use them with the 
default options, which are a little unexpected - Welch window, and 50% 
overlap?

And from reading the docs (I am not an SC user), it would appear that 
each PV opcode does its own conversion to magnitude and phase, and then 
back to complex, which is somewhat different from directly tracking 
(accumulating) phase as defined by the phase vocoder. This may even 
offer some advantages for some processes, but porting those opcodes in a 
way which preserves their behaviour may be non-trivial where not 
impossible - at least unless we activate the PVOCEX COMPLEX fsig format, 
and create a distinct set of opcodes that operate on that frame format. 
I am also unsure to what extent they will translate into a form 
compatible with SDFT (overlap = 1) - it will depend on whether 
assumptions are made in the code about the frequency ranges of bins, 
rather than by reading off frequency values directly.

Richard Dobson