Can't find the libscsynth / libsupernova header files

Hey all!

I remember finding the header file for libscsynth and libsupernova in the SuperCollider repository, but for the life of me I can’t find them anymore! Can someone point me to where they are supposed to be?

Thanks!

I think all public headers should be within the include directory, the headers of libscsynth are within the server subfolder. I don’t know if libsupernova has its own headers.

Just checked and there is no supernova shared library in Debian.

The libscsynth API is in include/server/SC_WorldOptions.h.

Just checked and there is no supernova shared library in Debian.

Because Supernova can’t be build as a library.

Thanks a lot!

Yeah, it’s quite sad that it is not possible. I might look into it and PR a way to do it. I’d say it would be a quite useful feature to have, considering that scsynth can be built as a library.

The problem is that unlike scsynth, Supernova is a singleton application which means that there can only ever be a single instance (= the global server instance). A libsupernova would be rather limited and not much different from starting Supernova as a subprocesses and sending OSC messages (like sclang does).

libscsynth is more interesting because you can create several instances, so it can be used in VST plugins, for example.

Speaking about libscsynth… Yesterday I was doing a very simple ctypes binding on Linux. It is supposed to be a C API but World_SendPacket / World_SendPacketWithContext uses ReplyFunc as custom callback, all C so far, but one of the parameters of that function is the struct ReplyAddress which is non public and has a member that is C++ (boost::asio::ip::address mAddress), that kinda killed my vib. Also that makes the API itself to depend on the API of another library which doesen’t seems to be good. I could open an issue if that is right.

but one of the parameters of that function is the struct ReplyAddress which is non public and has a member that is C++

Yes, that’s a problem.

Actually, the only member of ReplyAddress that is relevant for libscsynth users is mReplyData - which holds the context pointer passed to World_SendPacketWithContext. All the other members are not meant to be used. After all, the OSC message didn’t come from an actual network socket.

It would be less of a problem if mReplyData was the very first member in the ReplyAddress struct because then the client could simply cast ReplyAddress * to a similar struct that only contains the context pointer:

// in SC_WorldOptions.h:
struct ReplyContext {
    void *mData;
};

// in the user defined reply function:
void myReplyFunc(struct ReplyAddress * inReply, char *inBuf, int inSize) {
    ReplyContext *context = (ReplyContext *)inReply;
    MyData* data = (MyData *)context->mData;
    // ...
}

I think this could be an easy solution. One potential problem is that it breaks binary compatibility, but this only matters if a user swaps the libscsynth binary with a newer version without recompiling the app - or vice versa, recompiles the app with the new headers, but doesn’t update libscsynth. On the other hand, ReplyAddress was never part of the public API in the first place. I think it would be enough to just add a warning to the release notes.

Feel free to open a ticket on GitHub. You could copy my comment here, so I don’t have to repeat it :slight_smile:

(edited the post above for clarity)