Hi everyone,

thanks to those who were able to come to the meeting yesterday. We made some key decisions and
I think we have a clear path now towards the release.

Here are some minimal notes:

1. Csound 7.0 current status

Parser 3 is mostly done, except for a certain number of items in two categories: (1) Hlodver’s PR containing the full roll out of structs and various fixes; (2) Reference types (including opcode references)  and UDO pass by reference. The former should be soon merged; the latter
needs to be implemented (see 2. below).

Other work done included reorganisation of source code; removal of SWIG for Python; introduction of a soundfile interface to allow Csound to be built without libsndfile (currently stubs).

2. Minimum viable release candidate.

We need help to bring the Android and iOS platform support up-to-date. This is to provide a more uniform distribution of the Csound library across multiple platforms. This needs to be arranged before we release 7.0.

Desktop Java bindings using SWIG will be discontinued. Whether we will support custom-built Java bindings as part of the main repository as we do for Python (and WASM) is still to be decided.

Parser:
(i) reference types and pass by reference to UDOs needs to be implemented.
(ii) opcode references are also desirable but a design needs to be worked out where DSP context is taken into consideration (also see below re: local SR)
(iii) PARCS code needs to be restored
(iv) Support for adding new opcodes to a running system needs to be restored (not so much a parser issue but a feature that has been lost with the new parser).

Scheduler improvements:
(i) We can currently add events to the realtime list but cannot delete them. This needs to be implemented in some form/.
(ii) Tempo processing is a score processor feature. We need to investigate whether we can introduce the concept of
variable bpm into the scheduler.

Local sampling rate.
We need to implement support for local sampling rates in instruments and UDOs. For this we have decided that
sampling rate conversion should be handled by SRC. We need to investigate how to incorporate this (e.g. as dependency
like libsndfile or by incorporating the source code if the licence permits).

API: the API needs to be reviewed and consolidated.

In general, we should try to have the major external-facing features completed, plus the support for later additions (e.g.
in the parser, namespaces etc). We should try to make a number of internal changes before the release, but these can
potentially come later (as long as there are no ABI changes). Of these we have

- Source code reorganisation (e.g. csound.c -> csoundCore.c, a new
csound.c for csound.h functions etc)
- review named instruments mechanism
- simplify csound compiler code

3. Project management and work distribution.

Steven volunteered to manage the project. Work distribution will be discussed within the next while.
We decided to use Discord (#dev channel) for a more agile form of communication, but the developer’s
list can also be used for communication of major decisions or questions.

4. Proposed release schedule: September 2024

5. Csound 6.x maintenance: as agreed earlier we should enforce bug fixes only and re-direct any
improvement contributions to 7. Exceptions to these may be requested and we can consider these,
but the justification needs to be clear.

If anyone of you wish to see the meeting video recording/notes, please contact me privately and I will
share the link.

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

Wonderful. Thanks for the update!

Øyvind

tor. 2. nov. 2023 kl. 13:15 skrev Victor Lazzarini <Victor.Lazzarini@mu.ie>:

Hi everyone,

thanks to those who were able to come to the meeting yesterday. We made some key decisions and
I think we have a clear path now towards the release.

Here are some minimal notes:

1. Csound 7.0 current status

Parser 3 is mostly done, except for a certain number of items in two categories: (1) Hlodver’s PR containing the full roll out of structs and various fixes; (2) Reference types (including opcode references)  and UDO pass by reference. The former should be soon merged; the latter
needs to be implemented (see 2. below).

Other work done included reorganisation of source code; removal of SWIG for Python; introduction of a soundfile interface to allow Csound to be built without libsndfile (currently stubs).

2. Minimum viable release candidate.

We need help to bring the Android and iOS platform support up-to-date. This is to provide a more uniform distribution of the Csound library across multiple platforms. This needs to be arranged before we release 7.0.

Desktop Java bindings using SWIG will be discontinued. Whether we will support custom-built Java bindings as part of the main repository as we do for Python (and WASM) is still to be decided.

Parser:
(i) reference types and pass by reference to UDOs needs to be implemented.
(ii) opcode references are also desirable but a design needs to be worked out where DSP context is taken into consideration (also see below re: local SR)
(iii) PARCS code needs to be restored
(iv) Support for adding new opcodes to a running system needs to be restored (not so much a parser issue but a feature that has been lost with the new parser).

Scheduler improvements:
(i) We can currently add events to the realtime list but cannot delete them. This needs to be implemented in some form/.
(ii) Tempo processing is a score processor feature. We need to investigate whether we can introduce the concept of
variable bpm into the scheduler.

Local sampling rate.
We need to implement support for local sampling rates in instruments and UDOs. For this we have decided that
sampling rate conversion should be handled by SRC. We need to investigate how to incorporate this (e.g. as dependency
like libsndfile or by incorporating the source code if the licence permits).

API: the API needs to be reviewed and consolidated.

In general, we should try to have the major external-facing features completed, plus the support for later additions (e.g.
in the parser, namespaces etc). We should try to make a number of internal changes before the release, but these can
potentially come later (as long as there are no ABI changes). Of these we have

- Source code reorganisation (e.g. csound.c -> csoundCore.c, a new
csound.c for csound.h functions etc)
- review named instruments mechanism
- simplify csound compiler code

3. Project management and work distribution.

Steven volunteered to manage the project. Work distribution will be discussed within the next while.
We decided to use Discord (#dev channel) for a more agile form of communication, but the developer’s
list can also be used for communication of major decisions or questions.

4. Proposed release schedule: September 2024

5. Csound 6.x maintenance: as agreed earlier we should enforce bug fixes only and re-direct any
improvement contributions to 7. Exceptions to these may be requested and we can consider these,
but the justification needs to be clear.

If anyone of you wish to see the meeting video recording/notes, please contact me privately and I will
share the link.

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