Hello everyone,
I am a newbie Csound user and altough initially I had some trouble understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm beginning to appreciate their flexibility.

However, being that I'm doing research in the field of digital waveguide sound synthesis, I encountered some performance problems because I often need to create UDOs that work sample-by-sample (ksmps=1) which obviously slows down the execution of Csound code, especially if there are many voices in polyphony. Another thing that I think slows down the UDOs is the passage of a-rate parameters "by copy" rather than "by reference" but unfortunately Csound currently doesn't allow passage by reference (right?).
So, I would like to convert in C some of my experimental UDOs and I wonder, in this regard, if the following documents are still valid for the latest stable Csound version or maybe they are obsolete:

http://csounds.com/articles/Extensions_to_Csound.pdf

http://floss.booktype.pro/csound/extending-csound/

Finally, I would like to know if it's possible to call an existing C opcode from within a new opcode written in C. For example, let's suppose you want to convert into a C opcode the following UDO:

opcode test, a, ai
    aSignal,   \
    iCutoff    xin
    aFiltered  tone    aSignal, iCutoff
    aSignal    =       (aSignal + aFiltered) * 0.5
               xout    aSignal
endop

should I re-implement "tone" in my C code, or could I call the existing Csound tone opcode from within my new C opcode function? And, if it's possible, how could I do that in a clean way?

Best regards,
Mauro

Csound does not make it easy to re-use existing native opcode
functions from new opcodes. In theory this is possible, but I have not
heard of anyone doing it. To make it work, I think you would have to
(a) #include the existing opcode header files, and either (b)(i) link
with the existing opcode library (if it is a plugin), or (ii) obtain
pointers to the existing opcode functions either as named symbols (for
statically linked opcodes) or using csoundOpenLibrary and
csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
have to make your new opcode manage the existing opcode instance
lifecycle the same way that Csound itself does, and this is the hard
part (allocating the opcode, running the init pass, etc.).

Alternatively, you could use an existing C/C++ DSP library in your
opcode. Some of these are header file only libraries. I list some
examples here (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
but there are surely many more. I think this would be much simpler.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
 wrote:
> Hello everyone,
> I am a newbie Csound user and altough initially I had some trouble
> understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
> beginning to appreciate their flexibility.
>
> However, being that I'm doing research in the field of digital waveguide
> sound synthesis, I encountered some performance problems because I often
> need to create UDOs that work sample-by-sample (ksmps=1) which obviously
> slows down the execution of Csound code, especially if there are many voices
> in polyphony. Another thing that I think slows down the UDOs is the passage
> of a-rate parameters "by copy" rather than "by reference" but unfortunately
> Csound currently doesn't allow passage by reference (right?).
> So, I would like to convert in C some of my experimental UDOs and I wonder,
> in this regard, if the following documents are still valid for the latest
> stable Csound version or maybe they are obsolete:
>
> http://csounds.com/articles/Extensions_to_Csound.pdf
>
> http://floss.booktype.pro/csound/extending-csound/
>
>
> Finally, I would like to know if it's possible to call an existing C opcode
> from within a new opcode written in C. For example, let's suppose you want
> to convert into a C opcode the following UDO:
>
> opcode test, a, ai
>     aSignal,   \
>     iCutoff    xin
>     aFiltered  tone    aSignal, iCutoff
>     aSignal    =       (aSignal + aFiltered) * 0.5
>                xout    aSignal
> endop
>
> should I re-implement "tone" in my C code, or could I call the existing
> Csound tone opcode from within my new C opcode function? And, if it's
> possible, how could I do that in a clean way?
>
> 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

and what steven showed about implicit a[] loops might also be a solution 
for some cases:

EXAMPLE 03A19_Sample_by_sample_processing.csd   in
http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/

and

EXAMPLE 03G14_UDO_zdf_svf.csd in
http://write.flossmanuals.net/csound/g-user-defined-opcodes/

	
	joachim



On 19/04/18 22:10, Rory Walsh wrote:
> Regarding ksmps, UDOs can have their own ksmps independent of the main
> ksmps. No need to slow down the entire orchestra.
>
> On Thu 19 Apr 2018, 20:33 Michael Gogins,  > wrote:
>
>     Csound does not make it easy to re-use existing native opcode
>     functions from new opcodes. In theory this is possible, but I have not
>     heard of anyone doing it. To make it work, I think you would have to
>     (a) #include the existing opcode header files, and either (b)(i) link
>     with the existing opcode library (if it is a plugin), or (ii) obtain
>     pointers to the existing opcode functions either as named symbols (for
>     statically linked opcodes) or using csoundOpenLibrary and
>     csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
>     have to make your new opcode manage the existing opcode instance
>     lifecycle the same way that Csound itself does, and this is the hard
>     part (allocating the opcode, running the init pass, etc.).
>
>     Alternatively, you could use an existing C/C++ DSP library in your
>     opcode. Some of these are header file only libraries. I list some
>     examples here
>     (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
>     but there are surely many more. I think this would be much simpler.
>
>     Regards,
>     Mike
>
>
>
>
>     -----------------------------------------------------
>     Michael Gogins
>     Irreducible Productions
>     http://michaelgogins.tumblr.com
>     Michael dot Gogins at gmail dot com
>
>
>     On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
>     >
>     wrote:
>     > Hello everyone,
>     > I am a newbie Csound user and altough initially I had some trouble
>     > understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
>     > beginning to appreciate their flexibility.
>     >
>     > However, being that I'm doing research in the field of digital
>     waveguide
>     > sound synthesis, I encountered some performance problems because I
>     often
>     > need to create UDOs that work sample-by-sample (ksmps=1) which
>     obviously
>     > slows down the execution of Csound code, especially if there are
>     many voices
>     > in polyphony. Another thing that I think slows down the UDOs is
>     the passage
>     > of a-rate parameters "by copy" rather than "by reference" but
>     unfortunately
>     > Csound currently doesn't allow passage by reference (right?).
>     > So, I would like to convert in C some of my experimental UDOs and
>     I wonder,
>     > in this regard, if the following documents are still valid for the
>     latest
>     > stable Csound version or maybe they are obsolete:
>     >
>     > http://csounds.com/articles/Extensions_to_Csound.pdf
>     >
>     > http://floss.booktype.pro/csound/extending-csound/
>     >
>     >
>     > Finally, I would like to know if it's possible to call an existing
>     C opcode
>     > from within a new opcode written in C. For example, let's suppose
>     you want
>     > to convert into a C opcode the following UDO:
>     >
>     > opcode test, a, ai
>     >     aSignal,   \
>     >     iCutoff    xin
>     >     aFiltered  tone    aSignal, iCutoff
>     >     aSignal    =       (aSignal + aFiltered) * 0.5
>     >                xout    aSignal
>     > endop
>     >
>     > should I re-implement "tone" in my C code, or could I call the
>     existing
>     > Csound tone opcode from within my new C opcode function? And, if it's
>     > possible, how could I do that in a clean way?
>     >
>     > 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

Il 2018-04-19 21:33 Michael Gogins ha scritto:

Csound does not make it easy to re-use existing native opcode
functions from new opcodes. In theory this is possible, but I have not
heard of anyone doing it. To make it work, I think you would have to
(a) #include the existing opcode header files, and either (b)(i) link
with the existing opcode library (if it is a plugin), or (ii) obtain
pointers to the existing opcode functions either as named symbols (for
statically linked opcodes) or using csoundOpenLibrary and
csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
have to make your new opcode manage the existing opcode instance
lifecycle the same way that Csound itself does, and this is the hard
part (allocating the opcode, running the init pass, etc.).

Alternatively, you could use an existing C/C++ DSP library in your
opcode. Some of these are header file only libraries. I list some
examples here (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
but there are surely many more. I think this would be much simpler.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

Hello everyone,
I am a newbie Csound user and altough initially I had some trouble
understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
beginning to appreciate their flexibility.

However, being that I'm doing research in the field of digital waveguide
sound synthesis, I encountered some performance problems because I often
need to create UDOs that work sample-by-sample (ksmps=1) which obviously
slows down the execution of Csound code, especially if there are many voices
in polyphony. Another thing that I think slows down the UDOs is the passage
of a-rate parameters "by copy" rather than "by reference" but unfortunately
Csound currently doesn't allow passage by reference (right?).
So, I would like to convert in C some of my experimental UDOs and I wonder,
in this regard, if the following documents are still valid for the latest
stable Csound version or maybe they are obsolete:

http://csounds.com/articles/Extensions_to_Csound.pdf

http://floss.booktype.pro/csound/extending-csound/


Finally, I would like to know if it's possible to call an existing C opcode
from within a new opcode written in C. For example, let's suppose you want
to convert into a C opcode the following UDO:

opcode test, a, ai
    aSignal,   \
    iCutoff    xin
    aFiltered  tone    aSignal, iCutoff
    aSignal    =       (aSignal + aFiltered) * 0.5
               xout    aSignal
endop

should I re-implement "tone" in my C code, or could I call the existing
Csound tone opcode from within my new C opcode function? And, if it's
possible, how could I do that in a clean way?

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

Yes, I already know that, and in fact I use the instruction "setksmps=1" only in the UDOs where is necessary. For example, you need setksmps=1, inside an UDO, to make an accurate feedback comb filter. The problem is that in my experiments with digital waveguide synthesis most of the processing time is spent in these UDOs, so if there isn't already an a-time Csound opcode that does exactly what you want, the UDO version will slow down very much the real-time execution and your max polyphony will suffer. Another problem that I already mentioned is that passing a-time parameters by value (xin and xout opcodes inside an UDO) when the opcode could work directly on the input vectors, I think could badly affect max polyphony. From what I understand, if I write a Csound plugin, the parameters of the C opcodes are always passed by reference, so this is another important advantage in real-time performances.

Best regards,
Mauro

Il 2018-04-19 22:10 Rory Walsh ha scritto:

Regarding ksmps, UDOs can have their own ksmps independent of the main ksmps. No need to slow down the entire orchestra. 

On Thu 19 Apr 2018, 20:33 Michael Gogins, <michael.gogins@gmail.com> wrote:

Csound does not make it easy to re-use existing native opcode
functions from new opcodes. In theory this is possible, but I have not
heard of anyone doing it. To make it work, I think you would have to
(a) #include the existing opcode header files, and either (b)(i) link
with the existing opcode library (if it is a plugin), or (ii) obtain
pointers to the existing opcode functions either as named symbols (for
statically linked opcodes) or using csoundOpenLibrary and
csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
have to make your new opcode manage the existing opcode instance
lifecycle the same way that Csound itself does, and this is the hard
part (allocating the opcode, running the init pass, etc.).

Alternatively, you could use an existing C/C++ DSP library in your
opcode. Some of these are header file only libraries. I list some
examples here (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
but there are surely many more. I think this would be much simpler.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:
> Hello everyone,
> I am a newbie Csound user and altough initially I had some trouble
> understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
> beginning to appreciate their flexibility.
>
> However, being that I'm doing research in the field of digital waveguide
> sound synthesis, I encountered some performance problems because I often
> need to create UDOs that work sample-by-sample (ksmps=1) which obviously
> slows down the execution of Csound code, especially if there are many voices
> in polyphony. Another thing that I think slows down the UDOs is the passage
> of a-rate parameters "by copy" rather than "by reference" but unfortunately
> Csound currently doesn't allow passage by reference (right?).
> So, I would like to convert in C some of my experimental UDOs and I wonder,
> in this regard, if the following documents are still valid for the latest
> stable Csound version or maybe they are obsolete:
>
> http://csounds.com/articles/Extensions_to_Csound.pdf
>
> http://floss.booktype.pro/csound/extending-csound/
>
>
> Finally, I would like to know if it's possible to call an existing C opcode
> from within a new opcode written in C. For example, let's suppose you want
> to convert into a C opcode the following UDO:
>
> opcode test, a, ai
>     aSignal,   \
>     iCutoff    xin
>     aFiltered  tone    aSignal, iCutoff
>     aSignal    =       (aSignal + aFiltered) * 0.5
>                xout    aSignal
> endop
>
> should I re-implement "tone" in my C code, or could I call the existing
> Csound tone opcode from within my new C opcode function? And, if it's
> possible, how could I do that in a clean way?
>
> 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

That is not the goal of the API (to allow reuse). Also, you are probably confusing the host API, which is
the Csound API proper, with the support for adding new opcodes to the system (which may be seen 
as a subset thereof, but it is actually a separate element). That basically provides a mechanism for you to 
register your C code with the engine so that you can write Csound code using them (then if you are writing 
Csound code there is plenty of opportunities to reuse components). Note that this is a standard way
most music programming languages work (providing a mechanism to add unit generators without actually
providing a whole library of DSP C/C++ functions/etc for this purpose).

You also might want to look at the Csound collection of opcodes to see if there is not something that
already does the job that you are wanting to do.

Also, as Rory said, you can write Csound UDOs or instruments that use a local ksmps values of 1,
whereas the rest does not. It is often sufficient to do that in order to speed up processing.

best regatds
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 19 Apr 2018, at 23:40, Mauro Giubileo  wrote:
> 
> Thank you Mike. I thought Csound API provided some facility to opcode reusing, but if this is not the case I can always study some opcode C source code and merge part or all of its behaviour inside my new opcode. It's not the ideal solution from the point of view of software engineering, but it's doable. I already checked some opcodes source code and I think the code is clear enough to understand.
>  
> Thanks again,
> Mauro
> 
> 
> Il 2018-04-19 21:33 Michael Gogins ha scritto:
> 
>> Csound does not make it easy to re-use existing native opcode
>> functions from new opcodes. In theory this is possible, but I have not
>> heard of anyone doing it. To make it work, I think you would have to
>> (a) #include the existing opcode header files, and either (b)(i) link
>> with the existing opcode library (if it is a plugin), or (ii) obtain
>> pointers to the existing opcode functions either as named symbols (for
>> statically linked opcodes) or using csoundOpenLibrary and
>> csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
>> have to make your new opcode manage the existing opcode instance
>> lifecycle the same way that Csound itself does, and this is the hard
>> part (allocating the opcode, running the init pass, etc.).
>> 
>> Alternatively, you could use an existing C/C++ DSP library in your
>> opcode. Some of these are header file only libraries. I list some
>> examples here (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
>> but there are surely many more. I think this would be much simpler.
>> 
>> Regards,
>> Mike
>> 
>> 
>> 
>> 
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>> 
>> 
>> On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
>>  wrote:
>>> Hello everyone,
>>> I am a newbie Csound user and altough initially I had some trouble
>>> understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
>>> beginning to appreciate their flexibility.
>>> 
>>> However, being that I'm doing research in the field of digital waveguide
>>> sound synthesis, I encountered some performance problems because I often
>>> need to create UDOs that work sample-by-sample (ksmps=1) which obviously
>>> slows down the execution of Csound code, especially if there are many voices
>>> in polyphony. Another thing that I think slows down the UDOs is the passage
>>> of a-rate parameters "by copy" rather than "by reference" but unfortunately
>>> Csound currently doesn't allow passage by reference (right?).
>>> So, I would like to convert in C some of my experimental UDOs and I wonder,
>>> in this regard, if the following documents are still valid for the latest
>>> stable Csound version or maybe they are obsolete:
>>> 
>>> http://csounds.com/articles/Extensions_to_Csound.pdf
>>> 
>>> http://floss.booktype.pro/csound/extending-csound/
>>> 
>>> 
>>> Finally, I would like to know if it's possible to call an existing C opcode
>>> from within a new opcode written in C. For example, let's suppose you want
>>> to convert into a C opcode the following UDO:
>>> 
>>> opcode test, a, ai
>>>     aSignal,   \
>>>     iCutoff    xin
>>>     aFiltered  tone    aSignal, iCutoff
>>>     aSignal    =       (aSignal + aFiltered) * 0.5
>>>                xout    aSignal
>>> endop
>>> 
>>> should I re-implement "tone" in my C code, or could I call the existing
>>> Csound tone opcode from within my new C opcode function? And, if it's
>>> possible, how could I do that in a clean way?
>>> 
>>> 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

This is interesting... In this way you could isolate implicit a[] loops without slowing down the rest of the UDO, and in doing that you could regain a little bit of processing power... It could be useful when your UDO does many other things using standard Csound opcodes, besides your customized sample-by-sample computations. Of course, if your UDO does only the sample-by-sample computation, the result would be the same of using setksmps=1 at the beginning of it and I suspect in these cases you can get a big improvement only by writing an a-rate C opcode.

Anyway thanks for the suggestion, I will try it!

Mauro

Il 2018-04-19 23:49 joachim heintz ha scritto:

and what steven showed about implicit a[] loops might also be a solution for some cases:

EXAMPLE 03A19_Sample_by_sample_processing.csd   in
http://write.flossmanuals.net/csound/a-initialization-and-performance-pass/

and

EXAMPLE 03G14_UDO_zdf_svf.csd in
http://write.flossmanuals.net/csound/g-user-defined-opcodes/


    joachim



On 19/04/18 22:10, Rory Walsh wrote:

Regarding ksmps, UDOs can have their own ksmps independent of the main
ksmps. No need to slow down the entire orchestra.

On Thu 19 Apr 2018, 20:33 Michael Gogins, <michael.gogins@gmail.com
<mailto:michael.gogins@gmail.com>> wrote:

    Csound does not make it easy to re-use existing native opcode
    functions from new opcodes. In theory this is possible, but I have not
    heard of anyone doing it. To make it work, I think you would have to
    (a) #include the existing opcode header files, and either (b)(i) link
    with the existing opcode library (if it is a plugin), or (ii) obtain
    pointers to the existing opcode functions either as named symbols (for
    statically linked opcodes) or using csoundOpenLibrary and
    csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
    have to make your new opcode manage the existing opcode instance
    lifecycle the same way that Csound itself does, and this is the hard
    part (allocating the opcode, running the init pass, etc.).

    Alternatively, you could use an existing C/C++ DSP library in your
    opcode. Some of these are header file only libraries. I list some
    examples here
    (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
    but there are surely many more. I think this would be much simpler.

    Regards,
    Mike




    -----------------------------------------------------
    Michael Gogins
    Irreducible Productions
    http://michaelgogins.tumblr.com
    Michael dot Gogins at gmail dot com


    On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
    <mgiubileo@computeraltafed.it <mailto:mgiubileo@computeraltafed.it>>
    wrote:
    > Hello everyone,
    > I am a newbie Csound user and altough initially I had some trouble
    > understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
    > beginning to appreciate their flexibility.
    >
    > However, being that I'm doing research in the field of digital
    waveguide
    > sound synthesis, I encountered some performance problems because I
    often
    > need to create UDOs that work sample-by-sample (ksmps=1) which
    obviously
    > slows down the execution of Csound code, especially if there are
    many voices
    > in polyphony. Another thing that I think slows down the UDOs is
    the passage
    > of a-rate parameters "by copy" rather than "by reference" but
    unfortunately
    > Csound currently doesn't allow passage by reference (right?).
    > So, I would like to convert in C some of my experimental UDOs and
    I wonder,
    > in this regard, if the following documents are still valid for the
    latest
    > stable Csound version or maybe they are obsolete:
    >
    > http://csounds.com/articles/Extensions_to_Csound.pdf
    >
    > http://floss.booktype.pro/csound/extending-csound/
    >
    >
    > Finally, I would like to know if it's possible to call an existing
    C opcode
    > from within a new opcode written in C. For example, let's suppose
    you want
    > to convert into a C opcode the following UDO:
    >
    > opcode test, a, ai
    >     aSignal,   \
    >     iCutoff    xin
    >     aFiltered  tone    aSignal, iCutoff
    >     aSignal    =       (aSignal + aFiltered) * 0.5
    >                xout    aSignal
    > endop
    >
    > should I re-implement "tone" in my C code, or could I call the
    existing
    > Csound tone opcode from within my new C opcode function? And, if it's
    > possible, how could I do that in a clean way?
    >
    > Best regards,
    > Mauro
    >
    > Csound mailing list Csound@listserv.heanet.ie
    <mailto: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 <mailto: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
<mailto: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

Thank you for your reply, Victor.
Maybe I didn't express myself very well in my original message, but I'm already using "setksmps=1" in UDOs where I have to make sample-by-sample computations. Unfortunately this is not sufficient to speed up the processing as I would like.

I checked the collection of opcodes, and, for example, "wguide1" is the closest opcode to one of the things I have in mind for my experiments, but unfortunately it is not exactly what I want, so for now I implemented an UDO that does just what I want (but it does sample-by-sample computations in Csound language, so it's slow) and I hope to convert it in C, in future, to gain big performance improvements.

The other problem is that if you write something like that:

opcode myfilter, a, a
   aIn    xin

          ; DO SOMETHING WITH THE INPUT SIGNAL:
          ...
          ...

          xout aIn
endop

if, for example, I use this filter 10 times in cascade at each k-iteration and I understood how Csound works, it would do 10+10 copies of a-rate vectors (10 for the passage by value of the input a-rate parameters, 10 for the output) at each k-iteration. If in my UDO, theorically, I could work directly on the input signal without have to copy it, then all those vector copies that Csound does are a waste of processing power (and a waste of memory => CPU cache fills faster => more CPU cache miss => worse real-time performance => less polyphony).

So, if I didn't miss something, this is another situation where I could gain performance by writing code directly in C (or I can just replicate the Csound code 10 times to avoid passing parameters by value... But it's not an elegant solution from the point of view of software engineering and code reuse). A better way would be if the Csound language would permit to pass parameters by reference too.

Best regards,
Mauro

Il 2018-04-20 10:56 Victor Lazzarini ha scritto:

That is not the goal of the API (to allow reuse). Also, you are probably confusing the host API, which is
the Csound API proper, with the support for adding new opcodes to the system (which may be seen
as a subset thereof, but it is actually a separate element). That basically provides a mechanism for you to
register your C code with the engine so that you can write Csound code using them (then if you are writing
Csound code there is plenty of opportunities to reuse components). Note that this is a standard way
most music programming languages work (providing a mechanism to add unit generators without actually
providing a whole library of DSP C/C++ functions/etc for this purpose).

You also might want to look at the Csound collection of opcodes to see if there is not something that
already does the job that you are wanting to do.

Also, as Rory said, you can write Csound UDOs or instruments that use a local ksmps values of 1,
whereas the rest does not. It is often sufficient to do that in order to speed up processing.

best regatds
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952

On 19 Apr 2018, at 23:40, Mauro Giubileo <mgiubileo@COMPUTERALTAFED.IT> wrote:

Thank you Mike. I thought Csound API provided some facility to opcode reusing, but if this is not the case I can always study some opcode C source code and merge part or all of its behaviour inside my new opcode. It's not the ideal solution from the point of view of software engineering, but it's doable. I already checked some opcodes source code and I think the code is clear enough to understand.
 
Thanks again,
Mauro


Il 2018-04-19 21:33 Michael Gogins ha scritto:

Csound does not make it easy to re-use existing native opcode
functions from new opcodes. In theory this is possible, but I have not
heard of anyone doing it. To make it work, I think you would have to
(a) #include the existing opcode header files, and either (b)(i) link
with the existing opcode library (if it is a plugin), or (ii) obtain
pointers to the existing opcode functions either as named symbols (for
statically linked opcodes) or using csoundOpenLibrary and
csoundGetLibrarySymbol (for plugin opcodes). In addition, you would
have to make your new opcode manage the existing opcode instance
lifecycle the same way that Csound itself does, and this is the hard
part (allocating the opcode, running the init pass, etc.).

Alternatively, you could use an existing C/C++ DSP library in your
opcode. Some of these are header file only libraries. I list some
examples here (https://michaelgogins.tumblr.com/LibrariesForSoundSynthesis.html)
but there are surely many more. I think this would be much simpler.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Thu, Apr 19, 2018 at 2:49 PM, Mauro Giubileo
<mgiubileo@computeraltafed.it> wrote:

Hello everyone,
I am a newbie Csound user and altough initially I had some trouble
understanding the i-rate, k-rate, a-rate Csound mechanisms, now I'm
beginning to appreciate their flexibility.

However, being that I'm doing research in the field of digital waveguide
sound synthesis, I encountered some performance problems because I often
need to create UDOs that work sample-by-sample (ksmps=1) which obviously
slows down the execution of Csound code, especially if there are many voices
in polyphony. Another thing that I think slows down the UDOs is the passage
of a-rate parameters "by copy" rather than "by reference" but unfortunately
Csound currently doesn't allow passage by reference (right?).
So, I would like to convert in C some of my experimental UDOs and I wonder,
in this regard, if the following documents are still valid for the latest
stable Csound version or maybe they are obsolete:

http://csounds.com/articles/Extensions_to_Csound.pdf

http://floss.booktype.pro/csound/extending-csound/


Finally, I would like to know if it's possible to call an existing C opcode
from within a new opcode written in C. For example, let's suppose you want
to convert into a C opcode the following UDO:

opcode test, a, ai
    aSignal,   \
    iCutoff    xin
    aFiltered  tone    aSignal, iCutoff
    aSignal    =       (aSignal + aFiltered) * 0.5
               xout    aSignal
endop

should I re-implement "tone" in my C code, or could I call the existing
Csound tone opcode from within my new C opcode function? And, if it's
possible, how could I do that in a clean way?

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