FluComa exit server with code 0 on a recent build of SC 3.14-dev

Questions
1

Hello @tedmoore & @tremblap

in a recent thread, @dscheiba explain me this:
“I assume you are using a current develop build - we had to update a dependency (boost) which broke support with Flucoma, but there will be a future Flucoma release which will fix this. For further information see Bug: FluidDataSet results in server crash on Linux · Issue #174 · flucoma/flucoma-sc · GitHub”

Have you got any idea when there will be a Flucoma-sc release who will fix this problem ?

And what is FluCoMa SuperCollider Nightly Release ?
What are the differences with previous versions ?

2

This is a version that is compiled every time we make a change that we ‘commit’ on what will be the next official release. For people to test. In this instance, I hope you can try it and confirm it has sorted your problems.

I’m working on a release for (hopefully) in the next weeks. My quality check is incredibly thorough, hence the sparse releases. I test every CCE on every OS.

3

Thank you very much for your answer.

boost is up to date in this nightly release ?

You made an amazing work on FluComa, thank you.

4

I just tryed with Release FluCoMa SuperCollider Nightly Release · flucoma/flucoma-sc · GitHub

and SuperCollider 3.14-dev and I get the same message:

Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface

when I run

(
fork{
    var point = Buffer.alloc(s,1);
    var ds = FluidDataSet(s);
    s.sync;
    10.do{
        arg i;
        point.set(0,i);
        ds.addPoint("point-%".format(i),point);
        s.sync;
    };
    ds.print;
};
)
5

actually it is the opposite - now the nightlies and the release are sync’d with the official SC release. so as 3.14 is not the SC release, flucoma is not working with it.

The only option to work with a dev branch of SC (who is the one doing the breaking change) is to compile flucoma for it.

Sorry, until there is a major change in the SC API we cannot go around this.

6

Thank you and some more characters

1 Like
7

another option, if SC is supporting 2 official binaries, is to have 2 flucoma compiles… that would be a little messy on our side… we already have so many packages!

1 Like
8

Maybe we can get [plugin API] Make plugin API extendable · Issue #5347 · supercollider/supercollider · GitHub into 3.14 - this would break every extension out there, so I am somehow hesitant about it, but it would be great to get rid of this problem once and for all. (or we could support a new and a legacy API, but I heard that people with knowledge about its implementation are not too fond of such an idea).

IIRC Flucoma accesses SendReply which is not exposed via the API, right? If it is just about sending some OSC messages from the server to the language you could maybe use something like GitHub - capital-G/OSCMessenger: Send values of UGens to other applications via OSC. - adding this functionality to a UGen is not too hard.

1 Like
9

this is why I didn’t insist on it. I know it will be quite a mega challenge.

yes, and compiles against the exact same version of boost (which again is not in the API). The (difficult and brittle) solution proposed by @weefuzzy is going to be a big issue for SC code, while making it future-proof… but I cannot implement it so for now we do work-arounds and we hoped that compiling against sc’s official release was a good-citizenship-approach…

10

It’s correct that it will break plugin compatibility, but it is an established process. Every now and then we may update the plugin API and the plugins need to be recompiled. That’s what we have the API version for.

As it was pointed out, the problem with FluCoMa and the current plugin API is that the incompatibility is not due to different version of the API, but due to a necessary workaround around the API limitation and linking to boost directly.

I support extending the API, but we should also do it all at once, if possible, to avoid multiple subsequent updates: Plugin interface changes · Issue #6102 · supercollider/supercollider · GitHub

2 Likes