Posts by PeterN

That's it! Thanks Ryan. Ok, next question then... what do the XYZ values you get mean when you select the MArker parameter and enter the ID? Why do the XYZ values default to something other than 50, 50, 50? It also seems like X and Y are centered at 50 with any other value offsetting but Z starts at 0 instead and offsets up from there (or maybe I've got it wrong again?). If you had tracking data coming in for a point and you wanted to offset below that is that possible?

I'm trying to follow the instructions for XYZ programming here https://help2.malighting.com/Page/grandMA3/xyz_marker/en/1.8 but I keep getting this behaviour where the lights just point off in another direction. Any ideas? What am I missing?

The mover (a Viper in this case) has had XYZ turned on for both modes.

The markers are in Still mode with positions set using setup in the 3D window.

If the markers aren't in Moving mode I wasn't sure if the Space option made a difference so have tried with two options (it makes a difference but neither looks correct).

So something we can expect to see in the future?

From the difference between these two doc pages it seems like the ability to call gels by key was removed:

Gel Keyword - grandMA3 User Manual - Help pages of MA Lighting International GmbH

Gel Keyword - grandMA3 User Manual - Help pages of MA Lighting International GmbH

Testing in 1.6.3.7 confirms that 'At Gel "Lee"."201"' doesn't do anything.

Am I just doing it wrong or is this really no longer possible? If so what's the reasoning behind removing this capability? I appreciate it's possible to do 'At "Lee"."Full C_T Blue"' but that would require both knowing the name of the gel when most people just know the numbers and going to the keyboard.

Seems like it would be awesome if the conversation went:

LD: Can we try those in L201 please?

Programmer: Sure. (Types 'At Gel 7.201 please')

LD: Nah, maybe L202

Programmer: (Up arrow, right arrow, oops, 2, please)

rather than:

Programmer: Gimme a sec... (Opens swatch book, scroll to lee section, scroll down to find 201)

LD: Nah, maybe L202

Programmer: Argh I just closed the swatch book. (Opens swatch book again, scroll to lee section, scroll down to find 202).

A bit exaggerated maybe and the syntax without the quotation marks isn't very consistent with the rest of MA3s syntax but something to make this quick and easy for theatre LDs would be nice. Tips or consideration for some way of doing this in future versions appreciated!

1.6.3.7

Thanks for the swift reply Andreas. I should have been more specific with where the numbering difference was (particularly with the slightly blurry edge of the photo). It took me a few minutes to get from FOH to backstage so that accounts for the difference in the current cue and scroll position of the sequence sheet.

As it should have been/was FOH/was outputting:

139 - Blackout

140 - Runyanland

141 - Scene 7

142 - Marching band

143 - Return

144 - Guys and Dolls

145 - Finale

As it was on the DSMs laptop:

139 - Blackout

141 - Runyanland

142 - Scene 7

143 - Marching band

144 - Return

145 - Guys and Dolls

145 - Finale

We came across a strange bug during a show this afternoon that the dev team might be interested in. The setup was a PC FOH with a command wing, a laptop also FOH with a viz key and a third laptop backstage (with priority 'Never') logged in as a different user for the DSM to be able to see the cues. Towards the end of the show the DSM notified us that the numbers on the cues were different to what he had in his script. The first picture is from FOH where the numbers are correct. Going backstage (second picture) the cue names are correct but the corresponding number are not. Leaving the session and rejoining didn't help. Restarting the DSMs laptop didn't help. In the short gap between shows we reinstalled MA3 on the DSMs laptop (didn't seem to help) and restarted the FOH main and backup PCs. The thing that seemed to help (although might be coincidence) was we disconnected from the network, deleted all the saved show files and backups on the DSMs laptop and then rejoined the session. At this point the cues were correct.

Having fixed the issue I now don't have a broken show file to share but hopefully the heads up helps others spot the issue in the future.

Hi, I'm trying to use a bunch of series 2 lustrs in mode 3 and I'm not able to use the colour picker as it's entirely unresponsive with a lustr selected. I'm patching them as HSIC - Strobe on - Fan Auto. I've tried editing the fixture type by changing HUE to HSB_Hue and SATURATION to HSB_Saturation but this just results in an instant crash when trying to use the colour picker. I've only tried this fixture editing with onPC. I can try it on a full sized tomorrow. Anyone had any luck/have any advice with using series 2 Lustrs with MA3? Sadly going into direct mode isn't really an option as we've got Lustrs from different manufacturing batches so the colours are quite significantly different when not in a calibrated mode (the recommendation to avoid direct mode comes straight from an ETC rep).

Thanks!

Yeah, that's exactly it - thanks! That's nice that it's not going to spam the command line with messages. It's still doing things in the wrong order if the two messages are received within about 0.03-0.04 seconds of each other though.

Honestly, this is the method I'm using as it's the one I've been able to get working! I've not been able to work out how to see a schema for the OSC addresses on the desk and I can't find docs online so I'm just using /cmd from the example on the OSC doc page. Very open to changing though. The advantage of using Press over directly targeting a function is that way I can reassign the function just like all the other executors so other than not being able to type commands and hit the button (eg. Store <hit the button you want to assign the sequence to>) it acts just like another xkey. If it were possible to do something like "/Page2/Key291,s,Press" that I'm just not aware of then that would be neat.

Good idea. Here are the timings from the System Monitor. The first key press down and then up worked fine and in the system monitor they appear in the order:

1. OSCReceiver - Press

2. MainTask - Press

3. OSCReceiver - Unpress

4. MainTask - Press

It doesn't work when the order is:

1. OSCReceiver - Press

2. OSCReceiver - Unpress

3. MainTask - Press

4. MainTask - Unpress

So maybe this is a bug when two OSC commands relating to the same object arrive before the first one can be processed?

I've got a setup where MA3 is receiving OSC commands to press and unpress buttons and I'm running into an issue where it appears that incoming commands aren't being applied in the right order. For example, in the attached image you can see a number of Press commands and then the corresponding Unpress commands. However, executor 197 is still on even though the command line shows it should have been turned off. Has anyone else come across this/anyone from MA know how to prevent this from happening? Thank!