Ahh - the second part was introduced after 6.11.0 which is the version of my builds.

Is this working? I was thinking about updating the fluidsynth dependency from 1.1.10 to > 2. This would be a big help.

We can't move if v2 is not widely available. I think that we need to consider moving these opcodes out to their own repo so these changes can be made there and won't affect the build.

Apologies, I only saw the other comment in the other issue thread after. I added fluidsynth 1.1.10 to VCPKG so I can use that instead of >2.0 to fix the current build issue.

Maybe my header was a bit misleading: The patch should

• not change behaviour for fluidsynth 1.x
• fix for fluidsynth 2.x

Sorry - it was a naive mistake from my side that I did test this patch against 6.11.0 only: On current branch 'develop' it fixes some breakages but not all:

csound/git/Opcodes/fluidOpcodes/fluidOpcodes.cpp:707:43: error: invalid application of 'sizeof' to incomplete type 'FluidInfo'
{(char *)"fluidInfo", sizeof(FluidInfo), 0, 1, (char *)"S[]", (char *)"i",
^
csound/git/Opcodes/fluidOpcodes/fluidOpcodes.cpp:702:15: error: in-class initialization of static data member 'OENTRY FluidInfo::localops []' of incomplete type
static OENTRY localops[] = {
^~~~~~~~
csound/git/Opcodes/fluidOpcodes/fluidOpcodes.cpp:788:1: error: expected '}' at end of input
}
^
csound/git/Opcodes/fluidOpcodes/fluidOpcodes.cpp:788:1: error: expected unqualified-id at end of input

In fluidsynth 2.0.0 the API changed so that FluidInfo is like a handle for accessor functions - the structure of FluidInfo is kept private. Will investigate further how to fix - help appreciated.

FWIW: fluidsynth 2.x is worth the effort: Among other enhancements there is a new setting: synth.dynamic-sample-loading (see FluidSynth/fluidsynth#366). If activated it reduces load time and RAM consumption significantly for huge GM soundfonts and opens new possibilities (particularly on resurce-limited embedded machines).

We can't move if v2 is not widely available. I think that we need to consider moving these opcodes out to their own repo so these changes can be made there and won't affect the build.

I can not comprehend the reasoning to not accept this. @schnitzeltony's change proposed here is absolutely fine. It is the correct way to use the 2.0 API, while keeping compatibility to build with fluidsynth-1.x.

@schnitzeltony P.S.:

while ((fluidPreset = fluid_sfont_iteration_next(fluidSoundfont))) {
          {

One brace too many.

Even with a fix to the extra {, this doesn't build here for me on Windows but my headers look to have version 2 defined for fluidsynth. I suspect my copy of fluidsynth gitrepo/library was downloaded before @stekyne 's changes to downloadDependencies.ps1. I need to get connect to power supply to rebuild dependencies, but I'd say if this compiles and runs with Fluidsynth1.x that we should merge in.

It builds here on MacOS with 1.x

I'm not sure this was ready to be merged