iotpanic / pixelpusher Goto Github PK

General question: Is that abstract enough to also work for a dmx controller?
For now in the proto everything is matched for the use case of led stripes using udpx.
Do we create another kind of schema for different kinds of controllers or make this schema so abstract that it can serve for both?

We should be clear about naming here:
If we call it "device" it has the same name as the "devices defined in software" part of my concept -> we should name one of those two things different, so:

Example:

• A "controller" is a hardware device
• A "device" (which exists only my frontend) is the mapping from the functionality of a stripe to a part of the controller.
  Example: "My stripe" has 144 Pixels reserved in pixeldot-1 controller's first channel from postion 10 to position 155"

Chrome App is a wild try to make UDP and compression work without the need of usIng a nodejs backend.
Branch: feature/tv-chrome app

cC @hputzek @iotpanik

UDP is already working. Compression with JavaScript works too but is not fast enough to send more than 5 Fps with 484 pixels. I don't think is worth adding it unless we find a faster way to implement it (web assembly?)

If that is efficient enough we can use this as a proof of concept and make a branch in the tester to see how that works out.
Note that there a few quirks that need tonne take in account when making an app. For example you cannot use eval() or Function unless you put that part in a sandbox. Doing that will let that work but has the undesired effect that loading a video will fail unless it is send with the right allow origin CSP so I would have to serve it with apache or a php wrapper. But that's still ok as long as is transparent for the user.
The mission of this whole thing is that the user gets a no brained one click install thing without needing to install or setup anything.

I will be only 5 days more working on this and submit it next Friday to Chrome web store.

Maybe we should allow for 1-4 color values per Pixel but not call them "rgbw"?
Because there can be the case that you want to control a "warm/cold white" device which would mean you got two color values.
Or warm/cold/amber instead of "rgb"

Is it possible to just define it like that in the enum?:

enum MatrixType {
    WHITE = 0;
    WARM_COLD_WHITE = 1
    WARM_COLD_AMBER = 2
    RGB = 2;
    RGBW = 3;
}

One more question: You could use the constants from the enum instead of the numerical values here?:
https://github.com/IoTPanic/pixelpusher/blob/master/protobufs/api.proto#L33

This would make it more readable, so if this works I would <3 it.

Ok, this is a bit complicated, so I hope I don't loose you on the way with my explanation :-)

a matrix can be a single dimensional array longer than one to represent a LED strip, a two dimensional array to represent a true LED matrix, and a 1x1 "matrix" to represent a single off LED light. Each of these can be one of RGB, RGBW, or jjust white. A single white 1x1 matrix is assumed to be a strobe light.

I like this idea. Although I guess in the frontend I'll abstract that away a bit by offering the user options to add "software defined devices" of the following types:

• general Light (can be w/rgb/rgbw etc...) means one pixel; can be used for strobe, too
• Stripe (white/rgb/rgbw...) means 1*x pixel
• Matrix (white/rgb/rgbw...) means x*x pixel

Actually I should additionally make it possible to define matrices in the software.
So when I send a frame it looks like this:

const singleFrame = [
// each object is a software defined device (stripe)
{id: 1, data:[r,g,b,r,g,b,r,g,b....]},
{id: 9, data:[r,g,b,r,g,b,r,g,b....]},
{id: 3, data:[r,g,b,r,g,b,r,g,b....]},
...
]

Does that make sense? Because if I define the matrix in the software the workflow could be:

• Select multiple stripes in the 3d representation
• and combine them into a matrix

I see the advantage that one single matrix could contain stripes from different controllers/channels/device types.

So I see advantages in both attempts:

Your proposal:

• makes it easy to define a matrix very quickly
• very helpful if you want to add a matrix hardware like Martin has because you just have to set the dimensions and you're done.

My proposal:

• you got to create/combine the matrix out of several stripes youself BUT the matrix can emit to multiple controllers/device types this way
• helpful if you want to do the following: A wall of your room in the 3d representation has 20 stripes attached to it. Their layout on the wall would be like this:

 -----    ---------    
           -----------------      --------------
    ----------     -------------      ----------------
   ------------      --------   ----------------
 -----    ---------                                 ------------
           -----------------      --------------
    ----------     -------------
   ------------      --------   ----------------

Now I can create a matrix out of them and map video on them which takes into regard the position of those stripes on the wall. (Videomapping)