Optimised way to share continuous streams of data to users

[KonVas]

I am wondering which is the best way to share data with all users on the network, for example generating some values from a master computer and then make these available to everyone providing the solution we have now is a master computer generates the data and parses it to a dictionary then the dictionary is send as OSC message to the rest members using this way: ~addrBook.sendAll('/el', * ~eegBook); or to specific members using peers name and .send method. Is there a more efficient way than that?

[adcxyz]

Utopia has OSCDataSpace and OSCObjectSpace for this

[KonVas]

We couldn't add the dictionary on the OSCObjectSpace, for that we used sendAll could you make a dummy example of a dictionary embedding in either of two OSCDataSpace and OSCObjectSpace?

On Thu, Apr 4, 2019 at 11:15 AM Alberto de Campo notifications@github.com wrote:

Utopia has OSCDataSpace and OSCObjectSpace for this

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/muellmusik/Utopia/issues/23#issuecomment-479797581, or mute the thread https://github.com/notifications/unsubscribe-auth/AGlBSBL4V6emq5X8cxxwlX0EtkUgQvG2ks5vdbSXgaJpZM4ccKMU .

[adcxyz]

//////////////////////// from Utopia examples: 
// decentralised discovery of participants
// find who's on the network
(
~win = Window("AdHocSociety").front;
~win.layout = VLayout.new.add(~listView = ListView.new);

~addrBook = AddrBook.new;
// to get updates, just add a dependant
~addrBook.addDependant({|addrBook, what, who|
    {~listView.items = addrBook.peers.collectAs({|peer|
        peer.name ++ " | " ++ peer.addr.ip ++ " | " ++ if(peer.online, "online", "offline");
    }, Array)}.defer;
});

~addrBook.addMe; // will automatically add you using your user name

~hail = Hail(~addrBook);
)
// simple objectspace test:
~objSpace = OSCObjectSpace(~addrBook, true);

~objSpace.put(\event, (a: 1, b: 2));

// check on a different machine: 
~objSpace[\event];
// should be ->  ( 'a': 1, 'b': 2 )

[KonVas]

Oh that's easy, so we could just embed our dictionary into the objectspace inside our OSCdef receiving and at the same time providing the dict.

~objSpace = OSCObjectSpace(~addrBook, true);

OSCdef(\eegPower, { arg msg; msg = msg.round(0.00001); ~eegBook[ msg[1] ] = ([blink: msg[2], delta:msg[3], theta:msg[4], alpha:msg[5], betaLo:msg[6], beta:msg[7], betaHi:msg[8], gamma:msg[9]]); //msg[1] separated elec pin vals ~objSpace.put(~eegBook); }, '/band');

On Thu, Apr 4, 2019 at 11:26 AM Alberto de Campo notifications@github.com wrote:

//////////////////////// from Utopia examples: // decentralised discovery of participants // find who's on the network ( ~win = Window("AdHocSociety").front; ~win.layout = VLayout.new.add(~listView = ListView.new);

~addrBook = AddrBook.new; // to get updates, just add a dependant ~addrBook.addDependant({|addrBook, what, who| {~listView.items = addrBook.peers.collectAs({|peer| peer.name ++ " | " ++ peer.addr.ip ++ " | " ++ if(peer.online, "online", "offline"); }, Array)}.defer; });

~addrBook.addMe; // will automatically add you using your user name

~hail = Hail(~addrBook); ) // simple objectspace test: ~objSpace = OSCObjectSpace(~addrBook, true);

~objSpace.put(\event, (a: 1, b: 2));

// check on a different machine: ~objSpace[\event]; // should be -> ( 'a': 1, 'b': 2 )

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/muellmusik/Utopia/issues/23#issuecomment-479801276, or mute the thread https://github.com/notifications/unsubscribe-auth/AGlBSB50mRz9oaOXp7Tciw_PUauK8pfxks5vdbclgaJpZM4ccKMU .

[muellmusik]

On 4 Apr 2019, at 09:36, Konstantinos Vasilakos notifications@github.com wrote:

Oh that's easy, so we could just embed our dictionary into the objectspace inside our OSCdef receiving and at the same time providing the dict.

Well, basically, OSCObjectSpace is a dictionary, or at least quacks like one. So is OSCDataSpace, it’s just limited to OSC types.

You can have multiple instances with different keys if you need more than one.

I would suggest just using an OSCObjectSpace or OSCDataSpace directly rather than putting a dictionary in one. These can provide a callback when a value is changed. What they can’t do is tell when the internal state of a value is changed. So keeping it top level, and always accessing via the OSCObjectSpace or OSCDataSpace means you’ll be up to date.

~objSpace = OSCObjectSpace(~addrBook, true);

OSCdef(\eegPower, { arg msg; msg = msg.round(0.00001); ~eegBook[ msg[1] ] = ([blink: msg[2], delta:msg[3], theta:msg[4], alpha:msg[5], betaLo:msg[6], beta:msg[7], betaHi:msg[8], gamma:msg[9]]); //msg[1] separated elec pin vals ~objSpace.put(~eegBook); }, '/band');

I assume this is forwarding from another (non-SC) OSC client? If not, would be easier to set the object space directly.

Also, as I said, I don’t think you need the separate dict. Just store your data, at msg[1] in the object space. Since you’re only storing OSC types this could possibly be reworked to use OSCDataSpace.

In the code above, your call to put provides ~eegBook as a key but no value. Would need to be something like ~objSpace.put(\eegBook, ~eegBook); or as I suggested ~objSpace.put(msg[1], dict);

[KonVas]

Thanks for the Input @muellmusik then it means that in the client there is no reason to pack it up again, and make more dictionaries for the ~objSpace as it will be already packed up as one, then we on the clients side can parse it in any way using something like this: ~event = ~objSpace[\event]; and ~event[\el0] ~event[\el1] and so forth. To get a single value we need to use it as an Event ~event[\el0].asEvent and call the value we are looking, such as alpha etc. is this efficient?