Hi Alex,
You can use ftconv to enable having the IR as audio in a table.
I recently made a simple "live sample convolver" with it, where you
can record an IR on the fly and then immediately start convolving live
input with it.
I've speculated on how to "slide" the IR too, to continuously update
it. Haven't landed on a solution for this yet, guess you could keep
several simultaneous convolvers running and crossfade between them,
sort of like a "granular convolver".
best
Oeyvind

2011/3/24 Alex Weiss :
> Hi folks,
> I've been a quiet reader of this list for a while, but I do have a question
> now that I cannot solve on my own. Most of my sound design and music
> involves heavy use of convolution (pconvolve), as it's one of the most
> powerful techniques out there, I believe. But there is one limiting factor:
> while I can change and modulate the sound to be convoluted to my liking, the
> IR is always static in that I can't change it. What I'd love to do is to
> find a way to have the IR change continuously (but slowly) over time. I
> assume one way to do this would be to generate and output a new IR wave file
> at k-rate before calls to pconvolve. But that seems prohibitive in terms of
> performance overhead. Additionally, I don't even know if it would work at
> all, as the entire sound file would have to be generated during a single
> k-cycle, which means that I'd have to find a way to split one cycle up into
> multiple "subcycles." I'm probably not very clear on this, but I hope you
> understand what I mean.
>
> How hard would it be to modify the pconvolve opcode to read the IR from a
> table instead of a file? I believe this might be a solution...
> Thanks,
> Alex


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

If you have the cpu to generate multiple cycles in one k pass, you can use kgoto looping over a tabw and a phasor and whatever opcodes are generating the audio, as long as you do not rely on state of signals outside of that loop, you should be able to do multiple loops through in one actual k cycle. Something like:

kcount init 0
fill_table:
asig oscil kamp, kcps, 1
; isecs is the length of the table in seconds
kwrite phasor 1/isecs
kidx   = kwrite*isecs*sr
      tablew asig, kwrite, 2
kcount = icount + ksmps
if (kcount < isecs*sr) then kgoto fill_table


that is pseudo code, but it should be a start. The phases for the phasor and oscil should update each time the code passes through the block and it therefore fill the table properly (and I think most other opcodes should too if you are not using globals?).

Also, regarding a vs. k cycle, a and k cycles are the same thing, they are just different kinds of data storage, if I understand correctly (an "a" signal is a vector containing ksmps samples, the control flow goes through the opcodes, generates one new value for each "k" expression per cycle, and updates each "a" vector via its respective opcode)

Alex Weiss wrote:
> Hi Olivier,
> 
> yeah, I remember that example from a while back. That's really cool and
> getting even closer to what I want to do. Thanks for reminding me about
> ftmorf. But ultimately, what I want to do is to be able to generate the IR
> through regular synthesis opcodes and not just table morphing; I was
> envisioning sort of a "blackbox" (I assume an UDO or instrument would work)
> that behaves much like a regular instrument and can contain any number and
> possibilities of synthesis techniques, but saves the result to a table and
> does the entire computation during one a- or k-cycle.
> 
> Alex
> 
> 2011/3/24 Olivier Bélanger 
> 
>> Hi Alex,
>>
>> If you take a look at the module "DirectConvolve.cec" in Cecilia 4, I do
>> live convolution with a table updating at k-rate with "vcopy" and "ftmorf".
>> It works great!
>>
>> Olivier
>>
>>
>> 2011/3/24 Alex Weiss 
>>
>>> Hi Oeyvind,
>>>
>>> I didn't know about fconv, thanks for telling me about that. Sounds very
>>> promising. But there's still one problem to solve: if I want the IR to
>>> change continuously, I need to update/change the entire table at either a-
>>> or k-rate. If the table itself is the result of synthesis/modifications
>>> through opcodes, I need a way to squeeze the entire synthesis for all
>>> samples in the table into a single a- or k-rate. Is something like that even
>>> remotely possible?
>>>
>>> I do have another, slightly related question for the csound developers: Do
>>> opcodes that have file input implement their own file handling routines, or
>>> do they all use the same internal utility routines provided by csound? If
>>> it's the latter, how hard would it be to implement a way that lets the user
>>> define some "dummy" soundfile name and link it to a table? That way all
>>> opcodes that read from files could also read from tables, which might make
>>> some opcodes more powerful while maintaining compatibility. Just asking...
>>> :)
>>>
>>> Alex
>>>
>>>
>>> On Thu, Mar 24, 2011 at 11:57 AM, Oeyvind Brandtsegg <
>>> oyvind.brandtsegg@ntnu.no> wrote:
>>>
>>>> Hi Alex,
>>>> You can use ftconv to enable having the IR as audio in a table.
>>>> I recently made a simple "live sample convolver" with it, where you
>>>> can record an IR on the fly and then immediately start convolving live
>>>> input with it.
>>>> I've speculated on how to "slide" the IR too, to continuously update
>>>> it. Haven't landed on a solution for this yet, guess you could keep
>>>> several simultaneous convolvers running and crossfade between them,
>>>> sort of like a "granular convolver".
>>>> best
>>>> Oeyvind
>>>>
>>>> 2011/3/24 Alex Weiss :
>>>>> Hi folks,
>>>>> I've been a quiet reader of this list for a while, but I do have a
>>>> question
>>>>> now that I cannot solve on my own. Most of my sound design and music
>>>>> involves heavy use of convolution (pconvolve), as it's one of the most
>>>>> powerful techniques out there, I believe. But there is one limiting
>>>> factor:
>>>>> while I can change and modulate the sound to be convoluted to my
>>>> liking, the
>>>>> IR is always static in that I can't change it. What I'd love to do is
>>>> to
>>>>> find a way to have the IR change continuously (but slowly) over time. I
>>>>> assume one way to do this would be to generate and output a new IR wave
>>>> file
>>>>> at k-rate before calls to pconvolve. But that seems prohibitive in
>>>> terms of
>>>>> performance overhead. Additionally, I don't even know if it would work
>>>> at
>>>>> all, as the entire sound file would have to be generated during a
>>>> single
>>>>> k-cycle, which means that I'd have to find a way to split one cycle up
>>>> into
>>>>> multiple "subcycles." I'm probably not very clear on this, but I hope
>>>> you
>>>>> understand what I mean.
>>>>>
>>>>> How hard would it be to modify the pconvolve opcode to read the IR from
>>>> a
>>>>> table instead of a file? I believe this might be a solution...
>>>>> Thanks,
>>>>> Alex
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Yes this sounds similar to what I had in mind. I'll see if I can get
Soundhack running on one of our lab computers and listen to what it
sounds like.
Thanks for the tip, I was not aware of this feature in Soundhack
Oeyvind


2011/3/25 thorin kerr :
> Oeyvind... sounds a bit like the Soundhack 'moving window' convolution.
> The manual describes it, maybe it'll give you some ideas.
> http://soundhack.com/SndHckDoc/EditConv.html#(Command - C) Convolution...
> Tk
>
>
> On Fri, Mar 25, 2011 at 4:57 AM, Oeyvind Brandtsegg
>  wrote:
>>
>> Hi Alex,
>> You can use ftconv to enable having the IR as audio in a table.
>> I recently made a simple "live sample convolver" with it, where you
>> can record an IR on the fly and then immediately start convolving live
>> input with it.
>> I've speculated on how to "slide" the IR too, to continuously update
>> it. Haven't landed on a solution for this yet, guess you could keep
>> several simultaneous convolvers running and crossfade between them,
>> sort of like a "granular convolver".
>> best
>> Oeyvind
>>
>> 2011/3/24 Alex Weiss :
>> > Hi folks,
>> > I've been a quiet reader of this list for a while, but I do have a
>> > question
>> > now that I cannot solve on my own. Most of my sound design and music
>> > involves heavy use of convolution (pconvolve), as it's one of the most
>> > powerful techniques out there, I believe. But there is one limiting
>> > factor:
>> > while I can change and modulate the sound to be convoluted to my liking,
>> > the
>> > IR is always static in that I can't change it. What I'd love to do is to
>> > find a way to have the IR change continuously (but slowly) over time. I
>> > assume one way to do this would be to generate and output a new IR wave
>> > file
>> > at k-rate before calls to pconvolve. But that seems prohibitive in terms
>> > of
>> > performance overhead. Additionally, I don't even know if it would work
>> > at
>> > all, as the entire sound file would have to be generated during a single
>> > k-cycle, which means that I'd have to find a way to split one cycle up
>> > into
>> > multiple "subcycles." I'm probably not very clear on this, but I hope
>> > you
>> > understand what I mean.
>> >
>> > How hard would it be to modify the pconvolve opcode to read the IR from
>> > a
>> > table instead of a file? I believe this might be a solution...
>> > Thanks,
>> > Alex
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 25/03/2011 09:53, Oeyvind Brandtsegg wrote:
> Yes this sounds similar to what I had in mind. I'll see if I can get
> Soundhack running on one of our lab computers and listen to what it
> sounds like.
> Thanks for the tip, I was not aware of this feature in Soundhack
> Oeyvind
>
>


Ther is a caveat to make here - in pvoc-style processes like Soundhack, 
while there is convolution done per analysis frame, giving the idea of 
time-varying impulse responses, the price generally paid for that is 
that it is circular convolution (output is the same number of samples as 
the input) rather than the strictly linear convolution of reverb 
algorithms. In the latter, if the input frame is X samples, and the IR 
is Y samples, the output frame is (X+Y)-1 samples (i.e. the same as a 
FIR filter output). The vast majority of pvocs do not do this, and 
suffer the audio consequences of circular convolution, a "time-aliased" 
output. Of course what then happens is that the composer says "hey 
that's a cool sound!", and just carries on.

I have read of at least one high-end reverb system (or equally, a 
linear-phase filter bank) that does implement time-variable FIR impulse 
responses, but it is a very complex affair to do (you cannot expect a 
sudden change to have no glitchy audio consequences), and those systems 
are not cheap!

Richard Dobson



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks for the insight into this, Richard.

Is there a method to do both types of convolution in Csound, so we
could listen to and compare the results ?
I find it much easier to remember (and understand) these things when
hearing how it sounds.

best
Oeyvind

2011/3/25 Richard Dobson :
> On 25/03/2011 09:53, Oeyvind Brandtsegg wrote:
>>
>> Yes this sounds similar to what I had in mind. I'll see if I can get
>> Soundhack running on one of our lab computers and listen to what it
>> sounds like.
>> Thanks for the tip, I was not aware of this feature in Soundhack
>> Oeyvind
>>
>>
>
>
> Ther is a caveat to make here - in pvoc-style processes like Soundhack,
> while there is convolution done per analysis frame, giving the idea of
> time-varying impulse responses, the price generally paid for that is that it
> is circular convolution (output is the same number of samples as the input)
> rather than the strictly linear convolution of reverb algorithms. In the
> latter, if the input frame is X samples, and the IR is Y samples, the output
> frame is (X+Y)-1 samples (i.e. the same as a FIR filter output). The vast
> majority of pvocs do not do this, and suffer the audio consequences of
> circular convolution, a "time-aliased" output. Of course what then happens
> is that the composer says "hey that's a cool sound!", and just carries on.
>
> I have read of at least one high-end reverb system (or equally, a
> linear-phase filter bank) that does implement time-variable FIR impulse
> responses, but it is a very complex affair to do (you cannot expect a sudden
> change to have no glitchy audio consequences), and those systems are not
> cheap!
>
> Richard Dobson
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 25/03/2011 11:27, Oeyvind Brandtsegg wrote:
> Thanks for the insight into this, Richard.
>
> Is there a method to do both types of convolution in Csound, so we
> could listen to and compare the results ?
> I find it much easier to remember (and understand) these things when
> hearing how it sounds.
>
> best
> Oeyvind
>


That's a very good question, and very worthy of an experimental setup. 
In principle, it is a matter of comparing reverb-style convolution with, 
say, a streaming pvoc where the FFT of the impulse response (without any 
zero-padding) is multiplied with the streaming analysis frames of the 
source. I don't want to suggest that the effects are either extreme or 
obvious - this is largely a theoretical issue, and I am always a little 
surprised at just how well radical pvoc tricks such as zeroing bins 
works. A reverb impulse repsonse in any case might not the the best one 
to try, simply because the end of it by definition is relatively 
low-level and easily masked.

Theory says that if you zero, say, the upper set of bins in a pvoc frame 
(with a view to making it a maximally "brick-wall" filter) the 
time-domain impulse response is infinitely long (i.e. you need an 
extremely long FIR filter to achieve that rate of attenuation). So one 
route would be to compare a tightly defined brick-wall filter 
(high-order FIR) with the "naive' pvoc counterpart. The snag here from 
Csound's point of view is that that FIR filter needs to be properly 
designed (using techniques such as Parks-McLellan, Remez, etc), and 
AFAIK we do not have such a facility in Csound. There are external FIR 
design tools around (some even free, there is code kicking about for 
both algorithms), they tend to fail when very long lengths are requested 
- even N=1024 is too much for some tools.

So setting up such a comparison will unfortunately take a bit of doing.

One short-cut method might be simply to compare the literal brick-wall 
filter technique in pvs (directly zeroing the upper 75% of bins, say) 
with the same procedure where a non-zero slope is used (so what is left 
is like half of a trapezium). In theory, that reduces the impulse 
response length to something much more plausible in terms of correct FIR 
behaviour (while, sadly, still not actually the same - we need curves 
rather than straight lines in such things). What you are trying to do is 
reduce the time-domain ringing that would be the consequence of the 
literal brick-wall procedure. The source would need to be chosen so as 
to sufficiently highlight that effect. Part of the problem here is that 
it may well still sound pretty acceptable, at least to the casual ear, 
simply because we are used to recursive filters which have a more or 
less peaky resonant peak at the cut-off frequency. The true FIR filter 
will sound perfectly clean and "colourless" (which is one reason they 
are favoured in audio mastering), while the pvoc version will "make 
sense", but sound somewhat thicker, muddier, generally more "colourful" 
etc. A full-bandwidth (but band-limited) square wave could be a good 
test signal.

I will finally note here that a convolution opcode such as convolve is 
in principle entirely general, and not confined to use with (long) 
reverb impulse responses. It is just as appropriate to use it to 
implement, say, a linear-phase filter-bank, or any other standard FIR 
filter. That leave unaddressed the issue of the IR design, but once you 
have the IR, applying it to pconvolve would be entirely correct and 
appropriate.

So, looking aheead, there could be a case for adding a new utility to 
Csound to generate a proper FIR filter response from a specification; 
but this would be a non-trivial project!

Richard Dobson








Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hopefully you will indulge me in checking if I have understood this correctly.
(and apologies if this is too OT)

If we have two simple signals like this
1: [1 2 3]
2: [1 2 3 2 1]

With circular convolution, the output would be [7 9 14 14 10],
according to http://www.edaboard.com/thread180754.html.

With normal direct convolution we would get [3  8 14 14 10  4  1],
based on the nromal method (hopefully the text alignment is not too
messed up by the email client):
x1	         1   2   3   2  1
x2	    2   4   6   4   2
x3 	3  6   9   6   3
output	3  8 14 14 10  4  1

... so the normal convolution has a tail,
and this tail is "tied in" and added to the beginning of the signal
when we do circular convolution.

Is it correct to say that with non-circular convolution, this tail
would be added to the next frame of the signal (keeping the tail where
it really belongs),
but with circular convolution each frame's tail is wrapped up on itself?

best
Oeyvind


2011/3/25 Richard Dobson :
> On 25/03/2011 11:27, Oeyvind Brandtsegg wrote:
>>
>> Thanks for the insight into this, Richard.
>>
>> Is there a method to do both types of convolution in Csound, so we
>> could listen to and compare the results ?
>> I find it much easier to remember (and understand) these things when
>> hearing how it sounds.
>>
>> best
>> Oeyvind
>>
>
>
> That's a very good question, and very worthy of an experimental setup. In
> principle, it is a matter of comparing reverb-style convolution with, say, a
> streaming pvoc where the FFT of the impulse response (without any
> zero-padding) is multiplied with the streaming analysis frames of the
> source. I don't want to suggest that the effects are either extreme or
> obvious - this is largely a theoretical issue, and I am always a little
> surprised at just how well radical pvoc tricks such as zeroing bins works. A
> reverb impulse repsonse in any case might not the the best one to try,
> simply because the end of it by definition is relatively low-level and
> easily masked.
>
> Theory says that if you zero, say, the upper set of bins in a pvoc frame
> (with a view to making it a maximally "brick-wall" filter) the time-domain
> impulse response is infinitely long (i.e. you need an extremely long FIR
> filter to achieve that rate of attenuation). So one route would be to
> compare a tightly defined brick-wall filter (high-order FIR) with the
> "naive' pvoc counterpart. The snag here from Csound's point of view is that
> that FIR filter needs to be properly designed (using techniques such as
> Parks-McLellan, Remez, etc), and AFAIK we do not have such a facility in
> Csound. There are external FIR design tools around (some even free, there is
> code kicking about for both algorithms), they tend to fail when very long
> lengths are requested - even N=1024 is too much for some tools.
>
> So setting up such a comparison will unfortunately take a bit of doing.
>
> One short-cut method might be simply to compare the literal brick-wall
> filter technique in pvs (directly zeroing the upper 75% of bins, say) with
> the same procedure where a non-zero slope is used (so what is left is like
> half of a trapezium). In theory, that reduces the impulse response length to
> something much more plausible in terms of correct FIR behaviour (while,
> sadly, still not actually the same - we need curves rather than straight
> lines in such things). What you are trying to do is reduce the time-domain
> ringing that would be the consequence of the literal brick-wall procedure.
> The source would need to be chosen so as to sufficiently highlight that
> effect. Part of the problem here is that it may well still sound pretty
> acceptable, at least to the casual ear, simply because we are used to
> recursive filters which have a more or less peaky resonant peak at the
> cut-off frequency. The true FIR filter will sound perfectly clean and
> "colourless" (which is one reason they are favoured in audio mastering),
> while the pvoc version will "make sense", but sound somewhat thicker,
> muddier, generally more "colourful" etc. A full-bandwidth (but band-limited)
> square wave could be a good test signal.
>
> I will finally note here that a convolution opcode such as convolve is in
> principle entirely general, and not confined to use with (long) reverb
> impulse responses. It is just as appropriate to use it to implement, say, a
> linear-phase filter-bank, or any other standard FIR filter. That leave
> unaddressed the issue of the IR design, but once you have the IR, applying
> it to pconvolve would be entirely correct and appropriate.
>
> So, looking aheead, there could be a case for adding a new utility to Csound
> to generate a proper FIR filter response from a specification; but this
> would be a non-trivial project!
>
> Richard Dobson
>
>
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Looks about right to me - that is a handy web page.

To complete the picture, it is always helpful to look mat what the FIR 
filter equivalent does on an input stream - the first thing that comes 
out is the internal state, which to begin with is all zeroes; then the 
"heart" of the convolution, and finally the "tail" which is the IR 
scaled by the final sample.


On a technical note - in a sense all fast convolution of this kind is 
circular convolution (e.g it always ends up being one FFT frame 
multiplied with another of the same size), it is just that by 
zero-padding the data (both the input and the IR) the pesky wrap-around 
bits get discarded, to give the final correct "direct" convolution 
output. The two main classes of block-based convolution (overlap-add and 
overlap-save) manage the zero-padding and summing in slightly different 
ways (overlap-add being the more common, I think), based on discarding 
either the head or the tail, but of course the output is the same. This 
page has some handy pictures:

http://cnx.org/content/m12022/latest/


Richard Dobson


On 25/03/2011 13:46, Oeyvind Brandtsegg wrote:
> Hopefully you will indulge me in checking if I have understood this correctly.
> (and apologies if this is too OT)
>
> If we have two simple signals like this
> 1: [1 2 3]
> 2: [1 2 3 2 1]
>
> With circular convolution, the output would be [7 9 14 14 10],
> according to http://www.edaboard.com/thread180754.html.
>
> With normal direct convolution we would get [3  8 14 14 10  4  1],
> based on the nromal method (hopefully the text alignment is not too
> messed up by the email client):
> x1	         1   2   3   2  1
> x2	    2   4   6   4   2
> x3 	3  6   9   6   3
> output	3  8 14 14 10  4  1
>
> ... so the normal convolution has a tail,
> and this tail is "tied in" and added to the beginning of the signal
> when we do circular convolution.
>
> Is it correct to say that with non-circular convolution, this tail
> would be added to the next frame of the signal (keeping the tail where
> it really belongs),
> but with circular convolution each frame's tail is wrapped up on itself?
>
> best
> Oeyvind
>




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"