Hi everyone,

we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:

1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.

2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.

3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.

4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
For CS_PAR we can optionally disable the option until this can be looked at.

5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?

As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?

Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.

Victor

I've got a couple of items I'm looking at:

* Finishing pass-by-ref for new-style UDOs (was dealing with merging
latest from develop and working out through the changes from local sr
that affected UDOs)
* Fixing expressions (there's issues I've seen come up in some of my
live coding, need to diagnose further and resolve)

I haven't announced it but I've put together CsoundFFM
(https://central.sonatype.com/artifact/com.kunstmusik/csoundffm) for
using the Csound API from Java (requires Java 22). It works with
Csound 6 and the current develop branch but will need to be adjusted
for newapi changes. It does not fully wrap the Csound API yet but
should be easy to extend and maintain. I think this is the way to go
but requiring Java 22+ might not work for everyone. Needs a community
survey to see, but I'd prefer CsoundFFM be the main binding moving
forward. (It'll be what I use in Blue at least.)

Note: We still use SWIG and JNI for Android. I don't think there's any
option but JNI for Android for interfacing with native libraries? We
could remove producing the java library for linux/windows/macOS, but
we'll need to maintain what's there for Android.


Besides the PRs already to go through, there's two things I'd like to
see before the conference:

* code formatting/linting
* code folder reorganization

I think it's best to get through other things first but I do think
they're worth getting done for 7.0.




On Wed, Aug 14, 2024 at 7:08 AM Victor Lazzarini
<000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>
> Hi everyone,
>
> we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:
>
> 1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.
>
> 2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.
>
> 3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.
>
> 4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
> For CS_PAR we can optionally disable the option until this can be looked at.
>
> 5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?
>
> As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?
>
> Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.
>
> Victor
>
>
>
>
>
>

These all sound good to me. I guess the multiple assignment issue may be fixed
in the round together with the expressions issue you mentioned.

Formatting should not be difficult to implement (there is a proposal in one of the
branches). Folder reorganisation is important, maybe it’s the last thing before
release?

Android’s Java interface with SWIG + C++ JNI is still maintained (and synced to the API), 
I think it’s the simplest for now, until we have someone who knows their way round Android 
and can improve it.

If you think it’s better to have CsoundFFM as a third-party wrapper, then we may
deem this solved. It would certainly help us with maintenance. I also might move
the Bela frontend to its own repo.

What should we do with PARCS?

Victor
> On 14 Aug 2024, at 12:25, Steven Yi  wrote:
> 
> I've got a couple of items I'm looking at:
> 
> * Finishing pass-by-ref for new-style UDOs (was dealing with merging
> latest from develop and working out through the changes from local sr
> that affected UDOs)
> * Fixing expressions (there's issues I've seen come up in some of my
> live coding, need to diagnose further and resolve)
> 
> I haven't announced it but I've put together CsoundFFM
> (https://central.sonatype.com/artifact/com.kunstmusik/csoundffm) for
> using the Csound API from Java (requires Java 22). It works with
> Csound 6 and the current develop branch but will need to be adjusted
> for newapi changes. It does not fully wrap the Csound API yet but
> should be easy to extend and maintain. I think this is the way to go
> but requiring Java 22+ might not work for everyone. Needs a community
> survey to see, but I'd prefer CsoundFFM be the main binding moving
> forward. (It'll be what I use in Blue at least.)
> 
> Note: We still use SWIG and JNI for Android. I don't think there's any
> option but JNI for Android for interfacing with native libraries? We
> could remove producing the java library for linux/windows/macOS, but
> we'll need to maintain what's there for Android.
> 
> 
> Besides the PRs already to go through, there's two things I'd like to
> see before the conference:
> 
> * code formatting/linting
> * code folder reorganization
> 
> I think it's best to get through other things first but I do think
> they're worth getting done for 7.0.
> 
> 
> 
> 
> On Wed, Aug 14, 2024 at 7:08 AM Victor Lazzarini
> <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>> 
>> Hi everyone,
>> 
>> we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:
>> 
>> 1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.
>> 
>> 2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.
>> 
>> 3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.
>> 
>> 4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
>> For CS_PAR we can optionally disable the option until this can be looked at.
>> 
>> 5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?
>> 
>> As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?
>> 
>> Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.
>> 
>> Victor
>> 
>> 
>> 
>> 
>> 
>> 

I think if all of the requirements for PARCS are internal and we can
introduce changes that don't affect the ABI, it's fine to release it
with it disabled and fix it later. I don't know if anyone is using it?
If so, they can continue to use csound 6 for the time being.

On Wed, Aug 14, 2024 at 7:50 AM Victor Lazzarini
<000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>
> These all sound good to me. I guess the multiple assignment issue may be fixed
> in the round together with the expressions issue you mentioned.
>
> Formatting should not be difficult to implement (there is a proposal in one of the
> branches). Folder reorganisation is important, maybe it’s the last thing before
> release?
>
> Android’s Java interface with SWIG + C++ JNI is still maintained (and synced to the API),
> I think it’s the simplest for now, until we have someone who knows their way round Android
> and can improve it.
>
> If you think it’s better to have CsoundFFM as a third-party wrapper, then we may
> deem this solved. It would certainly help us with maintenance. I also might move
> the Bela frontend to its own repo.
>
> What should we do with PARCS?
>
> Victor
> > On 14 Aug 2024, at 12:25, Steven Yi  wrote:
> >
> > I've got a couple of items I'm looking at:
> >
> > * Finishing pass-by-ref for new-style UDOs (was dealing with merging
> > latest from develop and working out through the changes from local sr
> > that affected UDOs)
> > * Fixing expressions (there's issues I've seen come up in some of my
> > live coding, need to diagnose further and resolve)
> >
> > I haven't announced it but I've put together CsoundFFM
> > (https://central.sonatype.com/artifact/com.kunstmusik/csoundffm) for
> > using the Csound API from Java (requires Java 22). It works with
> > Csound 6 and the current develop branch but will need to be adjusted
> > for newapi changes. It does not fully wrap the Csound API yet but
> > should be easy to extend and maintain. I think this is the way to go
> > but requiring Java 22+ might not work for everyone. Needs a community
> > survey to see, but I'd prefer CsoundFFM be the main binding moving
> > forward. (It'll be what I use in Blue at least.)
> >
> > Note: We still use SWIG and JNI for Android. I don't think there's any
> > option but JNI for Android for interfacing with native libraries? We
> > could remove producing the java library for linux/windows/macOS, but
> > we'll need to maintain what's there for Android.
> >
> >
> > Besides the PRs already to go through, there's two things I'd like to
> > see before the conference:
> >
> > * code formatting/linting
> > * code folder reorganization
> >
> > I think it's best to get through other things first but I do think
> > they're worth getting done for 7.0.
> >
> >
> >
> >
> > On Wed, Aug 14, 2024 at 7:08 AM Victor Lazzarini
> > <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
> >>
> >> Hi everyone,
> >>
> >> we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:
> >>
> >> 1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.
> >>
> >> 2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.
> >>
> >> 3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.
> >>
> >> 4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
> >> For CS_PAR we can optionally disable the option until this can be looked at.
> >>
> >> 5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?
> >>
> >> As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?
> >>
> >> Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.
> >>
> >> Victor
> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
>

Sounds like the right thing for the moment.
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Aug 2024, at 15:08, Steven Yi  wrote:
> 
> I think if all of the requirements for PARCS are internal and we can
> introduce changes that don't affect the ABI, it's fine to release it
> with it disabled and fix it later. I don't know if anyone is using it?
> If so, they can continue to use csound 6 for the time being.
> 
>> On Wed, Aug 14, 2024 at 7:50 AM Victor Lazzarini
>> <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>> 
>> These all sound good to me. I guess the multiple assignment issue may be fixed
>> in the round together with the expressions issue you mentioned.
>> 
>> Formatting should not be difficult to implement (there is a proposal in one of the
>> branches). Folder reorganisation is important, maybe it’s the last thing before
>> release?
>> 
>> Android’s Java interface with SWIG + C++ JNI is still maintained (and synced to the API),
>> I think it’s the simplest for now, until we have someone who knows their way round Android
>> and can improve it.
>> 
>> If you think it’s better to have CsoundFFM as a third-party wrapper, then we may
>> deem this solved. It would certainly help us with maintenance. I also might move
>> the Bela frontend to its own repo.
>> 
>> What should we do with PARCS?
>> 
>> Victor
>>>> On 14 Aug 2024, at 12:25, Steven Yi  wrote:
>>> 
>>> I've got a couple of items I'm looking at:
>>> 
>>> * Finishing pass-by-ref for new-style UDOs (was dealing with merging
>>> latest from develop and working out through the changes from local sr
>>> that affected UDOs)
>>> * Fixing expressions (there's issues I've seen come up in some of my
>>> live coding, need to diagnose further and resolve)
>>> 
>>> I haven't announced it but I've put together CsoundFFM
>>> (https://central.sonatype.com/artifact/com.kunstmusik/csoundffm) for
>>> using the Csound API from Java (requires Java 22). It works with
>>> Csound 6 and the current develop branch but will need to be adjusted
>>> for newapi changes. It does not fully wrap the Csound API yet but
>>> should be easy to extend and maintain. I think this is the way to go
>>> but requiring Java 22+ might not work for everyone. Needs a community
>>> survey to see, but I'd prefer CsoundFFM be the main binding moving
>>> forward. (It'll be what I use in Blue at least.)
>>> 
>>> Note: We still use SWIG and JNI for Android. I don't think there's any
>>> option but JNI for Android for interfacing with native libraries? We
>>> could remove producing the java library for linux/windows/macOS, but
>>> we'll need to maintain what's there for Android.
>>> 
>>> 
>>> Besides the PRs already to go through, there's two things I'd like to
>>> see before the conference:
>>> 
>>> * code formatting/linting
>>> * code folder reorganization
>>> 
>>> I think it's best to get through other things first but I do think
>>> they're worth getting done for 7.0.
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Aug 14, 2024 at 7:08 AM Victor Lazzarini
>>> <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:
>>>> 
>>>> Hi everyone,
>>>> 
>>>> we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:
>>>> 
>>>> 1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.
>>>> 
>>>> 2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.
>>>> 
>>>> 3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.
>>>> 
>>>> 4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
>>>> For CS_PAR we can optionally disable the option until this can be looked at.
>>>> 
>>>> 5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?
>>>> 
>>>> As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?
>>>> 
>>>> Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.
>>>> 
>>>> Victor
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> 
>>