-
Notifications
You must be signed in to change notification settings - Fork 2
AudYoFlo: Behavior: Host Implementations
Every AudYoFlo application comes along with a central component, denoted as the host. This host holds references to all involved components and can be addressed from external to involve, connect and start components. Typically, all user interaction involves the host!
Depending on the application characteristics, a different type of host is required, starting from the minimal host to the full signal processing host. The host functionality is defined by the amount of interfaces it exposes. In the following diagram, the main host variants are summarized in a interface derivation chart:

The three host categories minimal host (IjvxMinHost), factory host (IjvxFactoryHost) and full host (IjvxHost) are highlighted by the grey background ellipses. From host to host the complexity increases due to additional interfaces that are added - for example, the interface IjvxFactoryHost comprises a set of sub interfaces whereas the interface IjvxHost derives all interfaces of IjvxFactoryHost but adds additional functionalities (interface IjvxComponentHost).
Besides the interfaces within the derivation graph which can be addressed via host reference pointers, additional functionalities can be addressed via the hidden interface extensions which can be queries and requested at runtime. In particular the interface IjvxToolsHost is exposed by both variants of the host, the factory host as well as the full host when querying with the hidden interface request function. For the sake of completeness, it must be noted here that the implementation of the IjvxToolsHost interface is diffferent in both casesdue to different feature sets.
The involved classes expose interface functions, in particular as described in the following chapters.
The minimal host object type exposes the typical interfaces objects are based on in AudYoFlo:
This interface combines the sub interfaces IjvxObject and IjvxHiddenInterface that every other object exposes as well.
This interface defines the typical state machine life cycle of an object in AudYoFlo.
Compared to the IjvxMinHost category, the factory host adds the following interfaces:
This interface defines options to control the host bindings. E.g., libraries to add components from static libraries can be added. Also, the blank IjvxFactoryHost can be extended by adding external interfaces which are provided by the controlling application. The member functions in detail are:
JVX_INTERFACE IjvxHostInteraction
{
public:
//! Set a report target for all kinds of reports.
virtual jvxErrorType set_external_report_target(IjvxReport* hdl) = 0;
//! Set a report target for specific steps during the configuration process.
virtual jvxErrorType set_external_report_on_config(IjvxReportOnConfig* callbackStruct) = 0;
//! Add aand remove external report targets for state switch operations. Multiple targets can be served.
virtual jvxErrorType add_external_report_state_switch(IjvxReportStateSwitch* callbackStruct, const char* tag) = 0;
virtual jvxErrorType remove_external_report_state_switch(IjvxReportStateSwitch* callbackStruct) = 0;
//! Add an remove external compoment factories. This function is used whenever static libraries are involved.
virtual jvxErrorType add_external_component(
IjvxObject* theObj, IjvxGlobalInstance* theGlob,
const char* locationDescription,
jvxBool allowMultipleInstance = false,
jvxInitObject_tp funcInit = NULL,
jvxTerminateObject_tp funcTerm = NULL) = 0;
virtual jvxErrorType remove_external_component(IjvxObject* theObj) = 0;
//! Add and remove external interface handlers.
virtual jvxErrorType add_external_interface(jvxHandle* theHdl, jvxInterfaceType theIFacetype) = 0;
virtual jvxErrorType remove_external_interface(jvxHandle* theHdl, jvxInterfaceType theIFacetype) = 0;
//! Functions to control which component to load and which to ignore at boot time.
virtual jvxErrorType add_component_load_blacklist(jvxComponentType theTp, jvxBool targetBlackList = true) = 0;
virtual jvxErrorType remove_component_load_blacklist(jvxComponentType theTp, jvxBool targetBlackList = true) = 0;
virtual jvxErrorType set_component_load_filter_function(jvxLoadModuleFilterCallback, jvxHandle* priv) = 0;
//!
virtual jvxErrorType store_config(const char* token, const char* cfgToken, jvxBool overwrite_old = true) = 0;
virtual jvxErrorType copy_config(const char* token, jvxApiString* strReturn) = 0;
virtual jvxErrorType clear_config(const char* token) = 0;
};
This interface is used by the application to report the following two state change events to the host:
JVX_INTERFACE IjvxSystemStatus
{
public:
//! Callback to report that the system is ready now
virtual jvxErrorType system_ready() = 0;
//! Callback to report that the system is about to shutdown
virtual jvxErrorType system_about_to_shutdown() = 0;
};
The interfaces as shown for the three host categories have been defined. In the implementation, however, besides the realization of these interfaces additional hidden interfaces are added in different host implementations to be explained in the following. The main goal in all host implementations is to avoid code duplicates, therefore, derived classes as well as template mixins are used in a derivation scheme that is shown in the following diagram:

Note that three different host implementations are currently in use within the overall system - depending on the requirements and with the target in mind to safe complexity and memory.
