Posts by philbearman

I only use Go To when I'm programming, not during shows.

Most of the cuelists that I create are timed to music with many 'Wait' cues,

So in the example above, if I wanted to edit cue 17, I would use 'Go To' to jump to cue 17, so that I could see how the lighting looks at that point without having to wait for ~2 minutes for the cuelist to play, and then 'Edit in programmer' to make the changes to cue 17, then update.

I'll create a bug ticket

Hi guys,

I've noticed a cuelist behaviour that seems incorrect, but I just want to check that it's not intentional before I report it as a bug.

I have a cuelist (we'll call this the master cuelist), and within that cuelist, I am triggering some other cuelists (we'll call these sub-cuelists) using the 'Go' and 'Stop' special cues.

If I use the 'Go to' function to jump to a later point in the master cuelist after I have triggered a 'go' and then a 'stop' on a sub-cuelist, that sub-cuelist remains playing when I believe it should be stopped.

Is this behaviour of DMXC3 deliberate, or is it a bug?

So in this example above, if I "Go To" cue 17, I would expect the 'Petro Alts' and 'Petro Zips' cuelists to be stopped, but instead they are running.

If I play the cuelist from the start, they behave as expected.

If this behaviour is intentional, can you explain the thinking behind it so i can understand why it happens.

Thanks,
Phil

Hi JP, thanks for your reply - that's useful to know.

I didn't realise that was possible to just restart the GUI on its own. (The crash happened in the middle of a song in the show, so I waited until the song had finished and then restarted as quickly as possible before the show continued).

I've never really spent any time learning about how the kernel / umbra / GUI architecture works, or the associated command line controls, so I will go to the wiki and do some reading

Hi guys, I posted a bug report a few weeks ago, but it hasn't received a response yet.

I'd be keen to know what caused this fatal crash in DMXC3 and whether it could have been avoided as it caused a tricky/awkward moment during a live show when I had to restart DMXC (meaning all the lights went out temporarily!).

Has anyone else experienced this, and do you know what would have caused it?

Here's a link to the bug report:

FS#5516 : DMXC3.3.0 crash (transport connections?)

Thanks,

Phil

Ah ok, thanks for that information.

Hi guys,

I'm trying to run a piece of software which is controlled via Art-net on the same computer as DMXC3. It appears that DMXC3 is already binding to port 6454 for input even though I'm only actually using DMXC3 for output, which means my other piece of software can't bind/listen for the Art-net output from DMXC3.

Is there any way of disabling Art-net DMX input in DMXC3 so that the port is available for my other software to bind to?

I have two Art-net interface instances configured, each one outputting a different universe. DMX-In is not enabled on either interface.

My knowledge of how Art-net works is a bit limited, so please excuse me if I've misunderstood how this works!

On the same topic, is there any documentation available for the latest Art-net plugin?

In particular, I'm interested in what the "Force broadcast" and "Additional Send to IP (optional)" fields in the interface are for?

Any help much appreciated,
Phil

No the CCT channel completely overrides whatever colour is set using the RGABL channels, as soon as the value is 10 or higher it is white light at the selected colour temperature.

This is what makes it particularly strange, is that you can also select these CCT white colours using the macro, so this channel seems completely redundant!

(It does seem strange to me that you're able to select CCT colours on this fixture both via the macro channel and via the CCT channel )

Hi guys,

I'm trying to write a DDF for an RGABL parcan that has channels for the RGBAL mixing, colour macros, and colour correction (CCT), and am unsure how to configure the DDF for the CCT.

In the DDF manual it says The "Color Temperature" function should not be used if white tones are stored in a device in the form of color macros and thus only either color mixing via the color wheel or the selection of a preset white tone is possible.

Which I think applies to this fixture? But I'm not sure what this means...!

How would you recommend that I accomodate this in the DDF?

Brilliant!

This made me smile today I'm guessing this is a little easter egg for the month of June (unless I've just not noticed it before!)

Thank you for the explanation JP 🙂

Ah, that's fixed it!

I didn't realise that "Stop and release" means the release time is ignored

Thanks for your help!

Hi guys,

I have a cuelist with a single cue in it which contains a capacitor effect on the dimmer of a group of lights. The cuelist has a release time of 1s, and is set to "release at end: Manual Only". We'll call this cuelist B.

Cuelist B is triggered from another cuelist - Cuelist A using the Special>CueList B:Go and then stopped using Special>CueList B:Stop and Release.

However, when Cuelist B is stopped from Cuelist A it doesn't use the release time that I set - it just switches off instantly.

If I stop Cuelist B manually it fades out over 1 second as expected.

Can you think of any reasons why the release time wouldn't be respected when triggered from another cuelist?

Hi guys,

I'm using DMXC3.3.0 and I've noticed the following error is appearing in the kernel constantly:

09:01:51 ERROR ArtNetFactory - ArtPollReply shorter than 198 bytes, ignoring!

This error also appeared:

09:04:51 ERROR ArtNetFactory -
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at org.dmxc.lumos.Kernel.DMX.ArtNetManager.BuildArtPollReplyPacket(Byte[] ownIp, Byte[] ownMAC, String shortName, String longName, Int32 portNr, Byte net, Byte subNet, Byte sendUniverse, Byte receiveUniverse, Boolean isOutput, Boolean isInput) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 550
at org.dmxc.lumos.Kernel.DMX.ArtNetManager.ProcessArtPoll(Byte[] packet, IPEndPoint receivedFrom) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 703
at org.dmxc.lumos.Kernel.DMX.ArtNetManager.client_receive(IAsyncResult res) in D:\Jenkins\workspace\Lumos_DMXPlugins_Pipeline_3.3\ArtisticLicenseArtNet\src\ArtNetManager.cs:line 877

I have two ArtNet outputs set up, one outputting to universe 0 and the other to universe 3.

I have Resolume Arena running on the same computer, set up to receive on ArtNet unvierse 3 via localhost, and Capture visualiser on another computer on the network set up to receive on universe 0.

Can you tell me what these errors mean and why I might be getting them?

Any help much appreciated.

Cheers,

Phil

The timecodePlayer is by far the most exciting & useful new feature for me, but I understand that the issues with scrolling/zooming the timeline won't be resolved until the TCP interface is rewritten using a new framework, which I imagine is a big task.

Until this is improved, I find it quicker to navigate the audio using other software and then enter the timecodes for cues into the cuelist manually rather than use the TCP interface (which is what I do in DMXC3.2)

My question is: is this interface rewrite something that is currently in progress for the main release of 3.3, or will we have to wait for a future release for this?

Thanks again for all the work you guys put into this software.

I've just had a look at the DMX output values and can see that the output is smooth, so I think the problem is with the moving light rather than the software. I'll speak to the manufacturer.

Sorry about that!

Hi guys,

I'm using some moving lights with 16-bit pan/tilt resolution.

I've noticed that when I use effects such as Sinus or Triangle to control the movement and the speed is very slow, it becomes very jerky - it looks like it's only being output in 8 bit resolution, or maybe the effect output is only being calculated and updated every half a second

If I create a similar speed of movement with cues the lights move very smoothly, so the device DDF is definitely configured correctly for 16 bit.

Do you have any idea why this is happening and is there a way to fix it?

All the best,

Phil

Thanks guys, that’s great!

Hi guys,

Is it possible to install DMXC3.3 alongside DMXC3.2 on the same computer, so I can continue to use 3.2 for shows until a stable version of 3.3 is released, but am able to test out 3.3 when I'm not doing real shows? (I don't need to run both versions at the same time).

I specified a different folder to install 3.3 into, but I'm only able to launch 3.3 from the Start menu - 3.2 has disappeared.

All the best,

Phil