Fixture Light4Me 10 eye Led

Hey,

what in detail is your problem!? Do you have general questions how to create the fixture type or is it about the two different Tilt Movements?

Cheers,
Lars

Hey,

what you basically need is a Fixture Type which consists of four instances:

1) Pan & Tilt
2) Tilt 2
3) General control functions like Dim & Strobe
4) LEDs

Then you can create instances of the module one and two, one instance of module two and 10 instances of module three. Please make sure that you've created and adressed the instances. Just by creating the module this will not work and you will get the blank fields again.

Hopefully this helps!

Cheers,
Lars

Depending upon the .XML profile and how it's written, I would say you'll need a Main Module with PAN and the other master controls. Then 2 TILT modules that you would build with TILT and whatever controls they get as masters. Then a RGB Module that 5 instances will parent to TILT1 instance and 5 instances that will parent to TILT2 instance. You'll be parenting a module to a parented module; good luck with that. This all depends upon how the .XML and fixtureProfile is structured. I've put 5 TILTING DIMS on a single PAN fixture, so I know this is possible; it's in the fine details of a fixture I've never physically seen before is the unknown part. This will take hours to proof out...but the fixture seemed simple enough to figure out and get rendering. Just getting the profile working on the actual fixture will take some doing, let alone building the 3D models to accomplish a double parent.

Good luck!

heyho!

thanks for your comments @Rex. You're probably right if you want to visualize the fixture in dot2 3D with a custom made body. But to control the fixture in real world there is no need to connect PAN and TILT2. This should work fine without a connection...

@nasula: Have you tested your Fixture Type with the real Fixture? Because if you want to visualize this Fixture in dot2 3D you need further knowledge about creating 3D models....

Cheers,
Lars

Johannes: Indeed you are correct for getting the profile to control the fixture on the stage...I speak for the MA3D visualization which, I think, most folks really want as well as the fixture controller information. Also, my opinion, that profiles should be written to be as 'visualizer-friendly' as they can be. You perhaps may not always have access to a shop with spare fixtures lying about. MA3D is the next best thing...

Also, a question about the way this OP fixture's DMX chart is structured and how do you cope with this situation, in the actual .XML and that goes a long way in helping me determine the visual side of things. The fine resolution DMX data is separated from the low resolution DMX data by another attribute/channel and not just an extension of the range. It's an extension of the range as well as a different index position and that confuses me. Do you double up the low rez data with fine rez into the first Channel of PAN because you can't specify a duplicated attribute, use a 'dummy'/virtual channel, or something equally swanky/clever? It seemed very strange to see this fixture's DMX chart structured in this way; unlike most 8bit/16bit channel profiles. I'm always trying to determine between what the fixture needs to see in the way of namingConvention compared with the straight DMX links. I assume most of the names are for the console side of things...not necessarily what the fixture on the bench needs to function properly?

Thanks!

First of all all the names are part of the console side. The Fixtures just need DMX data on the correct channel.
But I don't really understand the rest of your question...can you please explain this a little bit more!?

Which DMX Chart and which xml-file do you refer to?

Cheers,
Lars

The instance order can be as you like; IE, how it appears on the fixture's head. There is no instance builder in the fixture builder. You'll have to hand edit the .XML profile to build the array yourself. There are differences in default models and custom models, in the way the instance array is written.

For example: Here's the simplest of arrays.

<Instances index="1">
			<Instance index="0" module_index="0" />
		</Instances>

It describes a single instance of the first[0] module described in the Module index to render.

Most fixtures consist of more than one module. To that end a second module_index is added. The descriptions for modules is above the Instance array, which is logical.

<Instances index="1">
			<Instance index="0" module_index="0" />
			<Instance index="1" module_index="1" />
		</Instances>

This instance array describes 2 instances to render, a single instance of module#1 and a single instance of module#2.

This paradigm continues on. Describe the module and it's functions, then lower describe how many and where to render them. Things get more complicated with multi instance fixtures attaching[parenting] to other modules. You then need to assign PATCH data, POSITION data, and PARENT data for things to render correctly.

So, to continue for your example. Your instance array may end up looking something like this:

<Instances index="1">
			<Instance index="0" module_index="0" /> = Main Module wPAN/TILT1+other Master Functions,no patch specified: default= 1, no position specified: default= 0,0,0
			<Instance index="1" module_index="1" patch="blah" parent_instance="0" /> = TILT2 Module connected to Main Module @ 0,0,0 start patch with first function
			<Instance index="2" module_index="2" patch="blah" X="0.120" Z="-0.226" parent_instance="1" /> = RGBW Module connected to TILT2 Module @ X,Y,Z CH10
			<Instance index="3" module_index="2" patch="blah" X="0.060" Z="-0.226" parent_instance="1" /> = RGBW Module connected to TILT2 Module @ X,Y,Z
			<Instance index="4" module_index="2" patch="blah" Z="-0.226" parent_instance="1" /> = RGBW Module connected to TILT2 Module @ X,Y,Z CENTER-NO X NEEDED
			<Instance index="5" module_index="2" patch="blah" X="-0.060" Z="-0.226" parent_instance="1" /> = RGBW Module connected to TILT2 Module @ X,Y,Z
			<Instance index="6" module_index="2" patch="blah" X="-0.120" Z="-0.226" parent_instance="1" /> = RGBW Module connected to TILT2 Module @ X,Y,Z CH6
			<Instance index="7" module_index="2" patch="blah" X="0.120" Z="-0.171" parent_instance="0" /> = RGBW Module connected to TILT1 Module @ X,Y,Z CH5
			<Instance index="8" module_index="2" patch="blah" X="0.060" Z="-0.171" parent_instance="0" /> = RGBW Module connected to TILT1 Module @ X,Y,Z
			<Instance index="9" module_index="2" patch="blah" Z="-0.171" parent_instance="0" /> = RGBW Module connected to TILT1 Module @ X,Y,Z CENTER-NO X NEEDED
			<Instance index="10" module_index="2" patch="blah" X="-0.060" Z="-0.171" parent_instance="0" /> = RGBW Module connected to TILT1 Module @ X,Y,Z
			<Instance index="11" module_index="2" patch="blah" X="-0.120" Z="-0.171" parent_instance="0" /> = RGBW Module connected to TILT1 Module @ X,Y,Z CH1
		</Instances>

This is conceptually how to construct the array for a decent visualization. With default models it will look horrible because of the 2 default Headmover models. This is where custom models come into the picture. You create the shapes you need to point to. This goes a long way in creating a reasonable visualization to base programming upon.

Good luck!

Rex

PS: I hope this helps. With the parent_instance=, you'll need a custom model constructed correctly for the Class of fixtureType. Not exactly sure how you'd parent 'default' models together like this...I think they'll default parent to the main module and that's not what you want rendering... That's a question for Lars!

Yes, I have gotten very close to a visualization. It will need a custom Headmover model, custom TILT2 model, and 2 types of LED model due to parenting a Headmover to a Headmover.

The first Module has 4 DMX channels, Pan and Tilt1 both in 16bit resolution so the next Module is starting at channel 5.
If you have unused channels in Main Module then you can use a Dummy channel for this (Control > Dummy)

Perhaps so, Nasula. I did combine the fine rez with the low one in the single attribute channel as Go-Button suggests because I have no experience in doing it 'split'. I was unaware that you need to fill the empty spaces with a 'dummy'...but I still don't 'get it'. This is not an 'unused' channel it's a split channel. I usually need a visual example to make sense of things.

With instances it's tricky with patching for me. You can use absolute patching in the module and leave the patch assignment out in the instance definition or you can define the attributes and then use the instance array to patch the sub fixtures. I struggle sometimes determining the route to the solution with patching.

PS: yes, I'm following along, ;). I do with many Threads/Posts at both forums, MA2 and DOT2

I have problems with Fixture Builder 1.31 and my laptop as well. I create a profile, try to export to .XML and get a CTD/assertion error. This didn't happen with all other versions of Fixture Builder?? Only 1.31 doesn't work on my laptop which is odd because my studio machine is Windows 7 as well....and V1.31 works fine...exports .XML files.

I work in previz with MA2 and use DOT2 for testing fixtures and as free universe if needed.

Hey everybody,

to push this into the right direction I would suggest that @nasula sends us the DMX chart of the Fixture Type which he needs. We will create it an provide it to all of you!

Cheers!