Hi all, I would like to bring to your attention a problem that arose during my experiments with Digital Waveguide Synthesis in Csound.

This is the typical structure of a simplified digital waveguide model (I hope you can see it with the right formatting):

                
excitat. ----> (+) ----------------------------------+---> output
signal          ^                                    |
                |                                  __v__
                |                                 |DELAY|
                |                                 |LINE |
                |                                 |_____|
                |    ______              ______      |
                +---|FLTR n|<-- ... <---|FLTR 1|<----+
                    |______|            |______|


We have an excitation signal that is needed only at first to populate the delay line, then we have potentially "n" filters in cascade to make all the variations we need to shape the sound as we want (and maybe some fractional corrections to the pitch).

This is all perfectly doable in Csound language, but some problems arise when you use the opcodes delayr/delayw:

opcode myWaveGuide, a, ai
    aExc,   \       ; excitation signal
    iDelDur xin     ; lenght of the delay line in seconds

    aDlyd   delayr  iDelDur

    aFltrd  filter1 aDlyd
    aFltrd  filter2 aFltrd
            ...
    aFltrd  filterN aFltrd        

    aOut    =       aExc + aFltrd
            delayw  aOut

            xout    aOut
endop

(Note that in the example above, for the sake of clarity, I used more variables of what I really needed)

What is the problem here? The problem is that the delayr opcode requires a delay line length no smaller than 1/kr = 1/(sr/ksmps). This is a problem because it means that you could have to lower the UDO ksmps (with setksmps) and, consequently, you could have to lower the real-time performance of your opcode.

For example, I'm trying to create a synth for 88-keys midi keyboards, and to let Csound generate notes up to the last key of such keyboards, the UDO ksmps value has to be no greater than 10 (if you have a standard sr=44100). In the above code, a ksmps value of 10 could be overkill for the performance, because it affects greatly the max polyphony you can achieve in real-time. In my experiments, I found that a ksmps=256 at the beginning of the orchestra code can speed up very much my waveguide opcode, at the point that for my needs I could avoid writing the opcode directly in C, because the performance would be already acceptable. But with that ksmps value (256), I could play only the first 2 octaves (+ other 5 keys) of the midi keyboard, because the limitation of the delayr opcode. An 88-keys keyboard has 7 octaves (+ 4 more keys: 3 in the low register and 1 at the top)...

Of course, if I implement the above opcode directly in C, the problem would disappear (and I could achieve max computation speed), but then I should implement in the C opcode the behaviour of all the n filters too... So, if I could avoid it, I would be a little happier... :-D

Do you think there could be other solutions?

Best regards,
Mauro

Hi Victor, from the link you mentioned yourself:

delayw writes asig into the delay area established by the preceding delayr unit. Viewed as a pair, these two units permit the formation of modified feedback loops, etc. However, there is a lower bound on the value of idlt, which must be at least 1 control period (or 1/kr).

This means that the minimum delay of delayr/w depends on the value of ksmps (or, eventually, the modified setksmps inside the UDO).

For example if you have ksmps=256 (and sr=44100) for the orchestra code, from the manual, the minimum delay value permitted for delayr/w is 1/kr = 1/(sr/ksmps) = 0.00580498866213... seconds => 172.265625 Hz. This means that the UDO in my previous email cannot generate a note with a fundamental frequency higher than 172.265625 Hz if I don't lower the global ksmps (or use setksmps with a value < 256 inside the UDO itself).

If I use other opcodes like 'delay' or 'vdelay', they don't have this limit, so I don't have to lower the ksmps to generate high frequency notes, but unfortunately I cannot use them for delay lines with modified feedback (which are needed in the digital waveguide method)...

If you are asking me why I don't want to lower the ksmps (or use, inside my UDO, setksmps with a value lower than the global ksmps) the answer is obvious: the lower the ksmps, the worse the max polyphony for real-time performance.

Il 2018-04-21 21:41 Victor Lazzarini ha scritto:

The minimum delay with delayr/w is 1 ksmps.

That is indicated in the manual.

 

http://csound.com/docs/manual/delayw.html

 

if you need a 1-sample delay, then you will have to set ksmps to 1.

 

This is also discussed in the physical models chapter of the Csound springer book.

 

Victor 

 

On 21 Apr 2018, at 20:20, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi all, I would like to bring to your attention a problem that arose during my experiments with Digital Waveguide Synthesis in Csound.

This is the typical structure of a simplified digital waveguide model (I hope you can see it with the right formatting):

                
excitat. ----> (+) ----------------------------------+---> output
signal          ^                                    |
                |                                  __v__
                |                                 |DELAY|
                |                                 |LINE |
                |                                 |_____|
                |    ______              ______      |
                +---|FLTR n|<-- ... <---|FLTR 1|<----+
                    |______|            |______|


We have an excitation signal that is needed only at first to populate the delay line, then we have potentially "n" filters in cascade to make all the variations we need to shape the sound as we want (and maybe some fractional corrections to the pitch).

This is all perfectly doable in Csound language, but some problems arise when you use the opcodes delayr/delayw:

opcode myWaveGuide, a, ai
    aExc,   \       ; excitation signal
    iDelDur xin     ; lenght of the delay line in seconds

    aDlyd   delayr  iDelDur

    aFltrd  filter1 aDlyd
    aFltrd  filter2 aFltrd
            ...
    aFltrd  filterN aFltrd        

    aOut    =       aExc + aFltrd
            delayw  aOut

            xout    aOut
endop

(Note that in the example above, for the sake of clarity, I used more variables of what I really needed)

What is the problem here? The problem is that the delayr opcode requires a delay line length no smaller than 1/kr = 1/(sr/ksmps). This is a problem because it means that you could have to lower the UDO ksmps (with setksmps) and, consequently, you could have to lower the real-time performance of your opcode.

For example, I'm trying to create a synth for 88-keys midi keyboards, and to let Csound generate notes up to the last key of such keyboards, the UDO ksmps value has to be no greater than 10 (if you have a standard sr=44100). In the above code, a ksmps value of 10 could be overkill for the performance, because it affects greatly the max polyphony you can achieve in real-time. In my experiments, I found that a ksmps=256 at the beginning of the orchestra code can speed up very much my waveguide opcode, at the point that for my needs I could avoid writing the opcode directly in C, because the performance would be already acceptable. But with that ksmps value (256), I could play only the first 2 octaves (+ other 5 keys) of the midi keyboard, because the limitation of the delayr opcode. An 88-keys keyboard has 7 octaves (+ 4 more keys: 3 in the low register and 1 at the top)...

Of course, if I implement the above opcode directly in C, the problem would disappear (and I could achieve max computation speed), but then I should implement in the C opcode the behaviour of all the n filters too... So, if I could avoid it, I would be a little happier... :-D

Do you think there could be other solutions?

Best regards,
Mauro

 

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Hi Victor, honestly I don't know how other similar systems work, being that Csound is the first music language I learned until now (and I learned it from only a few months), so I'm sorry if I ask trivial questions, but I will be glad if you help me to understand better:

when you say:
"If you need a 1-sample delay, the DSP vector needs to be 1"

I think this is true only if you need to use delay lines with modified feedback (like in the case of digital waveguide methods), right?

I'm asking this because in a basic feedforward comb filter, for example, the following code works always perfectly, regardless of the value you have for the global ksmps:

opcode fcomb, a, aii
    aIn,    \
    iDelDur,\
    ia      xin
            
    aPhsd   delay   aIn, iDelDur
    aIn     =       (aIn + ia * aPhsd) / 2
    
            xout    aIn        
endop

Regards,
Mauro

Il 2018-04-22 00:31 Victor Lazzarini ha scritto:

I am not asking that, I am just pointing out

that this is the normal operation of the

system (in fact this is how any similar

system, not only Csound, works).

 

If you need a 1-sample delay, the DSP

vector needs to be 1. That's all. 

Victor Lazzarini

 

On 21 Apr 2018, at 22:59, Mauro Giubileo wrote:

Hi Victor, from the link you mentioned yourself:

delayw writes asig into the delay area established by the preceding delayr unit. Viewed as a pair, these two units permit the formation of modified feedback loops, etc. However, there is a lower bound on the value of idlt, which must be at least 1 control period (or 1/kr).

This means that the minimum delay of delayr/w depends on the value of ksmps (or, eventually, the modified setksmps inside the UDO).

For example if you have ksmps=256 (and sr=44100) for the orchestra code, from the manual, the minimum delay value permitted for delayr/w is 1/kr = 1/(sr/ksmps) = 0.00580498866213... seconds => 172.265625 Hz. This means that the UDO in my previous email cannot generate a note with a fundamental frequency higher than 172.265625 Hz if I don't lower the global ksmps (or use setksmps with a value < 256 inside the UDO itself).

If I use other opcodes like 'delay' or 'vdelay', they don't have this limit, so I don't have to lower the ksmps to generate high frequency notes, but unfortunately I cannot use them for delay lines with modified feedback (which are needed in the digital waveguide method)...

If you are asking me why I don't want to lower the ksmps (or use, inside my UDO, setksmps with a value lower than the global ksmps) the answer is obvious: the lower the ksmps, the worse the max polyphony for real-time performance.

Regards,

Mauro

Il 2018-04-21 21:41 Victor Lazzarini ha scritto:

The minimum delay with delayr/w is 1 ksmps.

That is indicated in the manual.

 

http://csound.com/docs/manual/delayw.html

 

if you need a 1-sample delay, then you will have to set ksmps to 1.

 

This is also discussed in the physical models chapter of the Csound springer book.

 

Victor 

 

On 21 Apr 2018, at 20:20, Mauro Giubileo wrote:

Hi all, I would like to bring to your attention a problem that arose during my experiments with Digital Waveguide Synthesis in Csound.

This is the typical structure of a simplified digital waveguide model (I hope you can see it with the right formatting):

                
excitat. ----> (+) ----------------------------------+---> output
signal          ^                                    |
                |                                  __v__
                |                                 |DELAY|
                |                                 |LINE |
                |                                 |_____|
                |    ______              ______      |
                +---|FLTR n|<-- ... <---|FLTR 1|<----+
                    |______|            |______|


We have an excitation signal that is needed only at first to populate the delay line, then we have potentially "n" filters in cascade to make all the variations we need to shape the sound as we want (and maybe some fractional corrections to the pitch).

This is all perfectly doable in Csound language, but some problems arise when you use the opcodes delayr/delayw:

opcode myWaveGuide, a, ai
    aExc,   \       ; excitation signal
    iDelDur xin     ; lenght of the delay line in seconds

    aDlyd   delayr  iDelDur

    aFltrd  filter1 aDlyd
    aFltrd  filter2 aFltrd
            ...
    aFltrd  filterN aFltrd        

    aOut    =       aExc + aFltrd
            delayw  aOut

            xout    aOut
endop

(Note that in the example above, for the sake of clarity, I used more variables of what I really needed)

What is the problem here? The problem is that the delayr opcode requires a delay line length no smaller than 1/kr = 1/(sr/ksmps). This is a problem because it means that you could have to lower the UDO ksmps (with setksmps) and, consequently, you could have to lower the real-time performance of your opcode.

For example, I'm trying to create a synth for 88-keys midi keyboards, and to let Csound generate notes up to the last key of such keyboards, the UDO ksmps value has to be no greater than 10 (if you have a standard sr=44100). In the above code, a ksmps value of 10 could be overkill for the performance, because it affects greatly the max polyphony you can achieve in real-time. In my experiments, I found that a ksmps=256 at the beginning of the orchestra code can speed up very much my waveguide opcode, at the point that for my needs I could avoid writing the opcode directly in C, because the performance would be already acceptable. But with that ksmps value (256), I could play only the first 2 octaves (+ other 5 keys) of the midi keyboard, because the limitation of the delayr opcode. An 88-keys keyboard has 7 octaves (+ 4 more keys: 3 in the low register and 1 at the top)...

Of course, if I implement the above opcode directly in C, the problem would disappear (and I could achieve max computation speed), but then I should implement in the C opcode the behaviour of all the n filters too... So, if I could avoid it, I would be a little happier... :-D

Do you think there could be other solutions?

Best regards,
Mauro

 

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Yes, actually I'm trying to get acceptable (for my needs) performance directly in Csound without writing C opcodes, but I think this is possible only up to a certain extent. Anyway it's fun to try to optimize my Csound scripts, and I'm learning much things of the Csound system in doing it. ;-)

I think I will continue to experiment only with Csound code and then, when I'm satisfied with the sound I get, I will try to convert the UDOs that need setksmps=1 to C opcodes, to boost the performance.

I checked wgpluck, pluck, repluck, wguide, etc.,  but unfortunately I need something more generic and flexible for my needs (like in the diagram from my first email for this topic).

Best regards,
Mauro

Il 2018-04-22 00:33 John ff ha scritto:

If you care seriously about performance then writing in C is the way to go. You might look at wgpluck and repluck as well....

Sent from Blue

On 21 Apr 2018, at 23:00, Mauro Giubileo <mgiubileo@computeraltafed.it> wrote:

Hi Victor, from the link you mentioned yourself:

delayw writes asig into the delay area established by the preceding delayr unit. Viewed as a pair, these two units permit the formation of modified feedback loops, etc. However, there is a lower bound on the value of idlt, which must be at least 1 control period (or 1/kr).

This means that the minimum delay of delayr/w depends on the value of ksmps (or, eventually, the modified setksmps inside the UDO).

For example if you have ksmps=256 (and sr=44100) for the orchestra code, from the manual, the minimum delay value permitted for delayr/w is 1/kr = 1/(sr/ksmps) = 0.00580498866213... seconds => 172.265625 Hz. This means that the UDO in my previous email cannot generate a note with a fundamental frequency higher than 172.265625 Hz if I don't lower the global ksmps (or use setksmps with a value < 256 inside the UDO itself).

If I use other opcodes like 'delay' or 'vdelay', they don't have this limit, so I don't have to lower the ksmps to generate high frequency notes, but unfortunately I cannot use them for delay lines with modified feedback (which are needed in the digital waveguide method)...

If you are asking me why I don't want to lower the ksmps (or use, inside my UDO, setksmps with a value lower than the global ksmps) the answer is obvious: the lower the ksmps, the worse the max polyphony for real-time performance.

Regards,

Mauro

Il 2018-04-21 21:41 Victor Lazzarini ha scritto:

The minimum delay with delayr/w is 1 ksmps.

That is indicated in the manual.

 

http://csound.com/docs/manual/delayw.html

 

if you need a 1-sample delay, then you will have to set ksmps to 1.

 

This is also discussed in the physical models chapter of the Csound springer book.

 

Victor 

 

On 21 Apr 2018, at 20:20, Mauro Giubileo < mgiubileo@COMPUTERALTAFED.IT> wrote:

Hi all, I would like to bring to your attention a problem that arose during my experiments with Digital Waveguide Synthesis in Csound.

This is the typical structure of a simplified digital waveguide model (I hope you can see it with the right formatting):

                
excitat. ----> (+) ----------------------------------+---> output
signal          ^                                    |
                |                                  __v__
                |                                 |DELAY|
                |                                 |LINE |
                |                                 |_____|
                |    ______              ______      |
                +---|FLTR n|<-- ... <---|FLTR 1|<----+
                    |______|            |______|


We have an excitation signal that is needed only at first to populate the delay line, then we have potentially "n" filters in cascade to make all the variations we need to shape the sound as we want (and maybe some fractional corrections to the pitch).

This is all perfectly doable in Csound language, but some problems arise when you use the opcodes delayr/delayw:

opcode myWaveGuide, a, ai
    aExc,   \       ; excitation signal
    iDelDur xin     ; lenght of the delay line in seconds

    aDlyd   delayr  iDelDur

    aFltrd  filter1 aDlyd
    aFltrd  filter2 aFltrd
            ...
    aFltrd  filterN aFltrd        

    aOut    =       aExc + aFltrd
            delayw  aOut

            xout    aOut
endop

(Note that in the example above, for the sake of clarity, I used more variables of what I really needed)

What is the problem here? The problem is that the delayr opcode requires a delay line length no smaller than 1/kr = 1/(sr/ksmps). This is a problem because it means that you could have to lower the UDO ksmps (with setksmps) and, consequently, you could have to lower the real-time performance of your opcode.

For example, I'm trying to create a synth for 88-keys midi keyboards, and to let Csound generate notes up to the last key of such keyboards, the UDO ksmps value has to be no greater than 10 (if you have a standard sr=44100). In the above code, a ksmps value of 10 could be overkill for the performance, because it affects greatly the max polyphony you can achieve in real-time. In my experiments, I found that a ksmps=256 at the beginning of the orchestra code can speed up very much my waveguide opcode, at the point that for my needs I could avoid writing the opcode directly in C, because the performance would be already acceptable. But with that ksmps value (256), I could play only the first 2 octaves (+ other 5 keys) of the midi keyboard, because the limitation of the delayr opcode. An 88-keys keyboard has 7 octaves (+ 4 more keys: 3 in the low register and 1 at the top)...

Of course, if I implement the above opcode directly in C, the problem would disappear (and I could achieve max computation speed), but then I should implement in the C opcode the behaviour of all the n filters too... So, if I could avoid it, I would be a little happier... :-D

Do you think there could be other solutions?

Best regards,
Mauro

 

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here