ETCLabs - sACN

Hello dear ETC community,

i hava a few questions about the nice open source sACN library published by ETC here:

s this the correct place for questions about the API usage? I did not find a dedicated developer forum, and i do not want to pollute the github repo with my user questions =)

Best wishes

Parents Reply Children
  • Hi Tom, cool!

    i am using the lib to receive DMX universes, and to my surprise in one of my customers setups (theatre, they have a ETC console) no 'Sources' show up. But i can receive all 'Merged' universes. So i have two questions,

    - is it normal / by design that there are no sources visible (or, more accurate, my callback (below) does not get called)

    	void HandleSourceUpdated(sacn::RemoteSourceHandle handle, const etcpal::Uuid& cid, const std::string& name,
    		const std::vector<uint16_t>& sourced_universes) override

    - is it possible to retrieve the owner names (of the merged universes) names through the  owners handles provided in the SacnRecvMergedData struct?

    	void HandleMergedData(sacn::MergeReceiver::Handle handle, const SacnRecvMergedData& merged_data) override

    Best wishes,

  • OK, very good. I can answer the first part:

    HandleSourceUpdated is part of the SourceDetector module. That deals with an *extension* to the sACN standard that allows sources to send a list of what universes they are controlling. Unfortunately that extension is optional, so you can't assume that all sources support it - and ETC family consoles in fact, don't support it yet. I would say it will sadly be some time before you could expect all sources to support source detection.

    On the second part - I'll check with the developers if/how you can get from a handle to a name - I will advise shortly.

  • And the second part:

    Yes, you can pass the handle into GetSource() which will then return a structure including the source info such as the name

  • Great, ok, i will consider that in the configuration setup. Is this 'extension' rather specific or is it expected to become a part of a future standard?

  • About the second part: to use the call to GetSource() i need a MergeReceiver instance pointer. The callback gives me a handle. Is there a library function that makes a lookup with a handle and returns the associated MergeReceiver? Or do i have to keep track between handles and Mergereceivers myself (,too)?  

  • It is already part of the published standard, it is just that it was added in a later revision (2016), so older sources that implement the first version of the standard (2009) don't support it yet. This was added in the same revision that also added Universe Synchronisation. There has also been a further revision (2018) to add IPv6 support.

  • Ok, thank you for the explanation. Generally speaking, as a DMX consumer (e.g. fixture or media server), am i interested in sources at all? Or do i just care about the merged data to handle control?

  • As a regular consumer you most probably just care about the merged data - e.g. if you are a fixture, you don't particularly care who is sending data or about how arbitration has happened, you just know you're set to universe 10 address 101, say, and you want to function based on that. Caring about all senders and separating them out is more of a diagnostic function you might want in a test tool or similar

  • Thanks, that makes sense. Sometimes media servers are producers (pixel grabbing/ mapping), what is expected bahaviour in that case? Merge receive and send at a selectable merit?