{"action":"created","issue":{"url":"https://api.github.com/repos/open-ephys/GUI/issues/311","labels_url":"https://api.github.com/repos/open-ephys/GUI/issues/311/labels{/name}","comments_url":"https://api.github.com/repos/open-ephys/GUI/issues/311/comments","events_url":"https://api.github.com/repos/open-ephys/GUI/issues/311/events","html_url":"https://github.com/open-ephys/GUI/pull/311","id":104551356,"number":311,"title":"Event Broadcaster sink","user":{"login":"cstawarz","id":180266,"avatar_url":"https://avatars.githubusercontent.com/u/180266?v=3","gravatar_id":"","url":"https://api.github.com/users/cstawarz","html_url":"https://github.com/cstawarz","followers_url":"https://api.github.com/users/cstawarz/followers","following_url":"https://api.github.com/users/cstawarz/following{/other_user}","gists_url":"https://api.github.com/users/cstawarz/gists{/gist_id}","starred_url":"https://api.github.com/users/cstawarz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cstawarz/subscriptions","organizations_url":"https://api.github.com/users/cstawarz/orgs","repos_url":"https://api.github.com/users/cstawarz/repos","events_url":"https://api.github.com/users/cstawarz/events{/privacy}","received_events_url":"https://api.github.com/users/cstawarz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-09-02T19:06:50Z","updated_at":"2015-09-04T00:13:43Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/open-ephys/GUI/pulls/311","html_url":"https://github.com/open-ephys/GUI/pull/311","diff_url":"https://github.com/open-ephys/GUI/pull/311.diff","patch_url":"https://github.com/open-ephys/GUI/pull/311.patch"},"body":"These changes add a new sink type, \"Event Broadcaster\", that makes Open Ephys events accessible to external processes via a ZeroMQ PUB socket.  The file `Resources/Python/event_listener.py` implements a subscriber to the published events (for testing and demonstration).\r\n\r\nEach event is transmitted as a ZeroMQ multi-part message with three parts:\r\n\r\n1. Event type (single byte)\r\n2. Event time in seconds (little-endian `double`)\r\n3. \"Raw\" OE event, minus the event type\r\n\r\nI opted to send the raw event data because (1) I wasn't certain how many fields of certain event types (e.g. spikes) would be useful to clients and therefore didn't want to omit any, and (2) I didn't have a preference for any particular serialization format, and using the raw event data was perfectly acceptable for my purposes.  As a future enhancement, I can imagine adding a drop-down menu in the Event Broadcaster editor that lets the user choose from a selection of serialization formats (e.g. [JSON](http://json.org), [BSON](http://bsonspec.org), [msgpack](http://msgpack.org)) in addition to the current \"raw\" format.\r\n\r\nThese changes also add a new event type, `TTL_WORD`, whose payload is a little-endian `uint64` where each bit represents the state of a TTL line.  Such an event is generated for every sample in which one or more TTL line states has changed.  I added this because I want to send multi-bit sync words from an external application and echo them back via the event broadcaster, and reconstructing the word from individual `TTL` events proved awkward.  I'm not 100% sure this is the right solution for my problem, so I'm open to suggestions for better ways to do it."},"comment":{"url":"https://api.github.com/repos/open-ephys/GUI/issues/comments/137606180","html_url":"https://github.com/open-ephys/GUI/pull/311#issuecomment-137606180","issue_url":"https://api.github.com/repos/open-ephys/GUI/issues/311","id":137606180,"user":{"login":"aacuevas","id":1830303,"avatar_url":"https://avatars.githubusercontent.com/u/1830303?v=3","gravatar_id":"","url":"https://api.github.com/users/aacuevas","html_url":"https://github.com/aacuevas","followers_url":"https://api.github.com/users/aacuevas/followers","following_url":"https://api.github.com/users/aacuevas/following{/other_user}","gists_url":"https://api.github.com/users/aacuevas/gists{/gist_id}","starred_url":"https://api.github.com/users/aacuevas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aacuevas/subscriptions","organizations_url":"https://api.github.com/users/aacuevas/orgs","repos_url":"https://api.github.com/users/aacuevas/repos","events_url":"https://api.github.com/users/aacuevas/events{/privacy}","received_events_url":"https://api.github.com/users/aacuevas/received_events","type":"User","site_admin":false},"created_at":"2015-09-04T00:13:43Z","updated_at":"2015-09-04T00:13:43Z","body":"Hi,\r\n\r\nThanks for the module, it's a greatly appreciated contribution.\r\nWhat we're a bit unsure of is the new event type. We recently did a cleanup on those, and adding new ones causes no short amount of trouble down the chain. Why's awkward reconstructing the words from the edge events? We chose sending separate edge events because that's what most processors needed and we'd like to minimice data redundancy."}}