Add Event Broadcaster JSON option

[markschatza]

Event Broadcaster only sent the raw binary event data out. This made reading/understanding the outbound data difficult. This feature adds the ability to choose your output format (Raw Binary, Header, Header/JSON) from a drop down list on the plugin.

Here the Header was implemented as starting with the type of event (spike, text, binary, ttl) followed by some important information (id, channel, timestamp, etc). The JSON object holds all information about the event, including metadata.

Example Header: "spike/sortedid:1/id:spikesource/ts:23384"
Example JSON: {'type': 'spike', 'sortedID': 1, 'numChannels': 2, 'threshold': [150, 160], 'timing': {'sampleRate': 40000, 'timestamp': 23384}, 'identifier': 'spikesource', 'name': 'ST p112.0 n0', 'metaData': {'Color': ['255', '255', '0']}}

It is a fairly big change, but nearly all of the additions involve parsing the event and building the JSON object to be sent. We found this very helpful so we could use the existing event class structure to get the event information instead of building our own parser after receiving the data!

Overview of Implementation

sendEvent() was heavily rewritten to now build a message object that holds all the information to be published. A JSON object was also made if the Header/JSON format is selected and then it's added to the message object.

This message object was sent to a new sendMessage() function that iterated through all the message parts and published them on the ZMQ socket.

The last few functions added getDataReader() , binaryValuetoVar() , stringValuetoVar() were used because JUCE has no built-in constructor for uint64/uint32 to Var which is needed to create the JSON object.

Let me know if you have any comments!

[ethanbb]

It looks like some recent changes to the event broadcaster architecture on development weren't included in this branch. I'm going to try to fix it with a merge and rebase.