-
Notifications
You must be signed in to change notification settings - Fork 0
ModuleControlMessage
Analog3 physical modules exchange messages to organize themselves to behave as a "synthesizer". These messages are called Module Control Message. CAN Bus is used for physical and datalink layers.
Module Control Messages are categorized into several types listed as below, in descending priority order.
| type | description | sender | receiver |
|---|---|---|---|
| Trigger | Signals used for synchronizing components. | trigger | listener modules |
| Modifier | Change-value notifications sent from modulator modules. | modulator | listener modules |
| Voice Message | Signals to play instrument. | voice generator (ex. MIDI Gateway) | modules corresponding to the voice |
| Parameter Change Request | Request to a component of a module to change its parameter. | manager | a module |
| Parameter Change Notification | Value change notification from a component of a module. | module | manager --> viewers |
A trigger is a time-critical message for module synchronization. Oscillator synchronization signal is an example of trigger.
A modifier is a value change notification of a modulator. Examples of modulators are LFO, envelope generator, etc.
A voice message is a message to play a voice.
A message from manager that requests for any component in a module to change its value.
This message is a reply to a parameter change request. This type of message also can be a notification of component value change initiated by the module itself.
CAN has two different message formats -- standard and extended. Lower ID has higher priority because of arbitration mechanism of CAN protocol.
A standard CAN frame can be represented as follows, although actual frame has more bits to control communication.
struct standard_data_frame = {
uint11 id;
uint1 rtr; // Remote transmission request -- 0: data frame, 1: remote request frame
uint4 data_length; // Number of bytes of data
uint8 data[];
};
An extended CAN frame can be represented as follows.
struct extended_data_frame = {
uint29 id;
uint1 rtr;
uint4 data_length;
uint8 data[];
};
CAN has 2048 (11 bit) ID inventory for standard data frames. Extended data frames have 29-bit ID space but we don't use first 11-bit to avoid extended frame conflicting standard frames. In other words, Analog 3 system uses extended frames with the first 11 bits set as recessive (1).
Map of message type and frame type is as follows:
| Message type | Frame type | ID range | Note |
|---|---|---|---|
| Trigger | standard | 0 - 63 | Trigger ID |
| Modifier | standard | 64 - 1919 | 64 + Modulator ID |
| Voice Message | standard | 1920 - 2047 | 1920 + Voice ID |
| Parameter Change Request | extended | ext 0 | Fixed known ID |
| Parameter Change Notification | extended | ext 1 - | ext 1 + module ID |
In an Analog3 system, there must be one manager component that takes care of ID ext 0. This is the only pre-defined ID in the system; All other IDs would be assigned by the manager.
Parameter change notification ID is build as follows. All of the first 11 bits are set as recessive (1) to avoid conflict with standard IDs during arbitration.
struct parameter_change_notification_id {
int11 padding = 0x7ff;
int2 message_type; // 0: parameter change notification
// 1: reserved
// 2: reserved
// 3: reserved
int16 module_id;
};
| padding = 0x7ff |type | module_id |
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|24|25|26|27|28|