DMX/Fixture Framework

vvvv beta question
1

helo DMX people, helo master kalle,

triggered by TheSeven on irc, we implemented a simple proof of concept dmx/fixture framework using the advantages of VL. but we’re not really familiar with the needs of dmx/fixture people, so please have a look at the proposal and comment.

i remember @kalle)) started something like this some years ago ((kalle.modules.dmx only now with VL this can be done more conveniently.

the main ideas are:
• similar to the demo fixtures A and B we could build a shared library of all the available fixtures. ie, one vvvv node per fixture.
• the group node takes multiple fixtures and joins them to one, like this endless cascades can be built.
• a Fixture2Bytes node convertes all fixtures to a dmx-universe. its output can be converted to RAW to be sent via udp…

questions remain:
• is that useful? or is the concept fundamentally flawed?
• is any fundamental node missing?
• any naming suggestions?

also if anything is unclear about this approach or the use of VL, please let us know.

requires latest alpha to test

DMX.zip (8.6 kB)

2

Hi Joreg,

first of all: Thanks for picking this up!

I’ve wondered about how something like this could be done for years, and now, with VL, we finally have the required technology in place. :)
These nodes will definitely simplify some of my patches quite a bit.

Some minor nitpicks, where there could still be room for improvement:

  • The likely most common way to send out the generated DMX data is via ArtNet. There’s a DMX Artnet Sender node for that. However that node expects values ranging from 0 to 1, and multiplies with 255 internally. It might make sense to adjust the Fixture2Bytes node to output such values for consistency (or build another Fixture2Value/Fixture2DMX/whatever node with that behavior).

  • DMX addresses are usually 1-based, so the first byte handed to the ArtNet Sender node will end up on channel 1. Subtracting 1 from the address pin on the fixture node might be an option, but I’m not sure if it is a good idea.

  • There seems to be a flaw in the Group node, imagine the following:
    ** You have 4 fixtures: A at address 10, B at 20, C at 30, D at 40
    ** You group A and C together, and B and D together
    ** Then you group the results of those two together, and will end up with the channels of fixture C being overwritten with zeros.
    ** This happens because when grouping fixtures, the result is one big fixture which spans the whole address space between the lowest and highest address used by its inputs.

  • I can think of two approaches to fix this:
    ** Keep track of the actually used channels as a bitmap (performance/complexity hit?)
    ** Do highest-value-takes-precedence mixing of the channels in the group node (commonly done by DMX software and lighting consoles)

3

Hi joreg & TheSeven

Dmx boy around :)

in terms of structure there is a lack in programming easely something to manipulate in LTP mode the fixture.

i would add the possibility to re route parameters entries from another group node

manipulating colors of fixtures is ok in the demo, if it is separately done.
But to override this first data, and manipulate from group structure colors of all a group, it is not present actually in the demo.

Groups should be able to be splitted in nodes ( Group 1, Group 2) with same general entries as fixtures

In a concert, you will use on the fly hability to activate and manipulate groups or solo mode, in order to give the colors, patterns of moves, as you want, on the fly

BUT how to insert the LTP logic in the actual patching chain and usage ? (HTP is used only for diming, for moving heads you will need Latest Takes Preeminence)

For me it would be more interresting to create a group pin directly in the Fixture, changing the simple object from solo mode, where it will be manipulated from its input pins, to a group, where it will be manipulated by the object group.

and to have a node GROUP, that can manipulate parameters without links; with S and R nodes variables.

Like this, you can manipulate either from Fixture or from groups, and resolve LTP handling

here is a

4

snapshot of this idea:

5

you are right, the other vvvv DMX nodes also have 0-1 input… easy change, could just be another getter method on the channel that both options are available.

good input, we didn’t know that… but it should of course reflect the address numbers you see on mixing desks and lamp settings. so 1 based it will be.

the merging of fixtures is also a topic to be discussed here. its a quick and dirty example which only shows how it could be possible to join fixtures. the actual merging was not the main concern and it should of course work as expected that all data comes through. this could be solved in a way that the channel stores its address and the group merges on a channel level not an address range.

its more the question whether the grouping system itself makes sense to work with. or would it better to just join the fixtures in a spread like structure which keeps all original fixtures?

6

karistouf, if i understand correctly, what you are thinking about is some kind of preset system which makes it easy to switch settings?

and also some kind of manipulation of the color or other parameters on the group node itself. so that you can for example enable/disable all lamps in one group.

thats a good idea and we’ll think about it…

7

Heyho,

1st time i started a somehow-VL-thing! :D
but sorry, no time for diving into details :(

so here my very first fast impressions:

  • the outputspread of labels could grow to something useful.

else i didn’t see much what wasn’t easily possible before.
will send few patches this evening.
may have the chance to dig deeper later/next days.

Guys, if you really want to help ‘us’ DMXguys:

just make that subnet- and universe-pins of both Artnet-nodes
both

  • accessable as regular input/output pins
  • spreadable

as you have been begged for countless times by at least me, catweasel, (list of usual suspects)

now i try to write sth helpful for your understanding of DMXfixture usage:

speaking about e.g. MovingLights which may have a little more complexity

lets say we have
16 fixtures “CheapThing” with 5 channels (Pan/Tilt/R/G/B all 8bit)
8 fixtures “FancyBrand 3000”

“FancyBrand 3000” offers 3 different modes:
*Mode 1: uses only 9 DMXchannels but Pan/Tilt/Focus/R/G/B have only 8bit Resolution.
*Mode 2: 11 channels, pan/Tilt 16bit
*Mode 3: 16 channels, all Pan/Tilt/Focus/R/G/B 16bit

*one would always use all fixtures of same type in the same Mode
*one would always give them startaddresses like (offset + n x channelcount)
*“offset” is typical like 0, 100, 200
*one would never ever have overlapping channels within a universe

e.g:
“FancyBrand 3000” addressed like 0,11,22,33,44,55,66,77
(using 0-based counting here…)
“CheapThing” now starting at 100 : 100,105,110,etc.

so the guy hanging in the truss changing startadresses on that device doesn’t need to use a calculator to get the appropriate adress for “7th leftmost Cheapthing”

8

Hi Tonfilm, Hi Kalle !

Ok about Preseting things, we are talking about a framework, where there is 2 things:

  • Fixtures definition (channels, modes)
  • How to send them data (ergonomy with groups)

Fixture are at the far end of the VVVV chain. They receives positions, intensities, presets on generic functions ( pan, tilt, colors, focus, gobos…), and route them to the proper channels, with their start adress.
The demo patch is shown inverse ti what it should be: fixture receives and routes main data. They are not at the bottom, but at the end of the chain of orders.

As Kalle noticed, Fixtures are very different and needs at the end some common labelling to be used (certain moving heads have 36 parameters).

Be aware that any fixture will need peculiar corrections ( for a movement, the Fixture on the far left will need some peculiar correctors, very different from the the fixture in center, saying that the 2 are drawing the same movement on the floor. You will need to correct them).

What is interesting is to refer to the fixture with a4 ways approach.

This 4 way approach can be understood taking TimeLiner in mind, and controlling fixture on a show with 4 types of events, that we could control with Subgroups:

-1 / Enlightenment family: dimming, colors, light corrector and modes, strobe… (power on is utility and will not take place in a use with a timeliner for example)

-2 / Lens family: focus, iris, angle

-3 / Visual effect family: gobos, visual specific effects (rotating wheel)

-4 / Utility family: Correctors for movement when a fixture was not installed in the good way (missing 45°), for Power On, etc etc…

The 4th one will not appear in a timelin in the manner of a show.

So, continuying this reflexion about Groups, you will easely understand that i may need to use in a show: a Global group, that contains all parameters, and say that a part of the device will all move and light the same colored, way and 4 subgroups, that contains specific parameters i can change on the fly just to change the movement only, or the colors.

In my idea, a good structure to the device would so listen to 5 events:
Last General Group parameters, and SubGroups specific parameters of the 4 families.

The parameters will be LTP token, either from Group structure or Sub Group structure.

If one day i implement my whitecat it would be with this type of structure.

9

hey kari!

Subgroups, hhhm

@devs:
‘Groups’ in terms of lightdesks/ontrollers usually means sth like a temporary ‘selection’. (e.g. “All fictures on the left/right sidewings”
that somehow collides with vvvv’s terms…

anyway; speaking about those “Parameterfamilies”
sometimes you want to make presets which contain both Pan/Tilt and Zoom/Focus!
and sometimes you don’t…

really not funky that some manufacturer multiplexes things like “total reset” with other params onto single channels

regarding LTP, HTP:
I’d prefer configurable per parameter with 3rd option “Priority”…

10

+1 for Kalle about priority, this being for the entries

we can imagine Fixture as the 4 entries + one global entry, + priority for each entry

@devvvs, for the question is it necessary: definitively yes, if users may have a module that treats all of that instead of re inventing this complex wheel, yes !

Question: where can i find theVL-thing doc to explore how it works ?

i would be very please if finally we can have something to create exe from vvvv patch… hope hope hope

11

@kalle one detail regarding the modes:
do you think it would make sense to provide one distinct node per mode (per fixture? like:
FancePants3000 (DMX Mode1)
FancePants3000 (DMX Mode2)
FancePants3000 (DMX Mode3)
so that those are actually 3 different nodes with different inputs (and handling their channels internally according to the modes)?
i mean do you think this could be an universal naming scheme?

12

@joreg:
for me soounds more a kind of enum pin.

there is PLENTY different modes for different device, and series of devices.
mmodes are really VERY different from manufacturer to manufacturers

isnt it possible to think the fixture to be fully editable on 3 or 5 layers of channels customisable by user ?
if not you will spend a lot of time to create the fixtures for users

one BIG thing would be to have the possibility to edit completey the device from inside the FIXTURE.

Community could share fixtures

13

if you have en enum pin then you would need to change the input pins according to the mode… this is basically the same as having different nodes. apart from that its not really possible to change input pins according to an enum…

this is the point why we are doing this… so that everyone can make a fixture for a specific device and share that. we are only providing simple modules like color to RGB channels or pan/tilt to two channels from which the users can build their specific device fixtures.

14

Regarding the fixture parameters and modes, there are already huge libraries of fixture profiles that contain this data, written in a (faily) stand way for certain desks.

It would mean writing (and updating) a plugin that can parse these different parameters to be interpreted further down the chain to be used more universally. The DMX channels could be filled up by choosing the real fixtures from your profiles list.

You could then have odd fixtures and so long as they share the same parameter (for example ‘dimmer’) that feature would be selectable and they could be grouped together to, for instance, go to black.

Like someone else said, I would like to know VL has particular features that would help with interfacing.

15

@karistouf: getting started with VL: dynamic vl plugin reference

the fundamental point here: you were not able to join the different channels of a fixture to one datatype “Fixture”.

hmkay, i see we’ve accidentally used the term “group” which seems to have a different meaning in dmx-land. would you mind elaborating on that concept a bit? is there any online-documentation about this? also what did you mean with “Priority”?

can you elaborate on “selecting” and “grouping” here?

and good to see those fixture resources. so indeed it looks more like we’d just need a parser for those

not sure what you mean by that. please define: “interfacing”

16

to know the attributes of a device I use the library Avolites http://personalities.avolites.com/

These files can be analyzed to create the node as needed

17

merci joreg for the VL link !

@tonfilm: please it would be really better to AVOID having 3 or 5 different nodes for a single device.
I was talking about the enum access method : a pin enabling to select the mode of the device, with its internal routing of channels, is far more interresting than a big quantity of node, where you are lost as user at the end.
for me mode SHOULD BE treated INSIDE the fixture node.

@joreg: priority:

LTP (Latest Takes Preeminence) is the way you use usually moving heads AND video: last order is what has been sended. It s opposite to traditionnal Lighting, where with dimmers we use HTP method (Highest Takes Preeminence).
The HTP method is used in theatre, dance, and with classical dimmers: in a softawre or a lighting desk, merging is done from different sources: cuelist / faders / groups of channels. The HIGHEST will be outputted, essentially because on dimmers what is interresting is to FADE with sliders the lighting output. you dont want jumps of levels when moving one slider (a master) or another (cuelist state from memories)

LTP is different and is done genrally by calling many different data, fixtures can be manipulated from a global group, solo, or from different little groups.
But the LTP logic is what you are doing when designing a VVVV patch: change is done on last parameters receives.

by LTP we are talking of LIVE usage, and not timelines (where you will call certain temporary states to change your presets, avoiding any unwanted jump of parameters, seenable onstage).

To be simple, you may have for example pan and tilt manipulated by a pattern with an LFO, sliders (midi) or joystick, or pushing buttons to go to preset positions.

18

although Karistouf disagrees here:
Yes.
You will never change modes during show,
You will never use a mix of modes.
so there is no need at all to evaluate any mode-pin each frame…

if “user” gets lost in choosing the correct node (with the correct mode…) you can also expect him/her getting lost at that enum-pin (uääh; me still don’t trust in enums)
Furthermore i don’t even want to imagine how “user” configures the hardware itself…

exactly this is the perfect transition here:
@dear devs:
as this is clearly to be read in your statements above:
you are lacking even very basic knowledge about this field.
IMHO this is not the best starting-situation for being the 20th reinventor of the wheel.

but pls keep in mind:

Guys, if you really want to help ‘us’ DMXguys:

just make that subnet/universe-pins of both Artnet-nodes

both

  • accessable as regular input/output pins
  • spreadable

as you have been begged for countless times by at least me, catweasel, (list of usual suspects)

cheers
kalle

19

well, which is exactly why we are asking all those questions.

Fixture Definitions:

  • we learned that different file formats exist
  • in the end it seems we’ll want to drop a fixture-file on a patch and get the appropriate FixtureNode from it (consider this long-term)
  • apart from that you’ll still want a quick way to patch a fixture manually and that is what VL is already good at
    any objections to that?

Selecting/Grouping
Here is where it seems to us we’re still missing an understanding of a typical workflow. So please don’t stop trying to explain that part to us.

now here is a little update of our understanding so far:

  • replaced the Group node with a Merge (to universe) node.
  • proposed an UpdateChannel node that would allow to “select” channels by matching label-names and update all those “selected” channels with a single value (see comment in patch)
    @guest thats what we made from your “dimmer” example. does that make sense?

DMXFixtureFramework.zip (9.0 kB)

20

@joreg: merger approach is very right joreg.
approach of label name is really the right entry to handle a fixture.
bravo for VL !

@kalle:
what have you eaten today Kalle ??? hum ?
i m not saying that modes will be changed en route.
from your feedback i believe that you LOVE the HUDGE list in the node list.
i DO NOT :)

i let you in this discussion with master Kalle, if you need feedback from a light designer just ring me back, it will be with pleasure.