Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

Is this on the dev branch now Victor? 

On Wed, 24 Jul 2024 at 18:32, vlz <viclazzarini@gmail.com> wrote:

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

Sorry, I see you actually mentioned where it is! 

On Wed, 24 Jul 2024 at 19:24, Rory Walsh <rorywalsh@ear.ie> wrote:

Is this on the dev branch now Victor? 

On Wed, 24 Jul 2024 at 18:32, vlz <viclazzarini@gmail.com> wrote:

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

Did you mean feature/newapi? 

On Wed, 24 Jul 2024 at 19:25, Rory Walsh <rorywalsh@ear.ie> wrote:

Sorry, I see you actually mentioned where it is! 

On Wed, 24 Jul 2024 at 19:24, Rory Walsh <rorywalsh@ear.ie> wrote:

Is this on the dev branch now Victor? 

On Wed, 24 Jul 2024 at 18:32, vlz <viclazzarini@gmail.com> wrote:

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

Thanks for this.

For csoundCompileCsd(), my thought was consolidation but of course with the mode parameter, it can be extendable.

I am hoping François and Steven who have been writing wrappers will be able to steer the API to a good state with regards to other languages.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 24 Jul 2024, at 20:07, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Looks OK to me. My main concerns:

(1) Be able to compile a CSD as a text blob as well as from a filename. Using a flag in csoundCompileCsd looks like it should do that, and may be better in that it allows changing the CSD from blob to filename at run time.

(2) Keep all API calls easy to wrap in other language interfaces, especially Python and JavaScript. That doesn't seem to have changed.

I may have suggested that the function pointers in the CSOUND_ struct should really be in an array, as in a C++ class, such that adding to this array does not change the size of the actual CSOUND_ struct. Please give that a thought.

Best,

Mike

-----------------------------------------------------

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

On Wed, Jul 24, 2024 at 12:32 PM vlz <viclazzarini@gmail.com> wrote:

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

I'll take a look.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 28 Jul 2024, at 13:46, Tarmo Johannes <trmjhnns@gmail.com> wrote:



Hi!

One more question:

CsoundQt uses csound_threaded.hpp  to support html files that us Csound.

The files is present in feature/newapi branch but not updated yet.

What are the plans with it? I am not sure, but I think MIchael Gogins wrote this wrapper?

Thanks!

tarmo

Kontakt Victor Lazzarini (<000010b17ddd988e-dmarc-request@listserv.heanet.ie>) kirjutas kuupäeval K, 24. juuli 2024 kell 22:42:

Thanks for this.

For csoundCompileCsd(), my thought was consolidation but of course with the mode parameter, it can be extendable.

I am hoping François and Steven who have been writing wrappers will be able to steer the API to a good state with regards to other languages.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 24 Jul 2024, at 20:07, Michael Gogins <michael.gogins@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

Looks OK to me. My main concerns:

(1) Be able to compile a CSD as a text blob as well as from a filename. Using a flag in csoundCompileCsd looks like it should do that, and may be better in that it allows changing the CSD from blob to filename at run time.

(2) Keep all API calls easy to wrap in other language interfaces, especially Python and JavaScript. That doesn't seem to have changed.

I may have suggested that the function pointers in the CSOUND_ struct should really be in an array, as in a C++ class, such that adding to this array does not change the size of the actual CSOUND_ struct. Please give that a thought.

Best,

Mike

-----------------------------------------------------

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

On Wed, Jul 24, 2024 at 12:32 PM vlz <viclazzarini@gmail.com> wrote:

Hi all,

I started work on the new API following some of François’ recommendations. The idea is to consolidate the
interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.

I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
(the API proper) and csoundCore_new.h (with some additions relating to changes).

Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.

Most notably, the following things have changed:

1) The number of compilation function variants is reduced.

2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.

3) Audio IO callback setting has been removed, for similar reasons.

4) MIDIO IO callback setting has been consolidated into a single function.

5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
hosts can just read from tables and do their own displays as they see fit.

6) Interfaces to threading, circular buffers, etc are gone.

7) Cscore functions are gone.

8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).

The idea is to make it less overwhelming for host developers.

Victor

I guess at this point the CI is not building the binaries, so you will need to build them yourself.
I still need to update Android and iOS though. They won’t build right now.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 29 Jul 2024, at 10:39, Giovanni Bedetti <giovanni.bedetti@GMAIL.COM> wrote:
>
> Hi,
> thanks a lot for this Victor.
> I wanted to try the new API on CsoundUnity, and I was wondering if the binaries for every platform are available somewhere, or if I should build them.
> Thanks again
>
> Il giorno dom 28 lug 2024 alle ore 16:09 vlz <viclazzarini@gmail.com> ha scritto:
> I'll take a look.
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 28 Jul 2024, at 13:46, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>
>> Hi!
>>
>> One more question:
>> CsoundQt uses csound_threaded.hpp  to support html files that us Csound.
>> The files is present in feature/newapi branch but not updated yet.
>> What are the plans with it? I am not sure, but I think MIchael Gogins wrote this wrapper?
>>
>> Thanks!
>> tarmo
>>
>> Kontakt Victor Lazzarini (<000010b17ddd988e-dmarc-request@listserv.heanet.ie>) kirjutas kuupäeval K, 24. juuli 2024 kell 22:42:
>> Thanks for this.
>>
>> For csoundCompileCsd(), my thought was consolidation but of course with the mode parameter, it can be extendable.
>>
>> I am hoping François and Steven who have been writing wrappers will be able to steer the API to a good state with regards to other languages.
>>
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>>> On 24 Jul 2024, at 20:07, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>
>>>  *Warning*
>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Looks OK to me. My main concerns:
>>>
>>> (1) Be able to compile a CSD as a text blob as well as from a filename. Using a flag in csoundCompileCsd looks like it should do that, and may be better in that it allows changing the CSD from blob to filename at run time.
>>>
>>> (2) Keep all API calls easy to wrap in other language interfaces, especially Python and JavaScript. That doesn't seem to have changed.
>>>
>>> I may have suggested that the function pointers in the CSOUND_ struct should really be in an array, as in a C++ class, such that adding to this array does not change the size of the actual CSOUND_ struct. Please give that a thought.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Wed, Jul 24, 2024 at 12:32 PM vlz <viclazzarini@gmail.com> wrote:
>>> Hi all,
>>>
>>> I started work on the new API following some of François’ recommendations. The idea is to consolidate the
>>> interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.
>>>
>>> I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
>>> (the API proper) and csoundCore_new.h (with some additions relating to changes).
>>>
>>> Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.
>>>
>>> Most notably, the following things have changed:
>>>
>>> 1) The number of compilation function variants is reduced.
>>>
>>> 2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
>>> hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
>>> also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.
>>>
>>> 3) Audio IO callback setting has been removed, for similar reasons.
>>>
>>> 4) MIDIO IO callback setting has been consolidated into a single function.
>>>
>>> 5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
>>> hosts can just read from tables and do their own displays as they see fit.
>>>
>>> 6) Interfaces to threading, circular buffers, etc are gone.
>>>
>>> 7) Cscore functions are gone.
>>>
>>> 8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).
>>>
>>> The idea is to make it less overwhelming for host developers.
>>>
>>> Victor

It's great the updated API is seeing progress! I'm going to revisit my .NET bindings.

I could also help out with the Python bindings, if there's a need and desire. It could be a good opportunity to modernize the Python bindings and library. For example, it would be better to release the Python library as a `pip` package to ease installation, since the package could just carry around the binary C libraries for each platform. Why is `numpy` included as a dependency. Is it needed? To manage dependencies and packaging, I'd recommend using Poetry.

For the API in general, I saw what was removed and changed but haven't yet had a chance to review them against my understanding, so I thought I'd just ask. My idea for a Csound bindings, library, and application would be to use Csound as a real-time synth and sound engine, but it would not be used with the typical write CSD -> compile -> run workflow. It would utilize the real-time, live-updating features of Csound. Is that functionality being preserved and improved in the new Csound API? Does the API still allow the selection of which audio driver/device to use?

On Mon, Jul 29, 2024 at 6:07 AM Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

I guess at this point the CI is not building the binaries, so you will need to build them yourself.
I still need to update Android and iOS though. They won’t build right now.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 29 Jul 2024, at 10:39, Giovanni Bedetti <giovanni.bedetti@GMAIL.COM> wrote:
>
> Hi,
> thanks a lot for this Victor.
> I wanted to try the new API on CsoundUnity, and I was wondering if the binaries for every platform are available somewhere, or if I should build them.
> Thanks again
>
> Il giorno dom 28 lug 2024 alle ore 16:09 vlz <viclazzarini@gmail.com> ha scritto:
> I'll take a look.
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 28 Jul 2024, at 13:46, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>
>> Hi!
>>
>> One more question:
>> CsoundQt uses csound_threaded.hpp  to support html files that us Csound.
>> The files is present in feature/newapi branch but not updated yet.
>> What are the plans with it? I am not sure, but I think MIchael Gogins wrote this wrapper?
>>
>> Thanks!
>> tarmo
>>
>> Kontakt Victor Lazzarini (<000010b17ddd988e-dmarc-request@listserv.heanet.ie>) kirjutas kuupäeval K, 24. juuli 2024 kell 22:42:
>> Thanks for this.
>>
>> For csoundCompileCsd(), my thought was consolidation but of course with the mode parameter, it can be extendable.
>>
>> I am hoping François and Steven who have been writing wrappers will be able to steer the API to a good state with regards to other languages.
>>
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>>> On 24 Jul 2024, at 20:07, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>
>>>  *Warning*
>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Looks OK to me. My main concerns:
>>>
>>> (1) Be able to compile a CSD as a text blob as well as from a filename. Using a flag in csoundCompileCsd looks like it should do that, and may be better in that it allows changing the CSD from blob to filename at run time.
>>>
>>> (2) Keep all API calls easy to wrap in other language interfaces, especially Python and JavaScript. That doesn't seem to have changed.
>>>
>>> I may have suggested that the function pointers in the CSOUND_ struct should really be in an array, as in a C++ class, such that adding to this array does not change the size of the actual CSOUND_ struct. Please give that a thought.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Wed, Jul 24, 2024 at 12:32 PM vlz <viclazzarini@gmail.com> wrote:
>>> Hi all,
>>>
>>> I started work on the new API following some of François’ recommendations. The idea is to consolidate the
>>> interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.
>>>
>>> I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
>>> (the API proper) and csoundCore_new.h (with some additions relating to changes).
>>>
>>> Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.
>>>
>>> Most notably, the following things have changed:
>>>
>>> 1) The number of compilation function variants is reduced.
>>>
>>> 2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
>>> hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
>>> also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.
>>>
>>> 3) Audio IO callback setting has been removed, for similar reasons.
>>>
>>> 4) MIDIO IO callback setting has been consolidated into a single function.
>>>
>>> 5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
>>> hosts can just read from tables and do their own displays as they see fit.
>>>
>>> 6) Interfaces to threading, circular buffers, etc are gone.
>>>
>>> 7) Cscore functions are gone.
>>>
>>> 8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).
>>>
>>> The idea is to make it less overwhelming for host developers.
>>>
>>> Victor

The Python wrapper is François' territory, maybe he can answer your question. As a user, I find it excellent that there's such a great integration with Numpy.

Regarding your questions about the API, all that functionality is there and streamlined as well.

For audio IO, you can select any of the existing backends as before or you can add a new one (as a plugin module using the module API). You can also access the csound audio buffers to send/receive as needed.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 29 Jul 2024, at 16:34, Blake Mitchell <bmitchell33@gmail.com> wrote:



It's great the updated API is seeing progress! I'm going to revisit my .NET bindings.

I could also help out with the Python bindings, if there's a need and desire. It could be a good opportunity to modernize the Python bindings and library. For example, it would be better to release the Python library as a `pip` package to ease installation, since the package could just carry around the binary C libraries for each platform. Why is `numpy` included as a dependency. Is it needed? To manage dependencies and packaging, I'd recommend using Poetry.

For the API in general, I saw what was removed and changed but haven't yet had a chance to review them against my understanding, so I thought I'd just ask. My idea for a Csound bindings, library, and application would be to use Csound as a real-time synth and sound engine, but it would not be used with the typical write CSD -> compile -> run workflow. It would utilize the real-time, live-updating features of Csound. Is that functionality being preserved and improved in the new Csound API? Does the API still allow the selection of which audio driver/device to use?

On Mon, Jul 29, 2024 at 6:07 AM Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

I guess at this point the CI is not building the binaries, so you will need to build them yourself.
I still need to update Android and iOS though. They won’t build right now.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 29 Jul 2024, at 10:39, Giovanni Bedetti <giovanni.bedetti@GMAIL.COM> wrote:
>
> Hi,
> thanks a lot for this Victor.
> I wanted to try the new API on CsoundUnity, and I was wondering if the binaries for every platform are available somewhere, or if I should build them.
> Thanks again
>
> Il giorno dom 28 lug 2024 alle ore 16:09 vlz <viclazzarini@gmail.com> ha scritto:
> I'll take a look.
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 28 Jul 2024, at 13:46, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>>
>> Hi!
>>
>> One more question:
>> CsoundQt uses csound_threaded.hpp  to support html files that us Csound.
>> The files is present in feature/newapi branch but not updated yet.
>> What are the plans with it? I am not sure, but I think MIchael Gogins wrote this wrapper?
>>
>> Thanks!
>> tarmo
>>
>> Kontakt Victor Lazzarini (<000010b17ddd988e-dmarc-request@listserv.heanet.ie>) kirjutas kuupäeval K, 24. juuli 2024 kell 22:42:
>> Thanks for this.
>>
>> For csoundCompileCsd(), my thought was consolidation but of course with the mode parameter, it can be extendable.
>>
>> I am hoping François and Steven who have been writing wrappers will be able to steer the API to a good state with regards to other languages.
>>
>>
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>
>>> On 24 Jul 2024, at 20:07, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>
>>>  *Warning*
>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Looks OK to me. My main concerns:
>>>
>>> (1) Be able to compile a CSD as a text blob as well as from a filename. Using a flag in csoundCompileCsd looks like it should do that, and may be better in that it allows changing the CSD from blob to filename at run time.
>>>
>>> (2) Keep all API calls easy to wrap in other language interfaces, especially Python and JavaScript. That doesn't seem to have changed.
>>>
>>> I may have suggested that the function pointers in the CSOUND_ struct should really be in an array, as in a C++ class, such that adding to this array does not change the size of the actual CSOUND_ struct. Please give that a thought.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Wed, Jul 24, 2024 at 12:32 PM vlz <viclazzarini@gmail.com> wrote:
>>> Hi all,
>>>
>>> I started work on the new API following some of François’ recommendations. The idea is to consolidate the
>>> interface, make it simpler and start removing functionality that has not been used by hosts since 6.x.
>>>
>>> I have completed a minimal set in the feature/moduleapi branch. The relevant files are csound_new.h
>>> (the API proper) and csoundCore_new.h (with some additions relating to changes).
>>>
>>> Not all of the API is implemented (I will start working on it next), but it’s out there now for comment.
>>>
>>> Most notably, the following things have changed:
>>>
>>> 1) The number of compilation function variants is reduced.
>>>
>>> 2) We are not exposing the buffering anymore, so csoundPerformBuffer() is gone. This has been
>>> hardly used, host developers seem to prefer access to spin/spout. The single-short csoundPerform() is
>>> also gone, it is easily duplicated by csoundPerfomKsmps() in a loop.
>>>
>>> 3) Audio IO callback setting has been removed, for similar reasons.
>>>
>>> 4) MIDIO IO callback setting has been consolidated into a single function.
>>>
>>> 5) Functions for events and table access were consolidated. Graphing callbacks etc are also removed since
>>> hosts can just read from tables and do their own displays as they see fit.
>>>
>>> 6) Interfaces to threading, circular buffers, etc are gone.
>>>
>>> 7) Cscore functions are gone.
>>>
>>> 8) UDP server functions are gone (this functionality is offered by options, so there is no need to duplicate it here).
>>>
>>> The idea is to make it less overwhelming for host developers.
>>>
>>> Victor