You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Other implementaions of liblsl (e.g. pylsl, liblsl-Matlab and liblsl-rust say that if you're looking for a specific stream, the prefered method is to use resolve_byprop().
"""Resolve all streams with a specific value for a given property.
If the goal is to resolve a specific stream, this method is preferred over
resolving all streams and then selecting the desired one.
Keyword arguments:
prop -- The StreamInfo property that should have a specific value (e.g.,
"name", "type", "source_id", or "desc/manufaturer").
value -- The string value that the property should have (e.g., "EEG" as
the type property).
minimum -- Return at least this many streams. (default 1)
timeout -- Optionally a timeout of the operation, in seconds. If the
timeout expires, less than the desired number of streams
(possibly none) will be returned. (default FOREVER)
Returns a list of matching StreamInfo objects (with empty desc field), any
of which can subsequently be used to open an inlet.
Debug.Log(string.Format("Found new Stream {0}", item.name()));
// var newStreamInfo = new StreamInfoWrapper(item);
knownStreams.Add(item);// newStreamInfo);
OnStreamFound?.Invoke(item);// newStreamInfo);
}
}
yieldreturnnew WaitForSecondsRealtime(0.1f);
}
yieldreturnnull;
}
}
}
liblsl-Csharp and LSL4Unity don't explicitly mention what the preffered method of finding a stream is and LSL4Unity uses a singular Resolver Monobehaviour that finds all the streams on the network. Would it be better to have the resolver be within the Inlet Monobehaviour instead and to call the ContinuousResolver(string prop, string value, double forget_after = 5.0) : base(dll.lsl_create_continuous_resolver_byprop(prop, value, forget_after)) { } constructor? This would then be in keeping with the other implementations of liblsl, especially as the Inlet class is alread asking for the stream name and type.
The text was updated successfully, but these errors were encountered:
So the reason the code samples in most other environments use resolve_byprop etc is that in those cases it's often fine that the call is blocking, and it's easier to get started with LSL this way. For Unity, if you don't want blocking calls, then it's usually better to use a ContinuousResolver rather than the standalone resolve functions. If you do use continuous resolvers, then it will be a bit lighter weight on the local network to use just one of them at a time, since each of them generates its own network traffic (query packets and response packets, if there are any matches) while the object is alive.
There are ways around the resolver being blocking within an inlet monobehaviour (e.g. coroutines, async/await or Unity 2023's Awaitable) but all of these methods will probably end up checking against a bool or if the inlet object == null within the Update loop and returning if conditions aren't met.
Regarding the lightweightness of the continuous resolvers, and this is for my understanding, is it better to have x byprop or bypred resolvers if there are y streams on the network but x < y? Or is still better to have one resolver regardless of how many streams Unity is hooking into?
Other implementaions of
liblsl
(e.g.pylsl
,liblsl-Matlab
andliblsl-rust
say that if you're looking for a specific stream, the prefered method is to useresolve_byprop()
.LSL4Unity/Runtime/Scripts/Resolver.cs
Lines 1 to 103 in 75d54ab
liblsl-Csharp
andLSL4Unity
don't explicitly mention what the preffered method of finding a stream is andLSL4Unity
uses a singular Resolver Monobehaviour that finds all the streams on the network. Would it be better to have the resolver be within the Inlet Monobehaviour instead and to call theContinuousResolver(string prop, string value, double forget_after = 5.0) : base(dll.lsl_create_continuous_resolver_byprop(prop, value, forget_after)) { }
constructor? This would then be in keeping with the other implementations ofliblsl
, especially as the Inlet class is alread asking for the stream name and type.The text was updated successfully, but these errors were encountered: