Hi,
I need to set boxes in real time with dynamic information.
Firstly, I did a basic thing : I created a stream matrix input on a box and a stream matrix output on an other one, both linked. So each numeric information can be send by this way. Each new dynamic settings is linked to a new input.
Now, I would like to make something generic, in the OpenViBE philosophy, so I need your point of view.
The first issue is about input : is it better to build one input by dynamic settings or one global input for all dynamic settings? I can easily imagine a 30 dynamic settings box... so it is not a basic question.
The second issue is about content of these input : if stream matrix is enough to communicate numeric value, do we need string value (for instance)... to change enumeration (value in comboBox), color, filename, etc.? If something generic is to be done, i think yes.
So I imagine a new flow for this kind of input, it would be an amount of "struct" information :
_Target (a header to identify the targetted setting to modify)
_Type (matrix or stringList or somethingelse)
_Data (stream matrix or list of string, etc.)
What do you advise me?
Thanks
new flow : configuration data
Re: new flow : configuration data
Dear matthieuG,
your first approach sounds reasonable for streamed matrix. However, you have to keep in mind that inputs / outputs are for streamed data. Conceptually, that means data "constantly changing" over time. My opinion on what you want to do is that a "dynamic setting" should be added to the box prototype. That means doing changes in the OpenViBE API and propose new services to the box developers. This is quite different than the stream approach and should be used differently. (e.g. updating a spatial filter with a stream sounds reasonable, updating a path to a filename with a stream does not sound reasonable). I think adding a "dynamic setting" to the boxes at the API / kernel level could easily be implemented thanks to the never used Messages / Signal things (don't know if anyone noticed this in the kernel).
In any circumstances, my advice is that if you want to move on the kernel implementation side, you should study the API and its kernel implementation in deep detail to understand the way of doing things and not to break other things...
I hope this helps,
Best regards,
Yann
your first approach sounds reasonable for streamed matrix. However, you have to keep in mind that inputs / outputs are for streamed data. Conceptually, that means data "constantly changing" over time. My opinion on what you want to do is that a "dynamic setting" should be added to the box prototype. That means doing changes in the OpenViBE API and propose new services to the box developers. This is quite different than the stream approach and should be used differently. (e.g. updating a spatial filter with a stream sounds reasonable, updating a path to a filename with a stream does not sound reasonable). I think adding a "dynamic setting" to the boxes at the API / kernel level could easily be implemented thanks to the never used Messages / Signal things (don't know if anyone noticed this in the kernel).
In any circumstances, my advice is that if you want to move on the kernel implementation side, you should study the API and its kernel implementation in deep detail to understand the way of doing things and not to break other things...
I hope this helps,
Best regards,
Yann
Re: new flow : configuration data
That's the point... these settings would change many times in a scenario, for example at each "SegmentStop" of a P300 speller. So well, we discussed about to change settings manually last time by phone but here, it is different : it really a streamed data information!Conceptually, that means data "constantly changing" over time. My opinion on what you want to do is that a "dynamic setting" should be added to the box prototype.
Thanks to answer with this point f view
![Smile :)](./images/smilies/icon_smile.gif)
Re: new flow : configuration data
Dear matthieuG,
as far as I understand the situation, they are changing on a discrete basis, not on a continuous one. However, you are free to implement whatever new stream type you want... this is only memory buffers. Just create one decoder, one encoder and you're done for all your boxes.
Best regards,
Yann
as far as I understand the situation, they are changing on a discrete basis, not on a continuous one. However, you are free to implement whatever new stream type you want... this is only memory buffers. Just create one decoder, one encoder and you're done for all your boxes.
Best regards,
Yann
Re: new flow : configuration data
OK yrenard, I understand I can do it... but do you think it is a good solution, can you imagine something "more OpenViBE".
If it is a good solution does this structuration is good too :
Thanks
If it is a good solution does this structuration is good too :
Endly, where are implemented flow type and decoder/encoder in source code? Is there other some documentation?_Target (a header to identify the targetted setting to modify)
_Type (matrix or stringList or somethingelse)
_Data (stream matrix or list of string, etc.)
Thanks
Re: new flow : configuration data
Dear matthieuG,
What I think is that depending on the case you're in, maybe the stream approach is better, maybe the dynamic setting approach is better...
You sound in a hurry here so do what most fits you needs. If time is a problem, then do it fast![Wink ;)](./images/smilies/icon_wink.gif)
The dynamic setting approach will most likely not be implemented anytime soon...
The existing streams coders / decoders are in openvibe-plugins/stream-codecs
Hope this helps,
Yann
What I think is that depending on the case you're in, maybe the stream approach is better, maybe the dynamic setting approach is better...
You sound in a hurry here so do what most fits you needs. If time is a problem, then do it fast
![Wink ;)](./images/smilies/icon_wink.gif)
The dynamic setting approach will most likely not be implemented anytime soon...
The existing streams coders / decoders are in openvibe-plugins/stream-codecs
Hope this helps,
Yann
Re: new flow : configuration data
That's true I like questions are quickly asked to have time to reflect on bottleneck (problems). I am not so hurry, I have 3 weeks now to find a solution... ![Smile :)](./images/smilies/icon_smile.gif)
As you can see, I have already a solution (both really). My problem is also to confirm (or not) it is a good solution. So I need your help.
The aim is clear : allow dynamic stream settings (so not manually change...even if it would be a good stuff). Boxes could communicate information by a stream to change internal parameter, exactly as they communique actually external parameter (in/output).
I see only two axis to do this :
->about pipe :
_one input for each parameter [1]
_one input for all parameters [2]
->about content :
_use existent streams [_a]
_use a new stream [_b]
So we have 4 solutions by combinaison : [1_a], [1_b], [2_a],[2_b]
Are you ok, here? Can you imagine something else?
Analyse :
I don't like the case [_a] for two reasons : The first one, each stream as a name which identify its function, so dynamic stream setting is one. The second one is that if we use existing stream, we can only communicate matrix and stimulations (or numeric only, structured as matrix or as index...spectrum or vector are not so different). This imply only numeric modification (ex : a matrix change to another one) or implanted one (ex : translate a stimulation to a specific setting).
That's however true that there are names of channel in IMatrix (It is the only one Yann?). Can we use them to communicate string information? I think yes. The only limitation is its list format (index-name). To be really generic, I think we need, as numeric part, a matrix format.
Do you think we need something else?Do you agree this case?
About pipe number, I am not sure a unique one is the best solution : whatever the number of box to modify settings, if we have only one input, we need a multiplexer (as stimulation and stream matrix which already exist) to collect all settings in one. So whatever the solution, the number of input is quite the same. So it is not a good condition to solve this question. From development point of view, the difference is only this box of multiplexing...not so difficult and time dependant. In code architecture the difference is about, either a getInputChunk for each input, either a switch with a label for each target setting. So if getInputChunk is only dependant of a known index, the label of setting imply a global define for each target. It is not a trick but it is a little inconvenient for the unique input.
I don't have any more idea...so if you find something to complete this part, it would be great.
Thanks
![Smile :)](./images/smilies/icon_smile.gif)
As you can see, I have already a solution (both really). My problem is also to confirm (or not) it is a good solution. So I need your help.
The aim is clear : allow dynamic stream settings (so not manually change...even if it would be a good stuff). Boxes could communicate information by a stream to change internal parameter, exactly as they communique actually external parameter (in/output).
I see only two axis to do this :
->about pipe :
_one input for each parameter [1]
_one input for all parameters [2]
->about content :
_use existent streams [_a]
_use a new stream [_b]
So we have 4 solutions by combinaison : [1_a], [1_b], [2_a],[2_b]
Are you ok, here? Can you imagine something else?
Analyse :
I don't like the case [_a] for two reasons : The first one, each stream as a name which identify its function, so dynamic stream setting is one. The second one is that if we use existing stream, we can only communicate matrix and stimulations (or numeric only, structured as matrix or as index...spectrum or vector are not so different). This imply only numeric modification (ex : a matrix change to another one) or implanted one (ex : translate a stimulation to a specific setting).
That's however true that there are names of channel in IMatrix (It is the only one Yann?). Can we use them to communicate string information? I think yes. The only limitation is its list format (index-name). To be really generic, I think we need, as numeric part, a matrix format.
Do you think we need something else?Do you agree this case?
About pipe number, I am not sure a unique one is the best solution : whatever the number of box to modify settings, if we have only one input, we need a multiplexer (as stimulation and stream matrix which already exist) to collect all settings in one. So whatever the solution, the number of input is quite the same. So it is not a good condition to solve this question. From development point of view, the difference is only this box of multiplexing...not so difficult and time dependant. In code architecture the difference is about, either a getInputChunk for each input, either a switch with a label for each target setting. So if getInputChunk is only dependant of a known index, the label of setting imply a global define for each target. It is not a trick but it is a little inconvenient for the unique input.
I don't have any more idea...so if you find something to complete this part, it would be great.
Thanks
Re: new flow : configuration data
Dear matthieuG,
maybe I was not clear in my previous posts.
My feeling about your explanations is that you are trying to do your best to implement something with what already exists but has not been designed for it. The implementation you proposes (either solution) will become hard to understand, hard to explain, hard to maintain and will most probably end in something useless. As I said before, implementing what you request - either - could use already existing streams - or - need to add dynamic settings to the box paradigms. The first one will immediately solve your problems for algorithms such as spatial filters, baseline corrections and so on (everything based on matrices in fact). The second one will have the advantage to rely on the Type Manager and the Configuration Manager for everything ! The drawback is that it needs an API enhancement, that can't be done with what already exists.
If you feel you should do it with what OpenViBE proposes nowadays, feel free to. But I insist, that's probably not a good direction...
Hope this was clearer...
Yann
maybe I was not clear in my previous posts.
My feeling about your explanations is that you are trying to do your best to implement something with what already exists but has not been designed for it. The implementation you proposes (either solution) will become hard to understand, hard to explain, hard to maintain and will most probably end in something useless. As I said before, implementing what you request - either - could use already existing streams - or - need to add dynamic settings to the box paradigms. The first one will immediately solve your problems for algorithms such as spatial filters, baseline corrections and so on (everything based on matrices in fact). The second one will have the advantage to rely on the Type Manager and the Configuration Manager for everything ! The drawback is that it needs an API enhancement, that can't be done with what already exists.
If you feel you should do it with what OpenViBE proposes nowadays, feel free to. But I insist, that's probably not a good direction...
Hope this was clearer...
Yann
Re: new flow : configuration data
Hello Yann et Matthieu,
I am with Yann when he says that keep things simple and use existing functionality should be the way to follow if it is good enough with the problem at hand.
I am with Matthieu when he says that what we want to do should be general enough to allow flexible and simple box parameterization on the fly.
Exchanging in english on this subject poses problem; i don't understand fully what you are saying, probably because of language expression.
Since making Open-ViBE fully adaptive is our major development right now, can we make sure we all agree on the best way to proceed?
Can we have a call to discuss these problems?
Cheers,
Marco
I am with Yann when he says that keep things simple and use existing functionality should be the way to follow if it is good enough with the problem at hand.
I am with Matthieu when he says that what we want to do should be general enough to allow flexible and simple box parameterization on the fly.
Exchanging in english on this subject poses problem; i don't understand fully what you are saying, probably because of language expression.
Since making Open-ViBE fully adaptive is our major development right now, can we make sure we all agree on the best way to proceed?
Can we have a call to discuss these problems?
Cheers,
Marco
Re: new flow : configuration data
Dear Marco,
we surely can have a call for this.
Yann
we surely can have a call for this.
Yann