Hi all,

Following from yesterday's post, I have been wandering how to do the
following operations in csound, using the pvs opcodes. After thinking for
some hours about this I still cannot come up with an answer.

1-spectral delay, where the amount of delay for individual bins is defined
in a function table (prefebally this would also include feedback with
control over the amount of feedback).

2-the ability to change the rate at which fft frames are updated so to
average the time resolution of the input.

So in short I cannot work out how to do time-domain operations on pvs
streams or fft bins.

Any comments are very much welcome :-)

Many Thanks
Peiman    
-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
Sent from the Csound - General mailing list archive at Nabble.com.

At 12:54 16/10/2007, you wrote:

>Hi all,
>
>Following from yesterday's post, I have been wandering how to do the
>following operations in csound, using the pvs opcodes. After thinking for
>some hours about this I still cannot come up with an answer.
>
>1-spectral delay, where the amount of delay for individual bins is defined
>in a function table (prefebally this would also include feedback with
>control over the amount of feedback).

Use the new opcodes pvsbuffer and pvsbufread


>2-the ability to change the rate at which fft frames are updated so to
>average the time resolution of the input.

Also pvsbuffer and pvsbufread. These are the two prime target
operations for the new opcodes. Hope they do what you want.

Victor



>So in short I cannot work out how to do time-domain operations on pvs
>streams or fft bins.
>
>Any comments are very much welcome :-)
>
>Many Thanks
>Peiman
>--
>View this message in context: 
>http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Great!

Thanks Victor. I will look at them right now.

Best
Peiman


Victor Lazzarini wrote:
> 
> At 12:54 16/10/2007, you wrote:
> 
>>Hi all,
>>
>>Following from yesterday's post, I have been wandering how to do the
>>following operations in csound, using the pvs opcodes. After thinking for
>>some hours about this I still cannot come up with an answer.
>>
>>1-spectral delay, where the amount of delay for individual bins is defined
>>in a function table (prefebally this would also include feedback with
>>control over the amount of feedback).
> 
> Use the new opcodes pvsbuffer and pvsbufread
> 
> 
>>2-the ability to change the rate at which fft frames are updated so to
>>average the time resolution of the input.
> 
> Also pvsbuffer and pvsbufread. These are the two prime target
> operations for the new opcodes. Hope they do what you want.
> 
> Victor
> 
> 
> 
>>So in short I cannot work out how to do time-domain operations on pvs
>>streams or fft bins.
>>
>>Any comments are very much welcome :-)
>>
>>Many Thanks
>>Peiman
>>--
>>View this message in context: 
>>http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13231958
Sent from the Csound - General mailing list archive at Nabble.com.

Wow! this is amazing. Just what I was after :-)


Victor Lazzarini wrote:
> 
> At 12:54 16/10/2007, you wrote:
> 
>>Hi all,
>>
>>Following from yesterday's post, I have been wandering how to do the
>>following operations in csound, using the pvs opcodes. After thinking for
>>some hours about this I still cannot come up with an answer.
>>
>>1-spectral delay, where the amount of delay for individual bins is defined
>>in a function table (prefebally this would also include feedback with
>>control over the amount of feedback).
> 
> Use the new opcodes pvsbuffer and pvsbufread
> 
> 
>>2-the ability to change the rate at which fft frames are updated so to
>>average the time resolution of the input.
> 
> Also pvsbuffer and pvsbufread. These are the two prime target
> operations for the new opcodes. Hope they do what you want.
> 
> Victor
> 
> 
> 
>>So in short I cannot work out how to do time-domain operations on pvs
>>streams or fft bins.
>>
>>Any comments are very much welcome :-)
>>
>>Many Thanks
>>Peiman
>>--
>>View this message in context: 
>>http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13232538
Sent from the Csound - General mailing list archive at Nabble.com.

 >1-spectral delay, where the amount of delay for individual bins is 
 >defined in a function table (prefebally this would also include 
 >feedback with control over the amount of feedback).

If you have a simple example of what you describe above I would love to 
see it, would you mind posting it?

Rory.



peiman wrote:
> Wow! this is amazing. Just what I was after :-)
> 
> 
> Victor Lazzarini wrote:
>> At 12:54 16/10/2007, you wrote:
>>
>>> Hi all,
>>>
>>> Following from yesterday's post, I have been wandering how to do the
>>> following operations in csound, using the pvs opcodes. After thinking for
>>> some hours about this I still cannot come up with an answer.
>>>
>>> 1-spectral delay, where the amount of delay for individual bins is defined
>>> in a function table (prefebally this would also include feedback with
>>> control over the amount of feedback).
>> Use the new opcodes pvsbuffer and pvsbufread
>>
>>
>>> 2-the ability to change the rate at which fft frames are updated so to
>>> average the time resolution of the input.
>> Also pvsbuffer and pvsbufread. These are the two prime target
>> operations for the new opcodes. Hope they do what you want.
>>
>> Victor
>>
>>
>>
>>> So in short I cannot work out how to do time-domain operations on pvs
>>> streams or fft bins.
>>>
>>> Any comments are very much welcome :-)
>>>
>>> Many Thanks
>>> Peiman
>>> --
>>> View this message in context: 
>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>> --
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> Victor Lazzarini
>> Music Technology Laboratory
>> Music Department
>> National University of Ireland, Maynooth
>>
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>
>>
> 

Hi,
Sure! I have been very busy to make the instrument today but I will probably
do it tonight and send a copy tomorrow. 
Best
Peiman 

PS I have just finished a blue plug-in instrument that kind of does the same
thing as the GRM frequency warp plugin
http://www.grmtools.org/quicktour/vstqtst/warp.html you can find it here in
the folder spectral blue. I'd be interested to see what you think about it:
http://idisk.mac.com/peimankh-Public?view=web


rory walsh wrote:
> 
>  >1-spectral delay, where the amount of delay for individual bins is 
>  >defined in a function table (prefebally this would also include 
>  >feedback with control over the amount of feedback).
> 
> If you have a simple example of what you describe above I would love to 
> see it, would you mind posting it?
> 
> Rory.
> 
> 
> 
> peiman wrote:
>> Wow! this is amazing. Just what I was after :-)
>> 
>> 
>> Victor Lazzarini wrote:
>>> At 12:54 16/10/2007, you wrote:
>>>
>>>> Hi all,
>>>>
>>>> Following from yesterday's post, I have been wandering how to do the
>>>> following operations in csound, using the pvs opcodes. After thinking
>>>> for
>>>> some hours about this I still cannot come up with an answer.
>>>>
>>>> 1-spectral delay, where the amount of delay for individual bins is
>>>> defined
>>>> in a function table (prefebally this would also include feedback with
>>>> control over the amount of feedback).
>>> Use the new opcodes pvsbuffer and pvsbufread
>>>
>>>
>>>> 2-the ability to change the rate at which fft frames are updated so to
>>>> average the time resolution of the input.
>>> Also pvsbuffer and pvsbufread. These are the two prime target
>>> operations for the new opcodes. Hope they do what you want.
>>>
>>> Victor
>>>
>>>
>>>
>>>> So in short I cannot work out how to do time-domain operations on pvs
>>>> streams or fft bins.
>>>>
>>>> Any comments are very much welcome :-)
>>>>
>>>> Many Thanks
>>>> Peiman
>>>> --
>>>> View this message in context: 
>>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>> --
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>> Victor Lazzarini
>>> Music Technology Laboratory
>>> Music Department
>>> National University of Ireland, Maynooth
>>>
>>> -- 
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>
>>>
>> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13243058
Sent from the Csound - General mailing list archive at Nabble.com.

Hi,

I have finally managed to put together a spectral delay instrument (sorry
for the delay!). It is working ;-) but I can't work out why changing the
control-rate or buffer size of csound, effects the delay time relatively
(e.g. moving from ksmps=100 to 10 increases the delay time for every bin by
over half!). 

This is I am sure as a result of the vecdelay opcode which I am using to
delay different fft bins according to a function table. Am I doing something
wrong though?

Many Thanks
Peiman

PLEASE SEE BELLOW FOR CSD




sr=44100
ksmps=100
nchnls=2

instr 1
ifndel      ftgen      0,0,512,-7, 1.9594594, 27.7113399506, 0.5135135651,
69.9381408691, 0.2162162066, 108.2061843872, 0.6351351738, 306.1443481445,0
ifn1         ftgen      0,0,1024,10,1        ; make ftable
ifn2     ftgen      0,0,1024,10,1        ; make ftable
ifncopy1     ftgen      0,0,1024,10,1        ; make ftable
ifncopy2     ftgen      0,0,1024,10,1        ; make ftable


ain1	diskin	 
"/Library/Frameworks/CsoundLib.framework/Versions/5.1/Resources/Manual/examples/beats.aiff",
1 

fsig1   pvsanal   ain1,1024,512/4,1024*2,1
fsig2   pvsanal   ain1,1024,512/4,1024*2,1
kflag   pvsftw    fsig1,ifn1
kflag1  pvsftw    fsig2,ifn2

if      kflag==0   kgoto contin1   

	vecdelay    ifncopy1, ifn1, ifndel, 512, 20
	pvsftr      fsig1,ifncopy1



if      kflag1==0   kgoto contin2  

	vecdelay  ifncopy2, ifn2, ifndel, 512, 20
	pvsftr    fsig2,ifncopy2


contin1:
aout1	pvsynth fsig1
ain1 delay ain1, (1024*2)/sr
aout1 = aout1 + ain1

contin2:
aout2	pvsynth fsig2
ain2 delay ain1, (1024*2)/sr
aout2 = aout2 + ain1
outs aout1, aout2
endin







i1 0 10


e





rory walsh wrote:
> 
>  >1-spectral delay, where the amount of delay for individual bins is 
>  >defined in a function table (prefebally this would also include 
>  >feedback with control over the amount of feedback).
> 
> If you have a simple example of what you describe above I would love to 
> see it, would you mind posting it?
> 
> Rory.
> 
> 
> 
> peiman wrote:
>> Wow! this is amazing. Just what I was after :-)
>> 
>> 
>> Victor Lazzarini wrote:
>>> At 12:54 16/10/2007, you wrote:
>>>
>>>> Hi all,
>>>>
>>>> Following from yesterday's post, I have been wandering how to do the
>>>> following operations in csound, using the pvs opcodes. After thinking
>>>> for
>>>> some hours about this I still cannot come up with an answer.
>>>>
>>>> 1-spectral delay, where the amount of delay for individual bins is
>>>> defined
>>>> in a function table (prefebally this would also include feedback with
>>>> control over the amount of feedback).
>>> Use the new opcodes pvsbuffer and pvsbufread
>>>
>>>
>>>> 2-the ability to change the rate at which fft frames are updated so to
>>>> average the time resolution of the input.
>>> Also pvsbuffer and pvsbufread. These are the two prime target
>>> operations for the new opcodes. Hope they do what you want.
>>>
>>> Victor
>>>
>>>
>>>
>>>> So in short I cannot work out how to do time-domain operations on pvs
>>>> streams or fft bins.
>>>>
>>>> Any comments are very much welcome :-)
>>>>
>>>> Many Thanks
>>>> Peiman
>>>> --
>>>> View this message in context: 
>>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>> --
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>> Victor Lazzarini
>>> Music Technology Laboratory
>>> Music Department
>>> National University of Ireland, Maynooth
>>>
>>> -- 
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>
>>>
>> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13352968
Sent from the Csound - General mailing list archive at Nabble.com.

Thanks for posting your example, I can't wait to have a look at it. Just 
yesterday I looked at pvsbuff and pvsbuffread for the first time, great 
opcodes. I had a lot of fun with my class today looking at different 
things that can be done with them. Thanks again to Victor for 
implementing them.

Rory.


peiman wrote:
> Hi,
> 
> I have finally managed to put together a spectral delay instrument (sorry
> for the delay!). It is working ;-) but I can't work out why changing the
> control-rate or buffer size of csound, effects the delay time relatively
> (e.g. moving from ksmps=100 to 10 increases the delay time for every bin by
> over half!). 
> 
> This is I am sure as a result of the vecdelay opcode which I am using to
> delay different fft bins according to a function table. Am I doing something
> wrong though?
> 
> Many Thanks
> Peiman
> 
> PLEASE SEE BELLOW FOR CSD
> 
> 
> 
> 
> sr=44100
> ksmps=100
> nchnls=2
> 
> instr 1
> ifndel      ftgen      0,0,512,-7, 1.9594594, 27.7113399506, 0.5135135651,
> 69.9381408691, 0.2162162066, 108.2061843872, 0.6351351738, 306.1443481445,0
> ifn1         ftgen      0,0,1024,10,1        ; make ftable
> ifn2     ftgen      0,0,1024,10,1        ; make ftable
> ifncopy1     ftgen      0,0,1024,10,1        ; make ftable
> ifncopy2     ftgen      0,0,1024,10,1        ; make ftable
> 
> 
> ain1	diskin	 
> "/Library/Frameworks/CsoundLib.framework/Versions/5.1/Resources/Manual/examples/beats.aiff",
> 1 
> 
> fsig1   pvsanal   ain1,1024,512/4,1024*2,1
> fsig2   pvsanal   ain1,1024,512/4,1024*2,1
> kflag   pvsftw    fsig1,ifn1
> kflag1  pvsftw    fsig2,ifn2
> 
> if      kflag==0   kgoto contin1   
> 
> 	vecdelay    ifncopy1, ifn1, ifndel, 512, 20
> 	pvsftr      fsig1,ifncopy1
> 
> 
> 
> if      kflag1==0   kgoto contin2  
> 
> 	vecdelay  ifncopy2, ifn2, ifndel, 512, 20
> 	pvsftr    fsig2,ifncopy2
> 
> 
> contin1:
> aout1	pvsynth fsig1
> ain1 delay ain1, (1024*2)/sr
> aout1 = aout1 + ain1
> 
> contin2:
> aout2	pvsynth fsig2
> ain2 delay ain1, (1024*2)/sr
> aout2 = aout2 + ain1
> outs aout1, aout2
> endin
> 
> 
> 
> 
> 
> 
> 
> i1 0 10
> 
> 
> e
> 
> 
> 
> 
> 
> rory walsh wrote:
>>  >1-spectral delay, where the amount of delay for individual bins is 
>>  >defined in a function table (prefebally this would also include 
>>  >feedback with control over the amount of feedback).
>>
>> If you have a simple example of what you describe above I would love to 
>> see it, would you mind posting it?
>>
>> Rory.
>>
>>
>>
>> peiman wrote:
>>> Wow! this is amazing. Just what I was after :-)
>>>
>>>
>>> Victor Lazzarini wrote:
>>>> At 12:54 16/10/2007, you wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Following from yesterday's post, I have been wandering how to do the
>>>>> following operations in csound, using the pvs opcodes. After thinking
>>>>> for
>>>>> some hours about this I still cannot come up with an answer.
>>>>>
>>>>> 1-spectral delay, where the amount of delay for individual bins is
>>>>> defined
>>>>> in a function table (prefebally this would also include feedback with
>>>>> control over the amount of feedback).
>>>> Use the new opcodes pvsbuffer and pvsbufread
>>>>
>>>>
>>>>> 2-the ability to change the rate at which fft frames are updated so to
>>>>> average the time resolution of the input.
>>>> Also pvsbuffer and pvsbufread. These are the two prime target
>>>> operations for the new opcodes. Hope they do what you want.
>>>>
>>>> Victor
>>>>
>>>>
>>>>
>>>>> So in short I cannot work out how to do time-domain operations on pvs
>>>>> streams or fft bins.
>>>>>
>>>>> Any comments are very much welcome :-)
>>>>>
>>>>> Many Thanks
>>>>> Peiman
>>>>> --
>>>>> View this message in context: 
>>>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>
>>>>> --
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>> Victor Lazzarini
>>>> Music Technology Laboratory
>>>> Music Department
>>>> National University of Ireland, Maynooth
>>>>
>>>> -- 
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>>
>>>>
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>
>>
> 

No problems :-) I found the error:

Just delete the conditional (if) statements along with the corresponding
labels and the problem is gone!

Best
Peiman


rory walsh wrote:
> 
> Thanks for posting your example, I can't wait to have a look at it. Just 
> yesterday I looked at pvsbuff and pvsbuffread for the first time, great 
> opcodes. I had a lot of fun with my class today looking at different 
> things that can be done with them. Thanks again to Victor for 
> implementing them.
> 
> Rory.
> 
> 
> peiman wrote:
>> Hi,
>> 
>> I have finally managed to put together a spectral delay instrument (sorry
>> for the delay!). It is working ;-) but I can't work out why changing the
>> control-rate or buffer size of csound, effects the delay time relatively
>> (e.g. moving from ksmps=100 to 10 increases the delay time for every bin
>> by
>> over half!). 
>> 
>> This is I am sure as a result of the vecdelay opcode which I am using to
>> delay different fft bins according to a function table. Am I doing
>> something
>> wrong though?
>> 
>> Many Thanks
>> Peiman
>> 
>> PLEASE SEE BELLOW FOR CSD
>> 
>> 
>> 
>> 
>> sr=44100
>> ksmps=100
>> nchnls=2
>> 
>> instr 1
>> ifndel      ftgen      0,0,512,-7, 1.9594594, 27.7113399506,
>> 0.5135135651,
>> 69.9381408691, 0.2162162066, 108.2061843872, 0.6351351738,
>> 306.1443481445,0
>> ifn1         ftgen      0,0,1024,10,1        ; make ftable
>> ifn2     ftgen      0,0,1024,10,1        ; make ftable
>> ifncopy1     ftgen      0,0,1024,10,1        ; make ftable
>> ifncopy2     ftgen      0,0,1024,10,1        ; make ftable
>> 
>> 
>> ain1	diskin	 
>> "/Library/Frameworks/CsoundLib.framework/Versions/5.1/Resources/Manual/examples/beats.aiff",
>> 1 
>> 
>> fsig1   pvsanal   ain1,1024,512/4,1024*2,1
>> fsig2   pvsanal   ain1,1024,512/4,1024*2,1
>> kflag   pvsftw    fsig1,ifn1
>> kflag1  pvsftw    fsig2,ifn2
>> 
>> if      kflag==0   kgoto contin1   
>> 
>> 	vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>> 	pvsftr      fsig1,ifncopy1
>> 
>> 
>> 
>> if      kflag1==0   kgoto contin2  
>> 
>> 	vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>> 	pvsftr    fsig2,ifncopy2
>> 
>> 
>> contin1:
>> aout1	pvsynth fsig1
>> ain1 delay ain1, (1024*2)/sr
>> aout1 = aout1 + ain1
>> 
>> contin2:
>> aout2	pvsynth fsig2
>> ain2 delay ain1, (1024*2)/sr
>> aout2 = aout2 + ain1
>> outs aout1, aout2
>> endin
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> i1 0 10
>> 
>> 
>> e
>> 
>> 
>> 
>> 
>> 
>> rory walsh wrote:
>>>  >1-spectral delay, where the amount of delay for individual bins is 
>>>  >defined in a function table (prefebally this would also include 
>>>  >feedback with control over the amount of feedback).
>>>
>>> If you have a simple example of what you describe above I would love to 
>>> see it, would you mind posting it?
>>>
>>> Rory.
>>>
>>>
>>>
>>> peiman wrote:
>>>> Wow! this is amazing. Just what I was after :-)
>>>>
>>>>
>>>> Victor Lazzarini wrote:
>>>>> At 12:54 16/10/2007, you wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Following from yesterday's post, I have been wandering how to do the
>>>>>> following operations in csound, using the pvs opcodes. After thinking
>>>>>> for
>>>>>> some hours about this I still cannot come up with an answer.
>>>>>>
>>>>>> 1-spectral delay, where the amount of delay for individual bins is
>>>>>> defined
>>>>>> in a function table (prefebally this would also include feedback with
>>>>>> control over the amount of feedback).
>>>>> Use the new opcodes pvsbuffer and pvsbufread
>>>>>
>>>>>
>>>>>> 2-the ability to change the rate at which fft frames are updated so
>>>>>> to
>>>>>> average the time resolution of the input.
>>>>> Also pvsbuffer and pvsbufread. These are the two prime target
>>>>> operations for the new opcodes. Hope they do what you want.
>>>>>
>>>>> Victor
>>>>>
>>>>>
>>>>>
>>>>>> So in short I cannot work out how to do time-domain operations on pvs
>>>>>> streams or fft bins.
>>>>>>
>>>>>> Any comments are very much welcome :-)
>>>>>>
>>>>>> Many Thanks
>>>>>> Peiman
>>>>>> --
>>>>>> View this message in context: 
>>>>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
>>>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>>>
>>>>>> --
>>>>>> Send bugs reports to this list.
>>>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>>> Victor Lazzarini
>>>>> Music Technology Laboratory
>>>>> Music Department
>>>>> National University of Ireland, Maynooth
>>>>>
>>>>> -- 
>>>>> Send bugs reports to this list.
>>>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>>>
>>>>>
>>> -- 
>>> Send bugs reports to this list.
>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>>
>>>
>> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13355899
Sent from the Csound - General mailing list archive at Nabble.com.

I just tried that instrument, that's a really nice effect, thanks again 
for posting.

Rory.


peiman wrote:
> No problems :-) I found the error:
> 
> Just delete the conditional (if) statements along with the corresponding
> labels and the problem is gone!
> 
> Best

yes well done peiman.

I haven't upped to 5.07 yet - but when i do this will be pretty much at the
top of my list.
-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13359589
Sent from the Csound - General mailing list archive at Nabble.com.

peiman wrote:
> No problems :-) I found the error:
> 
> Just delete the conditional (if) statements along with the corresponding
> labels and the problem is gone!
> 

This is a slightly deceptive solution, but maybe inescapable at present 
when combining vecdelay with the pvs routines. The use of the kflag test 
is in principle correct, as a new analysis frame is only generated every 
ten or so control cycles (depending on the ratio of ksmps to overlap); 
putting it another way, this means the pvs control rate is somewhat 
lower than a typical Csound kr. But vecdelay runs at the Csound kr (and 
of course will be implemented on that basis internally), so in the 
absence of the kflag controls, it wastefully overwrites the tables 
multiple times before they are actually used by  pvsynth.  Which means 
there is still a case for having a dedicated pvs version, one way or 
another.

Also note that as written, when kflag activates, it jumps over  the code 
associated with kflag1. In this case it is benign because the two 
signals run at the same frame rate; I suspect that if they were 
different (and thus updating in different control periods) a more 
elaborate testing scheme would be needed so that each analysis stream 
can be tested independently of the other. It is too early in the morning 
for me do do more than "leave this as an exercise"!



Richard Dobson




..
>>>kflag   pvsftw    fsig1,ifn1
>>>kflag1  pvsftw    fsig2,ifn2
>>>
>>>if      kflag==0   kgoto contin1   
>>>
>>>	vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>>>	pvsftr      fsig1,ifncopy1
>>>
>>>
>>>
>>>if      kflag1==0   kgoto contin2  
>>>
>>>	vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>>>	pvsftr    fsig2,ifncopy2
>>>
..

Thanks very much for your explanation Richard. It now all makes sense :-)  

Best
Peiman


Richard Dobson wrote:
> 
> peiman wrote:
>> No problems :-) I found the error:
>> 
>> Just delete the conditional (if) statements along with the corresponding
>> labels and the problem is gone!
>> 
> 
> This is a slightly deceptive solution, but maybe inescapable at present 
> when combining vecdelay with the pvs routines. The use of the kflag test 
> is in principle correct, as a new analysis frame is only generated every 
> ten or so control cycles (depending on the ratio of ksmps to overlap); 
> putting it another way, this means the pvs control rate is somewhat 
> lower than a typical Csound kr. But vecdelay runs at the Csound kr (and 
> of course will be implemented on that basis internally), so in the 
> absence of the kflag controls, it wastefully overwrites the tables 
> multiple times before they are actually used by  pvsynth.  Which means 
> there is still a case for having a dedicated pvs version, one way or 
> another.
> 
> Also note that as written, when kflag activates, it jumps over  the code 
> associated with kflag1. In this case it is benign because the two 
> signals run at the same frame rate; I suspect that if they were 
> different (and thus updating in different control periods) a more 
> elaborate testing scheme would be needed so that each analysis stream 
> can be tested independently of the other. It is too early in the morning 
> for me do do more than "leave this as an exercise"!
> 
> 
> 
> Richard Dobson
> 
> 
> 
> 
> ..
>>>>kflag   pvsftw    fsig1,ifn1
>>>>kflag1  pvsftw    fsig2,ifn2
>>>>
>>>>if      kflag==0   kgoto contin1   
>>>>
>>>>	vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>>>>	pvsftr      fsig1,ifncopy1
>>>>
>>>>
>>>>
>>>>if      kflag1==0   kgoto contin2  
>>>>
>>>>	vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>>>>	pvsftr    fsig2,ifncopy2
>>>>
> ..
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13360848
Sent from the Csound - General mailing list archive at Nabble.com.

I'd say if you use pvsbufread and pvsbuffer you would be able to make a
much simpler spectral delay, without the kr side-effect.

Victor

At 22:37 22/10/2007, you wrote:

>Hi,
>
>I have finally managed to put together a spectral delay instrument (sorry
>for the delay!). It is working ;-) but I can't work out why changing the
>control-rate or buffer size of csound, effects the delay time relatively
>(e.g. moving from ksmps=100 to 10 increases the delay time for every bin by
>over half!).
>
>This is I am sure as a result of the vecdelay opcode which I am using to
>delay different fft bins according to a function table. Am I doing something
>wrong though?
>
>Many Thanks
>Peiman
>
>PLEASE SEE BELLOW FOR CSD
>
>
>
>
>sr=44100
>ksmps=100
>nchnls=2
>
>instr 1
>ifndel      ftgen      0,0,512,-7, 1.9594594, 27.7113399506, 0.5135135651,
>69.9381408691, 0.2162162066, 108.2061843872, 0.6351351738, 306.1443481445,0
>ifn1         ftgen      0,0,1024,10,1        ; make ftable
>ifn2     ftgen      0,0,1024,10,1        ; make ftable
>ifncopy1     ftgen      0,0,1024,10,1        ; make ftable
>ifncopy2     ftgen      0,0,1024,10,1        ; make ftable
>
>
>ain1    diskin
>"/Library/Frameworks/CsoundLib.framework/Versions/5.1/Resources/Manual/examples/beats.aiff",
>1
>
>fsig1   pvsanal   ain1,1024,512/4,1024*2,1
>fsig2   pvsanal   ain1,1024,512/4,1024*2,1
>kflag   pvsftw    fsig1,ifn1
>kflag1  pvsftw    fsig2,ifn2
>
>if      kflag==0   kgoto contin1
>
>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>         pvsftr      fsig1,ifncopy1
>
>
>
>if      kflag1==0   kgoto contin2
>
>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>         pvsftr    fsig2,ifncopy2
>
>
>contin1:
>aout1   pvsynth fsig1
>ain1 delay ain1, (1024*2)/sr
>aout1 = aout1 + ain1
>
>contin2:
>aout2   pvsynth fsig2
>ain2 delay ain1, (1024*2)/sr
>aout2 = aout2 + ain1
>outs aout1, aout2
>endin
>
>
>
>
>
>
>
>i1 0 10
>
>
>e
>
>
>
>
>
>rory walsh wrote:
> >
> >  >1-spectral delay, where the amount of delay for individual bins is
> >  >defined in a function table (prefebally this would also include
> >  >feedback with control over the amount of feedback).
> >
> > If you have a simple example of what you describe above I would love to
> > see it, would you mind posting it?
> >
> > Rory.
> >
> >
> >
> > peiman wrote:
> >> Wow! this is amazing. Just what I was after :-)
> >>
> >>
> >> Victor Lazzarini wrote:
> >>> At 12:54 16/10/2007, you wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Following from yesterday's post, I have been wandering how to do the
> >>>> following operations in csound, using the pvs opcodes. After thinking
> >>>> for
> >>>> some hours about this I still cannot come up with an answer.
> >>>>
> >>>> 1-spectral delay, where the amount of delay for individual bins is
> >>>> defined
> >>>> in a function table (prefebally this would also include feedback with
> >>>> control over the amount of feedback).
> >>> Use the new opcodes pvsbuffer and pvsbufread
> >>>
> >>>
> >>>> 2-the ability to change the rate at which fft frames are updated so to
> >>>> average the time resolution of the input.
> >>> Also pvsbuffer and pvsbufread. These are the two prime target
> >>> operations for the new opcodes. Hope they do what you want.
> >>>
> >>> Victor
> >>>
> >>>
> >>>
> >>>> So in short I cannot work out how to do time-domain operations on pvs
> >>>> streams or fft bins.
> >>>>
> >>>> Any comments are very much welcome :-)
> >>>>
> >>>> Many Thanks
> >>>> Peiman
> >>>> --
> >>>> View this message in context:
> >>>> http://www.nabble.com/spectral-delay-tf4633685.html#a13231682
> >>>> Sent from the Csound - General mailing list archive at Nabble.com.
> >>>>
> >>>> --
> >>>> Send bugs reports to this list.
> >>>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >>> Victor Lazzarini
> >>> Music Technology Laboratory
> >>> Music Department
> >>> National University of Ireland, Maynooth
> >>>
> >>> --
> >>> Send bugs reports to this list.
> >>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >>>
> >>>
> >>
> > --
> > Send bugs reports to this list.
> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> >
>
>--
>View this message in context: 
>http://www.nabble.com/spectral-delay-tf4633685.html#a13352968
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
think there is a need for an extra vecdelay version.

Victor

At 10:33 23/10/2007, you wrote:
>peiman wrote:
>>No problems :-) I found the error:
>>Just delete the conditional (if) statements along with the corresponding
>>labels and the problem is gone!
>
>This is a slightly deceptive solution, but maybe inescapable at present 
>when combining vecdelay with the pvs routines. The use of the kflag test 
>is in principle correct, as a new analysis frame is only generated every 
>ten or so control cycles (depending on the ratio of ksmps to overlap); 
>putting it another way, this means the pvs control rate is somewhat lower 
>than a typical Csound kr. But vecdelay runs at the Csound kr (and of 
>course will be implemented on that basis internally), so in the absence of 
>the kflag controls, it wastefully overwrites the tables multiple times 
>before they are actually used by  pvsynth.  Which means there is still a 
>case for having a dedicated pvs version, one way or another.
>
>Also note that as written, when kflag activates, it jumps over  the code 
>associated with kflag1. In this case it is benign because the two signals 
>run at the same frame rate; I suspect that if they were different (and 
>thus updating in different control periods) a more elaborate testing 
>scheme would be needed so that each analysis stream can be tested 
>independently of the other. It is too early in the morning for me do do 
>more than "leave this as an exercise"!
>
>
>
>Richard Dobson
>
>
>
>
>..
>>>>kflag   pvsftw    fsig1,ifn1
>>>>kflag1  pvsftw    fsig2,ifn2
>>>>
>>>>if      kflag==0   kgoto contin1
>>>>
>>>>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>>>>         pvsftr      fsig1,ifncopy1
>>>>
>>>>
>>>>
>>>>if      kflag1==0   kgoto contin2
>>>>
>>>>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>>>>         pvsftr    fsig2,ifncopy2
>..
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

So that we are clear what I mean, here's a trivial
pvsbuffer example:






sr= 44100
ksmps = 64
nchnls= 2

instr 1

; signal generator
k1  phasor -0.5   ; envelope
k1  port k1, 0.01
asig  vco2 k1*16000,120 ; oscillator

; pvs bit
fsig1 pvsanal asig,1024,256,1024,1

;buffer
ibuf1,kt1  pvsbuffer fsig1,1
; 1st delayed signal from 0 to 1000 Hz delayed by 0.2 secs
fsig2 pvsbufread kt1-0.2, ibuf1, 0, 1000
; 2nd delayed signal from 750 to 5000 Hz delayed by 0.5 secs
fsig3 pvsbufread kt1-0.5, ibuf1, 750, 5000
; mix the two
fsig4 pvsmix fsig2, fsig3
; blur the mix
fsig5 pvsmooth fsig4, 0.05, 0.1
; output
adel  pvsynth fsig5

     outs asig*0.1, adel

endin






f1 0 16384 9 1 1

i1 0 5



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Victor Lazzarini wrote:
> pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
> think there is a need for an extra vecdelay version.
> 


I am ~still~ downloading the latest manual from CVS (so much of it!), so 
don't have the spec to hand. Does pvsbufread support varying the delay 
of individual bins (e.g. via an ftable)? I think that is what peiman is 
after (following in the footsteps of the Native Instrument "Spektral 
Delay" (which allowed you to draw an arbitrary delay envelope over the 
analysis bins) etc. Even a simple slope from low to high, so low bins 
are delayed (smoothed, gated, etc) more (or less) than high bins, say, 
can be very "interesting".


Richard Dobson

Correct me if I am wrong. I cannot find a way to control the delay for
individual bins with pvsbuf opcodes. Is this possible?

Thanks
Peiman


Victor Lazzarini wrote:
> 
> pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
> think there is a need for an extra vecdelay version.
> 
> Victor
> 
> At 10:33 23/10/2007, you wrote:
>>peiman wrote:
>>>No problems :-) I found the error:
>>>Just delete the conditional (if) statements along with the corresponding
>>>labels and the problem is gone!
>>
>>This is a slightly deceptive solution, but maybe inescapable at present 
>>when combining vecdelay with the pvs routines. The use of the kflag test 
>>is in principle correct, as a new analysis frame is only generated every 
>>ten or so control cycles (depending on the ratio of ksmps to overlap); 
>>putting it another way, this means the pvs control rate is somewhat lower 
>>than a typical Csound kr. But vecdelay runs at the Csound kr (and of 
>>course will be implemented on that basis internally), so in the absence of 
>>the kflag controls, it wastefully overwrites the tables multiple times 
>>before they are actually used by  pvsynth.  Which means there is still a 
>>case for having a dedicated pvs version, one way or another.
>>
>>Also note that as written, when kflag activates, it jumps over  the code 
>>associated with kflag1. In this case it is benign because the two signals 
>>run at the same frame rate; I suspect that if they were different (and 
>>thus updating in different control periods) a more elaborate testing 
>>scheme would be needed so that each analysis stream can be tested 
>>independently of the other. It is too early in the morning for me do do 
>>more than "leave this as an exercise"!
>>
>>
>>
>>Richard Dobson
>>
>>
>>
>>
>>..
>>>>>kflag   pvsftw    fsig1,ifn1
>>>>>kflag1  pvsftw    fsig2,ifn2
>>>>>
>>>>>if      kflag==0   kgoto contin1
>>>>>
>>>>>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>>>>>         pvsftr      fsig1,ifncopy1
>>>>>
>>>>>
>>>>>
>>>>>if      kflag1==0   kgoto contin2
>>>>>
>>>>>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>>>>>         pvsftr    fsig2,ifncopy2
>>..
>>
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13363041
Sent from the Csound - General mailing list archive at Nabble.com.

See my example.

At 13:18 23/10/2007, you wrote:

>Correct me if I am wrong. I cannot find a way to control the delay for
>individual bins with pvsbuf opcodes. Is this possible?
>
>Thanks
>Peiman
>
>
>Victor Lazzarini wrote:
> >
> > pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
> > think there is a need for an extra vecdelay version.
> >
> > Victor
> >
> > At 10:33 23/10/2007, you wrote:
> >>peiman wrote:
> >>>No problems :-) I found the error:
> >>>Just delete the conditional (if) statements along with the corresponding
> >>>labels and the problem is gone!
> >>
> >>This is a slightly deceptive solution, but maybe inescapable at present
> >>when combining vecdelay with the pvs routines. The use of the kflag test
> >>is in principle correct, as a new analysis frame is only generated every
> >>ten or so control cycles (depending on the ratio of ksmps to overlap);
> >>putting it another way, this means the pvs control rate is somewhat lower
> >>than a typical Csound kr. But vecdelay runs at the Csound kr (and of
> >>course will be implemented on that basis internally), so in the absence of
> >>the kflag controls, it wastefully overwrites the tables multiple times
> >>before they are actually used by  pvsynth.  Which means there is still a
> >>case for having a dedicated pvs version, one way or another.
> >>
> >>Also note that as written, when kflag activates, it jumps over  the code
> >>associated with kflag1. In this case it is benign because the two signals
> >>run at the same frame rate; I suspect that if they were different (and
> >>thus updating in different control periods) a more elaborate testing
> >>scheme would be needed so that each analysis stream can be tested
> >>independently of the other. It is too early in the morning for me do do
> >>more than "leave this as an exercise"!
> >>
> >>
> >>
> >>Richard Dobson
> >>
> >>
> >>
> >>
> >>..
> >>>>>kflag   pvsftw    fsig1,ifn1
> >>>>>kflag1  pvsftw    fsig2,ifn2
> >>>>>
> >>>>>if      kflag==0   kgoto contin1
> >>>>>
> >>>>>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
> >>>>>         pvsftr      fsig1,ifncopy1
> >>>>>
> >>>>>
> >>>>>
> >>>>>if      kflag1==0   kgoto contin2
> >>>>>
> >>>>>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
> >>>>>         pvsftr    fsig2,ifncopy2
> >>..
> >>
> >>--
> >>Send bugs reports to this list.
> >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> > Victor Lazzarini
> > Music Technology Laboratory
> > Music Department
> > National University of Ireland, Maynooth
> >
> > --
> > Send bugs reports to this list.
> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> >
>
>--
>View this message in context: 
>http://www.nabble.com/spectral-delay-tf4633685.html#a13363041
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

See the pages:
http://www.csounds.com/manual/html/pvsbuffer.html
http://www.csounds.com/manual/html/pvsbufread.html

By using several readers you can get different delays over
a range of frequencies.

Victor

At 12:50 23/10/2007, you wrote:
>Victor Lazzarini wrote:
>>pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
>>think there is a need for an extra vecdelay version.
>
>
>I am ~still~ downloading the latest manual from CVS (so much of it!), so 
>don't have the spec to hand. Does pvsbufread support varying the delay of 
>individual bins (e.g. via an ftable)? I think that is what peiman is after 
>(following in the footsteps of the Native Instrument "Spektral Delay" 
>(which allowed you to draw an arbitrary delay envelope over the analysis 
>bins) etc. Even a simple slope from low to high, so low bins are delayed 
>(smoothed, gated, etc) more (or less) than high bins, say, can be very 
>"interesting".
>
>
>Richard Dobson
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Thanks Victor,

Yes I see what you mean. However still this is more or less like filtering +
delay as opposed to arbitrarily delaying fft bins (as Richard mentioned)
independently from the actual frequencies. Also I am working with 512 delay
lines (one for each bin) and this can change easily with the fft-size (by
using the same variable). Using pvsbufread one needs to write an instance of
the opcode for every delay line which means writing 512 pvsburead lines. I
tried to this using loops but then the problem is that they need to be named
differently and csound doesn't allow that (to use the string opcodes to name
them doesn't work as the names end up  inside " "). Maybe an opcode to index
variable names would do the job? 

Thanks very much for the advice
Peiman

Victor Lazzarini wrote:
> 
> See my example.
> 
> At 13:18 23/10/2007, you wrote:
> 
>>Correct me if I am wrong. I cannot find a way to control the delay for
>>individual bins with pvsbuf opcodes. Is this possible?
>>
>>Thanks
>>Peiman
>>
>>
>>Victor Lazzarini wrote:
>> >
>> > pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
>> > think there is a need for an extra vecdelay version.
>> >
>> > Victor
>> >
>> > At 10:33 23/10/2007, you wrote:
>> >>peiman wrote:
>> >>>No problems :-) I found the error:
>> >>>Just delete the conditional (if) statements along with the
>> corresponding
>> >>>labels and the problem is gone!
>> >>
>> >>This is a slightly deceptive solution, but maybe inescapable at present
>> >>when combining vecdelay with the pvs routines. The use of the kflag
>> test
>> >>is in principle correct, as a new analysis frame is only generated
>> every
>> >>ten or so control cycles (depending on the ratio of ksmps to overlap);
>> >>putting it another way, this means the pvs control rate is somewhat
>> lower
>> >>than a typical Csound kr. But vecdelay runs at the Csound kr (and of
>> >>course will be implemented on that basis internally), so in the absence
>> of
>> >>the kflag controls, it wastefully overwrites the tables multiple times
>> >>before they are actually used by  pvsynth.  Which means there is still
>> a
>> >>case for having a dedicated pvs version, one way or another.
>> >>
>> >>Also note that as written, when kflag activates, it jumps over  the
>> code
>> >>associated with kflag1. In this case it is benign because the two
>> signals
>> >>run at the same frame rate; I suspect that if they were different (and
>> >>thus updating in different control periods) a more elaborate testing
>> >>scheme would be needed so that each analysis stream can be tested
>> >>independently of the other. It is too early in the morning for me do do
>> >>more than "leave this as an exercise"!
>> >>
>> >>
>> >>
>> >>Richard Dobson
>> >>
>> >>
>> >>
>> >>
>> >>..
>> >>>>>kflag   pvsftw    fsig1,ifn1
>> >>>>>kflag1  pvsftw    fsig2,ifn2
>> >>>>>
>> >>>>>if      kflag==0   kgoto contin1
>> >>>>>
>> >>>>>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
>> >>>>>         pvsftr      fsig1,ifncopy1
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>if      kflag1==0   kgoto contin2
>> >>>>>
>> >>>>>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
>> >>>>>         pvsftr    fsig2,ifncopy2
>> >>..
>> >>
>> >>--
>> >>Send bugs reports to this list.
>> >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> >
>> > Victor Lazzarini
>> > Music Technology Laboratory
>> > Music Department
>> > National University of Ireland, Maynooth
>> >
>> > --
>> > Send bugs reports to this list.
>> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> >
>> >
>>
>>--
>>View this message in context: 
>>http://www.nabble.com/spectral-delay-tf4633685.html#a13363041
>>Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13364711
Sent from the Csound - General mailing list archive at Nabble.com.

By slowing down the rate of read-back is one not just simply delaying the
contents of the bins?

>
> Correct me if I am wrong. I cannot find a way to control the delay for
> individual bins with pvsbuf opcodes. Is this possible?
>
> Thanks
> Peiman
>
>
> Victor Lazzarini wrote:

Yes but how do you delay each bin (as opposed to frequency region)? say you
have 512 bins then you would need 512 pvsbufread opcodes. But what if you
want to change the fft size? I see that pvsburead would be ideal for
spectral delay if there was a way to use it in a loop block.

Best
Peiman
  

rory walsh wrote:
> 
> By slowing down the rate of read-back is one not just simply delaying the
> contents of the bins?
> 
>>
>> Correct me if I am wrong. I cannot find a way to control the delay for
>> individual bins with pvsbuf opcodes. Is this possible?
>>
>> Thanks
>> Peiman
>>
>>
>> Victor Lazzarini wrote:
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13365405
Sent from the Csound - General mailing list archive at Nabble.com.

But the only difference is that I am setting the ranges in freqs not
bins (to make it simpler for the user); if you use the bin bandwith
+ cfreq, you can delay an individual bin.

Note that delaying each bin might sometimes be overkill. You can
of course have one instrument and 512 instances of it running
in parallel. Here's an example of what I mean. You only need
to add the i-statements for each read.







sr= 44100
ksmps = 256
nchnls= 2

gibuf init 0
gkt   init 0
gfmix pvsinit 1024

instr 1

asig  diskin2 "pianoc2.wav", 1,0,1
fsig1 pvsanal asig,1024,256,1024,1
gibuf,gkt  pvsbuffer fsig1,2

endin

instr 2

fsig pvsbufread gkt-p4,gibuf,p5,p6
; add the signal to the global bus
fmix pvsmix fsig, gfmix
; assignment is not working
; so we use pvsmix
gfmix pvsmix fmix, fmix
endin

instr 3
fzero pvsinit 1024
asig pvsynth gfmix
      outs asig, asig
; reset the global fsig
; actually we need an opcode for that!
gfmix pvsvoc gfmix,fzero, 0, 0
endin




f1 0 16384 9 1 1
f1 0 1024 -7  0.1 1024 1.9
i1 0 60
i2 0 60 .1  0     500
i2 0 60 .3 500    1000
i2 0 60 .3 1000    2000
i2 0 60 .5 2000    3000
i2 0 60 .7 4000    5000
i2 0 60 .9 5000    7000
i2 0 60 1.1 7000   20000
i3 0 60








At 14:50 23/10/2007, you wrote:

>Thanks Victor,
>
>Yes I see what you mean. However still this is more or less like filtering +
>delay as opposed to arbitrarily delaying fft bins (as Richard mentioned)
>independently from the actual frequencies. Also I am working with 512 delay
>lines (one for each bin) and this can change easily with the fft-size (by
>using the same variable). Using pvsbufread one needs to write an instance of
>the opcode for every delay line which means writing 512 pvsburead lines. I
>tried to this using loops but then the problem is that they need to be named
>differently and csound doesn't allow that (to use the string opcodes to name
>them doesn't work as the names end up  inside " "). Maybe an opcode to index
>variable names would do the job?
>
>Thanks very much for the advice
>Peiman
>
>Victor Lazzarini wrote:
> >
> > See my example.
> >
> > At 13:18 23/10/2007, you wrote:
> >
> >>Correct me if I am wrong. I cannot find a way to control the delay for
> >>individual bins with pvsbuf opcodes. Is this possible?
> >>
> >>Thanks
> >>Peiman
> >>
> >>
> >>Victor Lazzarini wrote:
> >> >
> >> > pvbsbuffer and pvsbufread implement  delay lines for f-sigs. I don't
> >> > think there is a need for an extra vecdelay version.
> >> >
> >> > Victor
> >> >
> >> > At 10:33 23/10/2007, you wrote:
> >> >>peiman wrote:
> >> >>>No problems :-) I found the error:
> >> >>>Just delete the conditional (if) statements along with the
> >> corresponding
> >> >>>labels and the problem is gone!
> >> >>
> >> >>This is a slightly deceptive solution, but maybe inescapable at present
> >> >>when combining vecdelay with the pvs routines. The use of the kflag
> >> test
> >> >>is in principle correct, as a new analysis frame is only generated
> >> every
> >> >>ten or so control cycles (depending on the ratio of ksmps to overlap);
> >> >>putting it another way, this means the pvs control rate is somewhat
> >> lower
> >> >>than a typical Csound kr. But vecdelay runs at the Csound kr (and of
> >> >>course will be implemented on that basis internally), so in the absence
> >> of
> >> >>the kflag controls, it wastefully overwrites the tables multiple times
> >> >>before they are actually used by  pvsynth.  Which means there is still
> >> a
> >> >>case for having a dedicated pvs version, one way or another.
> >> >>
> >> >>Also note that as written, when kflag activates, it jumps over  the
> >> code
> >> >>associated with kflag1. In this case it is benign because the two
> >> signals
> >> >>run at the same frame rate; I suspect that if they were different (and
> >> >>thus updating in different control periods) a more elaborate testing
> >> >>scheme would be needed so that each analysis stream can be tested
> >> >>independently of the other. It is too early in the morning for me do do
> >> >>more than "leave this as an exercise"!
> >> >>
> >> >>
> >> >>
> >> >>Richard Dobson
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>..
> >> >>>>>kflag   pvsftw    fsig1,ifn1
> >> >>>>>kflag1  pvsftw    fsig2,ifn2
> >> >>>>>
> >> >>>>>if      kflag==0   kgoto contin1
> >> >>>>>
> >> >>>>>         vecdelay    ifncopy1, ifn1, ifndel, 512, 20
> >> >>>>>         pvsftr      fsig1,ifncopy1
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>if      kflag1==0   kgoto contin2
> >> >>>>>
> >> >>>>>         vecdelay  ifncopy2, ifn2, ifndel, 512, 20
> >> >>>>>         pvsftr    fsig2,ifncopy2
> >> >>..
> >> >>
> >> >>--
> >> >>Send bugs reports to this list.
> >> >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >> >
> >> > Victor Lazzarini
> >> > Music Technology Laboratory
> >> > Music Department
> >> > National University of Ireland, Maynooth
> >> >
> >> > --
> >> > Send bugs reports to this list.
> >> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >> >
> >> >
> >>
> >>--
> >>View this message in context:
> >>http://www.nabble.com/spectral-delay-tf4633685.html#a13363041
> >>Sent from the Csound - General mailing list archive at Nabble.com.
> >>
> >>--
> >>Send bugs reports to this list.
> >>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> > Victor Lazzarini
> > Music Technology Laboratory
> > Music Department
> > National University of Ireland, Maynooth
> >
> > --
> > Send bugs reports to this list.
> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> >
>
>--
>View this message in context: 
>http://www.nabble.com/spectral-delay-tf4633685.html#a13364711
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

In fact, I have automated this now. A bit on the heavy processing
side though. But it does bin by bin, see:






sr= 44100
ksmps = 256
nchnls= 2

gibuf init 0
gkt   init 0
gfmix pvsinit 1024

instr 1

asig  diskin2 "pianoc2.wav", 1,0,1
fsig1 pvsanal asig,1024,256,1024,1
gibuf,gkt  pvsbuffer fsig1,6

endin

instr 2

fsig pvsbufread gkt-p4,gibuf,p5-p6,p6+p6
; add the signal to the global bus
fmix pvsmix fsig, gfmix
; assignment is not working
; so we use pvsmix
gfmix pvsmix fmix, fmix
print p5
endin

instr 3
fzero pvsinit 1024
asig pvsynth gfmix
      outs asig, asig
; reset the global fsig
; actually we need an opcode for that!
gfmix pvsvoc gfmix,fzero, 0, 0
endin

instr 4
kcf init 0
kcnt init 0
kdel init 0
even:
kcf = kcf+sr/1024
kdel = kdel+5/512
event "i",2,0,60,kdel,kcf,sr/512
kcnt = kcnt + 1
if kcnt < 512 kgoto even
turnoff
endin





f1 0 16384 9 1 1
i1 0 60
i4 0 1
i3 0 60





At 15:15 23/10/2007, you wrote:

>Yes but how do you delay each bin (as opposed to frequency region)? say you
>have 512 bins then you would need 512 pvsbufread opcodes. But what if you
>want to change the fft size? I see that pvsburead would be ideal for
>spectral delay if there was a way to use it in a loop block.
>
>Best
>Peiman
>
>
>rory walsh wrote:
> >
> > By slowing down the rate of read-back is one not just simply delaying the
> > contents of the bins?
> >
> >>
> >> Correct me if I am wrong. I cannot find a way to control the delay for
> >> individual bins with pvsbuf opcodes. Is this possible?
> >>
> >> Thanks
> >> Peiman
> >>
> >>
> >> Victor Lazzarini wrote:
> >
> > --
> > Send bugs reports to this list.
> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> >
> >
>
>--
>View this message in context: 
>http://www.nabble.com/spectral-delay-tf4633685.html#a13365405
>Sent from the Csound - General mailing list archive at Nabble.com.
>
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

Thanks Victor,
I am going to study this instrument to see what exactly is going on :-)

Thanks again for posting it
Best
Peiman


Victor Lazzarini wrote:
> 
> In fact, I have automated this now. A bit on the heavy processing
> side though. But it does bin by bin, see:
> 
> 
> 
> 
> 
> 
> sr= 44100
> ksmps = 256
> nchnls= 2
> 
> gibuf init 0
> gkt   init 0
> gfmix pvsinit 1024
> 
> instr 1
> 
> asig  diskin2 "pianoc2.wav", 1,0,1
> fsig1 pvsanal asig,1024,256,1024,1
> gibuf,gkt  pvsbuffer fsig1,6
> 
> endin
> 
> instr 2
> 
> fsig pvsbufread gkt-p4,gibuf,p5-p6,p6+p6
> ; add the signal to the global bus
> fmix pvsmix fsig, gfmix
> ; assignment is not working
> ; so we use pvsmix
> gfmix pvsmix fmix, fmix
> print p5
> endin
> 
> instr 3
> fzero pvsinit 1024
> asig pvsynth gfmix
>       outs asig, asig
> ; reset the global fsig
> ; actually we need an opcode for that!
> gfmix pvsvoc gfmix,fzero, 0, 0
> endin
> 
> instr 4
> kcf init 0
> kcnt init 0
> kdel init 0
> even:
> kcf = kcf+sr/1024
> kdel = kdel+5/512
> event "i",2,0,60,kdel,kcf,sr/512
> kcnt = kcnt + 1
> if kcnt < 512 kgoto even
> turnoff
> endin
> 
> 
> 
> 
> 
> f1 0 16384 9 1 1
> i1 0 60
> i4 0 1
> i3 0 60
> 
> 
> 
> 
> 
> At 15:15 23/10/2007, you wrote:
> 
>>Yes but how do you delay each bin (as opposed to frequency region)? say
you
>>have 512 bins then you would need 512 pvsbufread opcodes. But what if you
>>want to change the fft size? I see that pvsburead would be ideal for
>>spectral delay if there was a way to use it in a loop block.
>>
>>Best
>>Peiman
>>
>>
>>rory walsh wrote:
>> >
>> > By slowing down the rate of read-back is one not just simply delaying
>> the
>> > contents of the bins?
>> >
>> >>
>> >> Correct me if I am wrong. I cannot find a way to control the delay for
>> >> individual bins with pvsbuf opcodes. Is this possible?
>> >>
>> >> Thanks
>> >> Peiman
>> >>
>> >>
>> >> Victor Lazzarini wrote:
>> >
>> > --
>> > Send bugs reports to this list.
>> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> >
>> >
>>
>>--
>>View this message in context: 
>>http://www.nabble.com/spectral-delay-tf4633685.html#a13365405
>>Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>--
>>Send bugs reports to this list.
>>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13369360
Sent from the Csound - General mailing list archive at Nabble.com.

yet another variation, making bands a little larger (but they
can be as small as one bin). This one does not struggle
to run.

The delay time for each band is set by the function table.

I actually quite like the effect. Use any mono file you like.






sr= 44100
ksmps = 256
nchnls= 2

gibuf init 0
gkt   init 0
gfmix pvsinit 1024

instr 1

asig  diskin2 "jarrettm.wav", 1,0,1
fsig1 pvsanal asig,1024,256,1024,1
gibuf,gkt  pvsbuffer fsig1,10

endin

instr 2

fsig pvsbufread gkt-p4,gibuf,p5-p6,p6+p6
; add the signal to the global bus
fmix pvsmix fsig, gfmix
; assignment is not working
; so we use pvsmix
gfmix pvsmix fmix, fmix
print p5
endin

instr 3
fzero pvsinit 1024
asig pvsynth gfmix
      outs asig, asig
; reset the global fsig
; actually we need an opcode for that!
gfmix pvsvoc gfmix,fzero, 0, 0
endin

instr 4
kcf init 0
kcnt init 0
kdel init 0
ibands = 100
even:
kcf = kcf+sr/(ibands*2)
kdel tablei kcnt/ibands, 1, 1
event "i",2,0,p4,kdel,kcf,sr/ibands
kcnt = kcnt + 1
if kcnt < ibands kgoto even
turnoff
endin





f1 0 1024 -5  1.5 512 6 512 0.1
i1 0 30
i4 0 1 30
i3 0 30



Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth

How hard would it be to implement a pvsbufread with k-rate ilo and ihi 
arguments. I'm guessing not so easy otherwise you probably would have 
implemented it already?

Rory.

Victor Lazzarini wrote:
> In fact, I have automated this now. A bit on the heavy processing
> side though. But it does bin by bin, see:
> 
> 
> 
> 
> 
> 
> sr= 44100
> ksmps = 256
> nchnls= 2
> 
> gibuf init 0
> gkt   init 0
> gfmix pvsinit 1024
> 
> instr 1
> 
> asig  diskin2 "pianoc2.wav", 1,0,1
> fsig1 pvsanal asig,1024,256,1024,1
> gibuf,gkt  pvsbuffer fsig1,6
> 
> endin
> 
> instr 2
> 
> fsig pvsbufread gkt-p4,gibuf,p5-p6,p6+p6
> ; add the signal to the global bus
> fmix pvsmix fsig, gfmix
> ; assignment is not working
> ; so we use pvsmix
> gfmix pvsmix fmix, fmix
> print p5
> endin
> 
> instr 3
> fzero pvsinit 1024
> asig pvsynth gfmix
>      outs asig, asig
> ; reset the global fsig
> ; actually we need an opcode for that!
> gfmix pvsvoc gfmix,fzero, 0, 0
> endin
> 
> instr 4
> kcf init 0
> kcnt init 0
> kdel init 0
> even:
> kcf = kcf+sr/1024
> kdel = kdel+5/512
> event "i",2,0,60,kdel,kcf,sr/512
> kcnt = kcnt + 1
> if kcnt < 512 kgoto even
> turnoff
> endin
> 
> 
> 
> 
> 
> f1 0 16384 9 1 1
> i1 0 60
> i4 0 1
> i3 0 60
> 
> 
> 
> 
> 
> At 15:15 23/10/2007, you wrote:
> 
>> Yes but how do you delay each bin (as opposed to frequency region)? 
>> say you
>> have 512 bins then you would need 512 pvsbufread opcodes. But what if you
>> want to change the fft size? I see that pvsburead would be ideal for
>> spectral delay if there was a way to use it in a loop block.
>>
>> Best
>> Peiman
>>
>>
>> rory walsh wrote:
>> >
>> > By slowing down the rate of read-back is one not just simply 
>> delaying the
>> > contents of the bins?
>> >
>> >>
>> >> Correct me if I am wrong. I cannot find a way to control the delay for
>> >> individual bins with pvsbuf opcodes. Is this possible?
>> >>
>> >> Thanks
>> >> Peiman
>> >>
>> >>
>> >> Victor Lazzarini wrote:
>> >
>> > --
>> > Send bugs reports to this list.
>> > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>> >
>> >
>>
>> -- 
>> View this message in context: 
>> http://www.nabble.com/spectral-delay-tf4633685.html#a13365405
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>> -- 
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 

Thanks very much this is nice! and I think I know how it is working! 
Best  

Victor Lazzarini wrote:
> 
> yet another variation, making bands a little larger (but they
> can be as small as one bin). This one does not struggle
> to run.
> 
> The delay time for each band is set by the function table.
> 
> I actually quite like the effect. Use any mono file you like.
> 
> 
> 
> 
> 
> 
> sr= 44100
> ksmps = 256
> nchnls= 2
> 
> gibuf init 0
> gkt   init 0
> gfmix pvsinit 1024
> 
> instr 1
> 
> asig  diskin2 "jarrettm.wav", 1,0,1
> fsig1 pvsanal asig,1024,256,1024,1
> gibuf,gkt  pvsbuffer fsig1,10
> 
> endin
> 
> instr 2
> 
> fsig pvsbufread gkt-p4,gibuf,p5-p6,p6+p6
> ; add the signal to the global bus
> fmix pvsmix fsig, gfmix
> ; assignment is not working
> ; so we use pvsmix
> gfmix pvsmix fmix, fmix
> print p5
> endin
> 
> instr 3
> fzero pvsinit 1024
> asig pvsynth gfmix
>       outs asig, asig
> ; reset the global fsig
> ; actually we need an opcode for that!
> gfmix pvsvoc gfmix,fzero, 0, 0
> endin
> 
> instr 4
> kcf init 0
> kcnt init 0
> kdel init 0
> ibands = 100
> even:
> kcf = kcf+sr/(ibands*2)
> kdel tablei kcnt/ibands, 1, 1
> event "i",2,0,p4,kdel,kcf,sr/ibands
> kcnt = kcnt + 1
> if kcnt < ibands kgoto even
> turnoff
> endin
> 
> 
> 
> 
> 
> f1 0 1024 -5  1.5 512 6 512 0.1
> i1 0 30
> i4 0 1 30
> i3 0 30
> 
> 
> 
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
> 
> -- 
> Send bugs reports to this list.
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 
> 

-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13370086
Sent from the Csound - General mailing list archive at Nabble.com.

Here's another example. These opcodes are a lot of fun. I've been 
playing around with a mic for this one but a soundfile will work too...




-odevaudio -b64 -idevaudio


sr = 44100
ksmps = 1
nchnls = 2

instr 1
igain = 0.6

afdb1 init 0
afdb2 init 0
afdb3 init 0

asig inch 1
;asig soundin "D:/MyDocuments/csoundfiles/Old/Radiohead.wav"

k1 phasor 0.5

kdel1 randi 1, 0.5, 0.2
kdel2 randi 1, 1,   0.4
kdel3 randi 1, 1.5, 0.5

fsig1   pvsanal   asig+afdb1,1024, 512,1024,1
fsig2   pvsanal   asig+afdb2,1024, 512,1024,1
fsig3   pvsanal   asig+afdb3,1024, 512,1024,1

ibuf1,kt1   pvsbuffer   fsig1, 2
ibuf2,kt1   pvsbuffer   fsig2, 2
ibuf3,kt1   pvsbuffer   fsig3, 2

khan1 init ibuf1
khan2 init ibuf2
khan3 init ibuf3

fsb1  pvsbufread  k1-kdel1, khan1, 0, 2500
fsb2  pvsbufread  k1-kdel2, khan2, 2500, 7000
fsb3  pvsbufread  k1-kdel3, khan3, 7000, 18000

aout1  pvsynth   fsb1
aout2  pvsynth   fsb2
aout3  pvsynth   fsb3

afdb1 = (afdb1+aout1)*igain
afdb2 = (afdb2+aout2)*igain
afdb3 = (afdb3+aout3)*igain

aLeft = (afdb1*kdel1)+(afdb2*kdel2)+(afdb3*kdel3)
aRight = (afdb1*(1-kdel1))+(afdb2*(1-kdel2))+(afdb3*(1-kdel3))
outs aLeft, aRight

endin




f1 0 1024 10 1
i1 0 100

This example doesn't run on my system (Vista+csound 5.07 double 
precision). Segment violation!
I have tried other examples posted on the list and this is the same 
error. I have tried to comment lines for finding the culprit; and it 
seems to be pvsbufread.
CsOptions is -odac6 -b2048
I have tried with a wav file, and also using vco2. No way

jean-pierre

Rory Walsh a écrit :
> Here's another example. These opcodes are a lot of fun. I've been 
> playing around with a mic for this one but a soundfile will work too...
>
>
> 
> 
> -odevaudio -b64 -idevaudio
> 
> 
> sr = 44100
> ksmps = 1
> nchnls = 2
>
> instr 1
> igain = 0.6
>
> afdb1 init 0
> afdb2 init 0
> afdb3 init 0
>
> asig inch 1
> ;asig soundin "D:/MyDocuments/csoundfiles/Old/Radiohead.wav"
>
> k1 phasor 0.5
>
> kdel1 randi 1, 0.5, 0.2
> kdel2 randi 1, 1,   0.4
> kdel3 randi 1, 1.5, 0.5
>
> fsig1   pvsanal   asig+afdb1,1024, 512,1024,1
> fsig2   pvsanal   asig+afdb2,1024, 512,1024,1
> fsig3   pvsanal   asig+afdb3,1024, 512,1024,1
>
> ibuf1,kt1   pvsbuffer   fsig1, 2
> ibuf2,kt1   pvsbuffer   fsig2, 2
> ibuf3,kt1   pvsbuffer   fsig3, 2
>
> khan1 init ibuf1
> khan2 init ibuf2
> khan3 init ibuf3
>
> fsb1  pvsbufread  k1-kdel1, khan1, 0, 2500
> fsb2  pvsbufread  k1-kdel2, khan2, 2500, 7000
> fsb3  pvsbufread  k1-kdel3, khan3, 7000, 18000
>
> aout1  pvsynth   fsb1
> aout2  pvsynth   fsb2
> aout3  pvsynth   fsb3
>
> afdb1 = (afdb1+aout1)*igain
> afdb2 = (afdb2+aout2)*igain
> afdb3 = (afdb3+aout3)*igain
>
> aLeft = (afdb1*kdel1)+(afdb2*kdel2)+(afdb3*kdel3)
> aRight = (afdb1*(1-kdel1))+(afdb2*(1-kdel2))+(afdb3*(1-kdel3))
> outs aLeft, aRight
>
> endin
>
>
> 
> 
> f1 0 1024 10 1
> i1 0 100
> 
> 

That's strange. I am using the latest build from the CVS, float 
precision, winxp and it runs fine, so does Victor's sample?

Jean-Pierre Lemoine wrote:
> This example doesn't run on my system (Vista+csound 5.07 double 
> precision). Segment violation!
> I have tried other examples posted on the list and this is the same 
> error. I have tried to comment lines for finding the culprit; and it 
> seems to be pvsbufread.
> CsOptions is -odac6 -b2048
> I have tried with a wav file, and also using vco2. No way
> 
> jean-pierre
> 
> Rory Walsh a écrit :
>> Here's another example. These opcodes are a lot of fun. I've been 
>> playing around with a mic for this one but a soundfile will work too...
>>
>>
>> 
>> 
>> -odevaudio -b64 -idevaudio
>> 
>> 
>> sr = 44100
>> ksmps = 1
>> nchnls = 2
>>
>> instr 1
>> igain = 0.6
>>
>> afdb1 init 0
>> afdb2 init 0
>> afdb3 init 0
>>
>> asig inch 1
>> ;asig soundin "D:/MyDocuments/csoundfiles/Old/Radiohead.wav"
>>
>> k1 phasor 0.5
>>
>> kdel1 randi 1, 0.5, 0.2
>> kdel2 randi 1, 1,   0.4
>> kdel3 randi 1, 1.5, 0.5
>>
>> fsig1   pvsanal   asig+afdb1,1024, 512,1024,1
>> fsig2   pvsanal   asig+afdb2,1024, 512,1024,1
>> fsig3   pvsanal   asig+afdb3,1024, 512,1024,1
>>
>> ibuf1,kt1   pvsbuffer   fsig1, 2
>> ibuf2,kt1   pvsbuffer   fsig2, 2
>> ibuf3,kt1   pvsbuffer   fsig3, 2
>>
>> khan1 init ibuf1
>> khan2 init ibuf2
>> khan3 init ibuf3
>>
>> fsb1  pvsbufread  k1-kdel1, khan1, 0, 2500
>> fsb2  pvsbufread  k1-kdel2, khan2, 2500, 7000
>> fsb3  pvsbufread  k1-kdel3, khan3, 7000, 18000
>>
>> aout1  pvsynth   fsb1
>> aout2  pvsynth   fsb2
>> aout3  pvsynth   fsb3
>>
>> afdb1 = (afdb1+aout1)*igain
>> afdb2 = (afdb2+aout2)*igain
>> afdb3 = (afdb3+aout3)*igain
>>
>> aLeft = (afdb1*kdel1)+(afdb2*kdel2)+(afdb3*kdel3)
>> aRight = (afdb1*(1-kdel1))+(afdb2*(1-kdel2))+(afdb3*(1-kdel3))
>> outs aLeft, aRight
>>
>> endin
>>
>>
>> 
>> 
>> f1 0 1024 10 1
>> i1 0 100
>> 
>> 
> 
> 
> 

I have done more tests,
fsb1  pvsbufread  0, khan1, 0, 2500 -> segment violation
fsb1  pvsbufread  2.1, khan1, 0, 2500 -> no violation, but out of range 
samples

jean-pierre

Steven Yi a écrit :
> I got a Segmentation Violation here on WinXP.  Latest compiled from
> CVS but for double precision.  Perhaps there is a hardcoaded float
> somewhere?
>
> On 10/23/07, Rory Walsh  wrote:
>   
>> That's strange. I am using the latest build from the CVS, float
>> precision, winxp and it runs fine, so does Victor's sample?
>>
>> Jean-Pierre Lemoine wrote:
>>     
>>> This example doesn't run on my system (Vista+csound 5.07 double
>>> precision). Segment violation!
>>> I have tried other examples posted on the list and this is the same
>>> error. I have tried to comment lines for finding the culprit; and it
>>> seems to be pvsbufread.
>>> CsOptions is -odac6 -b2048
>>> I have tried with a wav file, and also using vco2. No way
>>>
>>> jean-pierre
>>>
>>> Rory Walsh a écrit :
>>>       
>>>> Here's another example. These opcodes are a lot of fun. I've been
>>>> playing around with a mic for this one but a soundfile will work too...
>>>>
>>>>
>>>> 
>>>> 
>>>> -odevaudio -b64 -idevaudio
>>>> 
>>>> 
>>>> sr = 44100
>>>> ksmps = 1
>>>> nchnls = 2
>>>>
>>>> instr 1
>>>> igain = 0.6
>>>>
>>>> afdb1 init 0
>>>> afdb2 init 0
>>>> afdb3 init 0
>>>>
>>>> asig inch 1
>>>> ;asig soundin "D:/MyDocuments/csoundfiles/Old/Radiohead.wav"
>>>>
>>>> k1 phasor 0.5
>>>>
>>>> kdel1 randi 1, 0.5, 0.2
>>>> kdel2 randi 1, 1,   0.4
>>>> kdel3 randi 1, 1.5, 0.5
>>>>
>>>> fsig1   pvsanal   asig+afdb1,1024, 512,1024,1
>>>> fsig2   pvsanal   asig+afdb2,1024, 512,1024,1
>>>> fsig3   pvsanal   asig+afdb3,1024, 512,1024,1
>>>>
>>>> ibuf1,kt1   pvsbuffer   fsig1, 2
>>>> ibuf2,kt1   pvsbuffer   fsig2, 2
>>>> ibuf3,kt1   pvsbuffer   fsig3, 2
>>>>
>>>> khan1 init ibuf1
>>>> khan2 init ibuf2
>>>> khan3 init ibuf3
>>>>
>>>> fsb1  pvsbufread  k1-kdel1, khan1, 0, 2500
>>>> fsb2  pvsbufread  k1-kdel2, khan2, 2500, 7000
>>>> fsb3  pvsbufread  k1-kdel3, khan3, 7000, 18000
>>>>
>>>> aout1  pvsynth   fsb1
>>>> aout2  pvsynth   fsb2
>>>> aout3  pvsynth   fsb3
>>>>
>>>> afdb1 = (afdb1+aout1)*igain
>>>> afdb2 = (afdb2+aout2)*igain
>>>> afdb3 = (afdb3+aout3)*igain
>>>>
>>>> aLeft = (afdb1*kdel1)+(afdb2*kdel2)+(afdb3*kdel3)
>>>> aRight = (afdb1*(1-kdel1))+(afdb2*(1-kdel2))+(afdb3*(1-kdel3))
>>>> outs aLeft, aRight
>>>>
>>>> endin
>>>>
>>>>
>>>> 
>>>> 
>>>> f1 0 1024 10 1
>>>> i1 0 100
>>>> 
>>>> 
>>>>         
>>>
>>>       
>> --
>> Send bugs reports to this list.
>> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
>>
>>     

My god, you go to sleep & you wake up & the csound list has spiralled into
carnage! ; )

I have to concur with Richard Dobson here - certainly my expectations of
what a "spectral delay" is all about would be something along the lines of a
"vecdelay" (what i had always intended to try & use before these latest
opcodes came along) - 1 ftable bin proving delay time for its corresponding
analysis bin range. ditto feedback. just like the n*tive *nstruments
"model".

if it was simply a question of returning individual fsig streams delayed by
different amounts, then surely you could split the fsig into ranges using
pvsmaska (or any similar) & then just delay the various (& now multiple)
asig streams?

there is certainly no rush on my part. still on 5.06 & increasingly looking
like i might stay that way for the moment...

there is no ingratitude or malice on my part. just another observation from
someone who likes to hear the sound of his own keyboard clacking....



-- 
View this message in context: http://www.nabble.com/spectral-delay-tf4633685.html#a13376210
Sent from the Csound - General mailing list archive at Nabble.com.

Hum...   My first attempt says

SECTION 1:
ftable 1:
new alloc for instr 1:
 *** internal error: mcalloc() called with zero nbytes
Csound tidy up: Segmentation fault
inactive allocs returned to freespace
end of score.              overall amps:      0.0      0.0
           overall samples out of range:        0        0
0 errors in performance

Second attempt under gdb is worse....

SECTION 1:
ftable 1:
new alloc for instr 1:
 *** internal error: mcalloc() called with zero nbytes
 *** internal error: mcalloc() called with zero nbytes
INIT ERROR in instr 1: invalid window type
aout1   pvsynth fsb1    0
 *** internal error: mcalloc() called with zero nbytes
INIT ERROR in instr 1: invalid window type
aout2   pvsynth fsb2    0
          B  0.000 - note deleted.  i1 had 2 init errors

Seems as if something is very wrong somewhere!
==John ffitch

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net