Muse SDK

Incorporate the SDK into your code to communicate directly with the MuseHub

The Muse SDK allows for a seamless customer experience for apps that are web based, or require a login/account setup flow to work. The goal is to activate and sign in everything behind the scenes so that the product has a great first-run experience.

It is very straightforward to integrate the Muse SDK into an existing software project. Via the Muse SDK, the product can query the MuseHub and retrieve information like the Unique User ID, to use it internally or together with a server component.

This wiki page refers to Muse SDK v1.3.0.

Package structure

The MuseClientSDK package is structured as follows:

• README.md Quick overview of the SDK

• bin

  • macos_universal Contains the universal dynamic library for macOS, supporting both arm64 and x86_64 architectures.

  • win64 Contains the 64-bit dynamic library (.dll) for Windows, along with the respective import library (.lib).

• include Header files defining the SDK API for accessing library functions.

• examples Cross-platform examples demonstrating SDK usage.

• nodejs-bindings Native add-on binding the native C API to Electron applications, provided for convenience together with instructions and a javascript example.

Integration

Your product can access the SDK functionality by linking the provided binary libraries and using the API include/MuseClientSdkApi.h. Electron apps shall use the provided node.js bindings, more on that below.

The SDK is provided with a C interface for maximum compatibility across languages, compilers and ABIs.

Linking - Windows

The product shall statically link to bin\win64\MuseClientSdk.1.3.0.lib. The MuseHub client application will take care of installing the DLL on the computer.

Electron applications may continue using the legacy static import. To do so, they shall statically link to bin\win64\MuseClientSdk.1.3.0_imports.lib instead, and embed the statically linked DLL into their package as before.

Linking - macOS

The product shall statically link to bin/macos_universal/libMuseClientSdk.1.3.0.a and bin/macos_universal/libMuseClientSdk.1.3.0.dylib. The dylib shall be copied into the app or plug-ins bundle in Contents/Frameworks/libMuseClientSdk.1.3.0.dylib.

Depending on the toolchain used, you may have to set the linker flag -rpath @loader_path/../Frameworks/ for the linker to find the embedded dylib.

The dynamic library will be code-signed as part of the product. To that purpose, please use codesign --deep.

If you are signing an AAX plug-in via PACE's wraptool, pre-sign the dylib as follows: codesign --force --deep --options runtime -s "your developer identity" ProductName.aaxplugin/Contents/Frameworks/libMuseClientSdk.1.3.0.dylib

Note for Projucer users on macOS

If you are building a JUCE plug-in with the Projucer app, you can achieve the above linking by adding the flag -rpath @loader_path/../Frameworks/ to "Extra Linker Flags" and path/to/libMuseClientSdk.1.3.0.dylib to "Embedded Frameworks".

However, recent versions of the projucer have a limitation when it comes to embedding frameworks, not yet solved at the time of writing. The problem and work-arounds are discussed on the JUCE forum.

The cmake-based JUCE demo plug-in provided with the SDK package correctly integrates the SDK dylib instead.

Functionality

The easiest way get acquainted with the SDK is to build the example provided in the example directory. This example demonstrates the usage of the SDK in a practical scenario and can serve as a guide for integrating and using the SDK in your own projects.

For a detailed description of the API functions and parameters, please refer to the API header MuseClientSdkApi.h.

General information

• The API is single threaded.

• All functions are synchronous and can block the caller up to a few seconds while waiting for external resources. If responsiveness is a concern, it is suggested to use this API on a dedicated thread instead of the UI thread.

• All returned char* fields are either valid null-terminated strings, or nullptr if not available.

• All returned memory structures must be released using the dedicated MuseSdk_release functions.

Electron applications

Electron applications can use the SDK via js bindings, known as a native add-on. For your convenience, an Electron add-on is provided with instructions for building for your specific Electron ABI. This add-on exposes a js interface for all the native SDK API. An example.js file is also provided to demonstrate typical usage in Electron apps.

Initialization

• MuseSdk_initialize: Initializes the secure inter-process communication with the MuseHub for subsequent SDK API calls.

Electron applications cannot use MuseSdk_initializeand must use a dedicated API instead:

MuseSdk_initializeElectron: Initializes the secure inter-process communication between an Electron app and the MuseHub for subsequent SDK API calls. Pass process.execPathas the mandatory argument. This API cannot be used by native applications, that shall use MuseSdk_initialize instead.

• MuseSdk_initializeTestMode: can be used to ease initial integration testing, because it does not require your test product to be installed via the MuseHub, since it returns mock data. For actual product submissions (Beta or Release), either initialize or initializeElectron must be used depending on the application type. However, SDK use of these calls is subject to pre-approval, see the box below.

Important

MuseSdk_initialize and MuseSdk_initializeElectron will only connect to the Hub successfully once SDK usage is enabled via pre-approval by the MuseHub team. This acceptance step is in place for quality and security purposes, and the SDK will not connect unless approved.

• MuseSdk_finalize: Releases the communication channel with the MuseHub and any associated resources.

User information

The information returned here allows a product to activate and sign in a user behind the scenes.

• MuseSdk_getUserInfo: Retrieves the UUID associated with the active MuseHub account.

  • If the user has opted in for personal data sharing with partners, the following additional data may be returned by this API: email, name, picture.

• MuseSdk_releaseUserInfo: Releases any data created by MuseSdk_getUserInfo.

• MuseSdk_requestPersonalDataOptin: this can be used if an email and other personal data are absolutely needed to create a user account, i.e. if UUID is not sufficient. If the user has not opted in for personal data sharing already, the MuseHub will show a popup asking for permission to do so.

The user information API functionality is complemented by the Web Hooks feature.

Product information

• MuseSdk_getSku: Retrieves the SKU specified in the Muse Partner Portal for the current product.

• MuseSdk_releaseSku: Releases any data created by MuseSdk_getSku.

• MuseSdk_getSubscriptionOption: Retrieves the ID specified in the Muse Partner Portal for the currently authorized product subscription.

• MuseSdk_releaseSubscriptionOption: Releases any data created by MuseSdk_getSubscriptionOption.

Product license

• MuseSdk_getActivationStatus: Retrieves the current activation status for the running product. This is a quick license check, useful for server-based products that self-update frequently and do not rely upon more secure license information and prefer a less-secure but simpler check.

• MuseSdk_getReceipt: Retrieves a receipt of purchased items, that is the client product and any in-app-purchase content. This is a detailed and secure receipt, cryptographically-signed on the MuseHub servers. Its signature can be validated by the product for additional security, using the following cryptographic API:

• MuseSdk_verifySignature: Verifies a payload signature using the specified public key id.

• MuseSdk_getSystemId: Retrieves a unique hardware system identifier that can be used to check the product receipts are intended for the current computer.

The above security functions are provided via the SDK's static library part, so that they are linked inside the product binary itself for additional security, with a very small additional footprint.

Content

• MuseSdk_getSamplesInstallLocation: Retrieves the samples install location for a product to enumerate available content. Corresponding samples_location_changed and new_content_installed callbacks are available for a sampling product to be informed when new MuseSounds are available to the current user.

Asynchronous notifications

• MuseSdk_registerNotificationListener: Allows the product to register for notifications from the MuseHub app. These notifications are diverse (i.e. user opted-in to share personal info, new samples were downloaded...) and we will add more as we add new functionality.