Wouldn't it be reasonable to have an api for in and output?
Since many things have a combination of both and sometimes are really related.
touchscreen = screen (output) + touch (input).

I don't know this for sure but wouldn't having two seperate api's be less convenient for integration of complicated input+output devices? Maybe there can be some benefits to integrating something. And with having to change something in two specifications this could proove to be more difficult.

Thank u for reading.

Gedolo

08-06-2011, 08:30 AM

Something I forgot.

Many things are also almost the same but in the different direction:

camera is something that sends 2D array of pixels periodically.
screen is something that receives 2D array of pixels periodically.

They are like qua data almost exactly the same.
It would be very practical, handy to use, exploit these similarities in one api.
Instead of two where there would be many things almost identical.

gavriels

08-11-2011, 06:47 PM

We are indeed thinking about channels for the output side as well. There are many interesting possibilities with that, such as LEDs, audio, etc.

-Gav

Gedolo

08-14-2011, 07:05 AM

Neat!

Also, maybe it would be a good idea to give it another name?
It doesn't make much sense to call it StreamInput if it also does output. :lol:

:idea: Maybe have a contest for the most self-explaining, logical name?

kevinashaw

08-31-2011, 10:48 AM

With regard to the input/output question, I would argue that the output modalities of a computing device haven't really changed in decades. Its still basically a screen display with audio output. Yes, the graphics and computational support behind them have improved, but its still a 2D array of pixels with an audio stream.

For example, an augmented reality app is probably using over half of these now and soon will use most of them. Most of the sensors overlap in significant ways (there are, after all, only six degrees of freedom needed to fully define a rigid body kinematically), however none of them are sufficient all the time and one ends of combining (fusing) inputs across them most of the time.
Thus, I will argue that the real excitement in the field is in finding ways to combine these inputs in new and clever ways, and across a broad range of devices.

Kevin Shaw, CTO
Sensor Platforms

Gedolo

09-02-2011, 06:38 AM

That's quite a narrow minded vision.

There are lots of people who would want to interface engines and other output devices with a computer. What about haptic devices used in gaming?
What about people interfacing a computer with a bunch of servos to build a robot?
Such as in this example:
http://www.talkandroid.com/51611-android-powered-robot-tank-built-by-london-developer/

What if I want to use all kinds of random non-screen non-audio devices?

What about arduino boards and all kinds of output devices?
We want to do this too in an easy way.

This api should allow me to get information from any kind of sensor without having to install extra divers (except the ones who implement streamInput) easily and universally.
But it would be crazy to not use the parallels / synergies between input and output devices.

What if there is a need for other things you haven't thought off?
My point is that the symmetry between input and output devices can minimize the work being done if the latter one needs to be revised. And syncing them will provide benefits because you can make everything consistent in the same release.

What about cellphones? Sending SMS messages and holding a conversation over a phone network requires also a output device?

Maybe something universal for networks?

Gedolo

09-11-2011, 02:55 AM

Another little thing.

Some sensors measure events that happen.
E.g. gamepads and other stuff.
Please have a general event type that can be used with all kinds of things.

Gedolo

02-15-2012, 12:59 PM

We only need the format, sample frequency or event interrupt and what physical property they measure. And some other stuff.
We just need to know what kind of thing they measure and how it's data is formatted. This is easy to make an implementation of.

Front camera and touch screen are both 2D array inputs.
One has 3 components per pixel and the other one has 1 component per pixel.

Let's see for the other ones
The RF stuff are positional thus like audio except up to 6 components and usual very low sampling frequency. But then again there is multichannel audio or what if I want to use 6 microphones in sync?

Audio: Microphones, Accelerometer, magnetometer, gyroscope and barometer only differ in the number of components one sample has, sample frequency and the kind of thing they measure. The three mentioned properties describes most of them already in a way that you can just ask all of the sensors and only use the one you want.

Maybe the kind of thing some input device measures should be best done with a set of default set of string names and extensibility in the way that the api permits custom names (for custom hardware).

Fusing would be done with these layers that were mentioned.

Gedolo

05-09-2012, 02:26 PM

And for sensors and stuff of course a way to implement in drivers and able to ask in applications the units in which something is given.

getMeasureUnit();
or a function like that.

(I'm sure there is a better name for this.)

Gedolo

05-13-2012, 09:41 AM

Also a screen and a sensor matrix for a touchscreen can form a touchscreen.
With StreamInput we should be able to.
Set data to the screen and get the input matrix data.
Discover if they form a touchscreen.
(What if I have a screen and a second screen which is a touchscreen connected to my computer device.)
I need to be able to get information about relations.
There was this thing for hat named a triplet:
[first object][second object][relation]

For my example, with some madeup names:
[screen2][touch2DArray1][touchscreen]

Being able to have grouping of devices into other devices would be really handy.
Having some hierarchy can make things more organized.
(Being able to do device fission and device fusion with names and a default way to get/set subdevices would be really flexible and there for neat.)