Translate R-G-B-virtual I to SPI RGB?

[Scott Snowden]

Hi Folks,

Just wondering your thoughts about translating RGBI at the console to RGB at the LED (SPI) end?

Specifically, would it be feasible to code something for a Raspberry Pi receiving Artnet or ShowNet that would convert incoming DMX in the form of RGBI (or IRGB) to pure RGB values (with the I scaling applied) being output to an SPI strip?

An up-to-date console such as GrandMA can internally create a virtual intensity channel for pure RGB fixtures, but older consoles such as a Strand 5xx cannot.

Cheers,

Scotty.

[Sean Sill]

Definitely feasible. I want to see what others think. I kinda feel like this should be a client but it would be easy I think to add a personality that allowed this.

[Simon Newton]

What is RGBI, and can you explain how 4 channels map to RGB?

Simon

> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Sean Sill]

He wants RGB plus Intensity. Where the actual RGB levels output are grandmastered from the I channel basically.

I = 50%, R = 100%, G = 100%, B = 100%

So Actual output of spi would be 

R = 50%,  G = 50%,  B = 50%

--

Sean Sill
Electrical and Computer Engineering Alumni from
Missouri University of Science and Technology(Missouri S&T)

[Peter Newman]

This looks to me like another good fit for patcher V2 when it arrives:

https://code.google.com/p/open-lighting/issues/detail?id=279

Some fixtures would have it built in, and I guess if it's done at the fixture level it all tracks and changes as you change the address/number of channels etc, rather than having to manually update something else too.

[Scott Snowden]

Sean's summation is exactly what I'm talking about.

The patcher v2 summary doesn't exactly cover RGB(i) to RGB but I notice Peter has now expanded patcher's scope to cover it.

Happy to help make it happen.  I've got a bit of programming experience as well as some useful lighting hardware.

[Peter Newman]

What a few of us had been discussing was something more generic than just patching, essentially a set of filters you can stick in between universes (similar to the video filters you can add to process video with ffmpeg/ffmbc), I guess at a crude level, they'd appear as other plugins with pairs of input and output ports, but hopefully we can do something nicer with how they're presented/used. Adding a virtual dimmer was one of the use cases I'd thought of for them, channel shuffling, as the original bug report talks about, but also things like top setting so you can't go above x%, or scaling, so 0-50% on input maps to 0-100% on output. When you've got the framework in place, adding another simple transformation becomes trivial. The challenge, as always, is how you present it to the user to make it easy and user friendly to configure and use, while still being flexible.

[Stefan Krüger]

which user 'interface' did you mean?
the web?
or text / file ?

for web i would love to have something similar to the visual part of http://noflojs.org/example/.
i found a javascript library that makes something like this possible:
http://jsplumbtoolkit.com/demo/flowchart/jquery.html
if i find some time i will try to setup a example...

the other side is - how to get this configuration in an readable way stored? if i rememer correct there is a text-format for the patching..
is it possible to build on top of this?

[Simon Newton]

On Wed, Dec 25, 2013 at 4:34 AM, Stefan Krüger <ste...@s-light.eu> wrote:
> which user 'interface' did you mean?
> the web?
> or text / file ?
>
> for web i would love to have something similar to the visual part of
> http://noflojs.org/example/.
> i found a javascript library that makes something like this possible:
> http://jsplumbtoolkit.com/demo/flowchart/jquery.html
> if i find some time i will try to setup a example...

Yeah, drag and drop UI is one of the goals for patcher v2. I've been
holding off because E1.33 will probably dictate changes in OLA's
universe model and I didn't want to end up re-writing everything
twice.

>
> the other side is - how to get this configuration in an readable way stored?

Have a look at https://github.com/OpenLightingProject/ola/blob/master/include/olad/Preferences.h

[Peter Newman]

On Wednesday, 25 December 2013 17:18:22 UTC, Simon Newton wrote:

On Wed, Dec 25, 2013 at 4:34 AM, Stefan Krüger <ste...@s-light.eu> wrote:
> which user 'interface' did you mean?
> the web?
> or text / file ?

Either really, but even in the text file, which can probably be more crude than the web interface, if we take the original example, you may want IRGB or RGBI; the fixtures may be sequential, or spread out across a universe. You could have 8 or 16 bit intensity (although I guess 16 may be irrelevant if the RGB isn't 16, and if it is, the fixture may well have a dimmer channel). It's how you present those options, probably with global and/or per universe defaults, without the text file becoming an unreadable mess. Then as you've pointed out, you've got the patching aspect; does the filter get applied in the internal OLA universe, or as a separate plugin with input and output ports, so you'd go say ArtNet 1 -> OLA 1 -> Filter -> OLA 2 -> ArtNet 2, in which case you need to show that in an understandable way.

On Wednesday, 25 December 2013 17:18:22 UTC, Simon Newton wrote:

On Wed, Dec 25, 2013 at 4:34 AM, Stefan Krüger <ste...@s-light.eu> wrote:
> i found a javascript library that makes something like this possible:
> http://jsplumbtoolkit.com/demo/flowchart/jquery.html
> if i find some time i will try to setup a example...

Yeah, drag and drop UI is one of the goals for patcher v2. I've been
holding off because E1.33 will probably dictate changes in OLA's
universe model and I didn't want to end up re-writing everything
twice.

That looks awesome! I appreciate what Simon is saying, but given the way E1.33 seems to be dragging on, if you fancy it, even just doing a read only view of the current patch would be neat.

 
On Wednesday, 25 December 2013 17:18:22 UTC, Simon Newton wrote:

On Wed, Dec 25, 2013 at 4:34 AM, Stefan Krüger <ste...@s-light.eu> wrote: 
> the other side is - how to get this configuration in an readable way stored?

Have a look at https://github.com/OpenLightingProject/ola/blob/master/include/olad/Preferences.h

I do think we need to look at extending the preferences system somehow to cope with key, key, value settings, like the SPI stuff, I wonder if it's worth stealing from/adapting Java, <device>.<option> = <value>, we could also go deeper <device>.<group/uni>.<option> = <value>.
 

[Simon Newton]

Agreed. I had this grand plan of rich schema, and then being able to
auto-populate the web UI based on the schema. The idea was to define
the schema for the settings similar to how we do RDM messages today
and then everything would just appear (web UI, command line tools,
defaults in the .config file etc.

We'd want the schema to be exposed as a json interface so I need to
finish reading my latest book on RESTful APIs before we can start
pulling this all together.

It's even listed as a GSOC project:
http://www.opendmx.net/index.php/OLA_SOC_Ideas_Page#Web_Based_Configuration_of_Preferences



Simon