Re: [Csnd-dev] Csound 7.0 release planning

Hi!

What about documentation and examples demonstrating the new possibilities?

I will do more testing through CsoundQt during coming weeks.

Thanks!
tarmo

Kontakt Steven Yi (<[email protected]>) kirjutas kuupäeval K, 14. august
2024 kell 14:25:

> 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
> <[email protected]> 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
> >
> >
> >
> >
> >
> >
>