Neil Macmillan

I have been experimenting a bit with OSC and faced the issue of the software being recommended for windows being Show Cue Systems. While I have no doubt it's brilliant, for my limited requirements, it's a little pricey. All I needed was to start some music and be able to have a desk change cues at set points of the music. I came across Multiplay software and found that it has all the features I require. So far I've only run it with the Phantom software, looping back via 127.0.0.1 localhost, but I see no reason it won't run with the actual desk when I get a chance to run it, long as the IP address is updated. I've done a screen recording which should show all the required information to get you going quickly, but I'll type the main points. Going to File > Production Properties > Network, you can add a network patch. Patch name isn't important, as long as the destination IP is your desk, the port for OSC is 8830 (or whatever your non factory setting is changed to on your own desk) and the encoding is OSC. Next you need to select a Network Cue (little icon that looks like an RJ45 connection). Description is the only important part of the Common tab, then in the network messages tab, you need to select the Zero88 network patch (or whatever you named it above) and create an ASCII command with the form /zeros/cue/go/<cue number>. In the video I have created a cue 0.1 which sets everything to black each time everything is run, so the lights come on with the music. For the Cue 0.1 alone, I also change the Cue Advance options to Action: End Play and Target: Next Cue and the Post Wait option to 1.00 seconds, so that when it is played, as soon as it does its 1 second to make sure the desk has time to move everything back to black, it then advanced to the next cue. All the other cues are just duplicates of this with the description changed and the cue number changed in the ASCII command. You can just add as many of these as you require. None of these have the above options for Waiting and going to the next cue of course. I then insert an Audio file just below the Cue 0.1 cue, which is played once Cue 0.1 has done its 1 second wait. You can obviously select whatever audio file you need to run in the Audio tab. The important bit for this is the Cue Points tab. I add a list of New Cue Points for each of the cues from 1 onwards. Time is changed for each one to be the time in the audio playing that I want the desired cue to be run on the desk. The target option is the name of the Cue I want to run, based on the description of the cue. As such, you could imagine making a standard file with a large number of cues and cue points, then putting in the times for the ones you need and deleting any after that point you don't need. Just a note also that the OSC command I have used runs a cue in the current playback, so make sure you have the correct playback active. You can use cues that run a given cue in a specific playback if you need to. For more information on the possible OSC commands, you can check this link: https://www.zero88.com/manuals/zeros/setup/triggers/osc-examples Not saying this is the best way to do it, but it's a way I've got it working and it's free to try. Hope it proves useful to someone. You can find the screen recording here:

Had a quick look through the profile on Phantom Zeros and I don't see anything obvious. My expectation was that there may be some mode option which was a default value other than zero, which was causing something weird when the profile operated, but when you put it in as dimmers, they were all defaulting to zero, so it started to work. Given this worked via dimmers, I'd bring up the profile and watch the dmx values being sent out to see if anything obvious is raised above zero, other than those you were doing with the multiple dimmer channels. Otherwise, an RDM issue if it's enabled, jumping to something unexpected, or perhaps a mode issue on the light settings or just a general communication issue. Will be interested to head the full update on what fixed it though!

Pretty much what I thought. For the kind of work that I do in film and television, it would be a huge bonus to be able to programme 16 bit intensity changes. Often I have a fairly powerful LED filming light at perhaps 5% in a scene and I'm asked to bring it smoothly up from black. Those 12 jumps over a 4 second rise are really noticable on camera. Your wording has made me realise that the get-around for this would be to have a lit cue and a black cue which would allow me to go from black to lit or lit to black with 16 bit fading. Fair bit more work in time-sensitive situations, but I've just checked and I get 16 bit intensity changes between cues. That'll work for now in certain circumstances where I have a bit of time. I don't see any benefit to the raise/lower being 8 bit rather than 16 bit, so it would be great if that could be sorted for a future update. Makes it a very quick way to make timed rises and falls for a saved scene.

Thanks David. Yes, I do intend to shortly. Was pretty much just sense-checking that I'm not being an idiot and missing something before I do mail support. It's been good to see that it does operate as I expected when you use the programmer timer (which I didn't think of trying) so it adds to the likelihood that something is indeed not right in the software for the raise / lower times.

Thanks for this. Had to get storm damage out the way before getting a look at this. I can confirm that you are correct - the board is capable of doing this as I've done the same on the Phantom FLX S24 (and I assume it will work with my board too). As this is the case, it looks like there is a bug in the raise / lower times. I put in 600 seconds to the raise time on a playback channel, and did everything as per what you described above (fixture etc.) As you'll see, it is raising the MSB and LSB simultaneously. I have also checked on the Phantom FLX and it also does the same so this isn't an S24 issue. I've created a screen capture of everything I'm doing so you can see the issue. If I'm missing something, I'm delighted to be put straight on what I'm doing wrong. I can't see any reason it shouldn't be doing exactly what it does when you do what you described in your post. This should just be an automated recording of that operation. You can see the screen capture here:

Sorry for the slow reply! It's rising the two numbers simultaneously, so it is making some attempt at playing across the two channels. Just the two numbers duplicate each other. Perhaps the S24 is purely an 8 bit intensity setup and it just fakes being 16 bit to support the profiles. I do see on other channels, such as pan/tilt etc. it does use the full range. Something I'll need to try perhaps is to make a profile which has a 16 bit setting which isn't intensity (some other option such as a beam setting) and try to see if it is able to move those settings on a 16 bit fade. Just makes it a bit inconvenient that the fader wouldn't really do anything beyond selecting the light.

I have some 16 bit capable fixtures which have channel 1 and 2 for intensity. I hoped to get some nicer smoother slow fade ups (at least to the capability of the fixture) by switching to 16 bit mode, but I don't seem to be getting a true 16 bit. So to follow, I bring the fader for the fixture to 100% then store to a playback. I then go into the setup for the playback, raise and lower tab then change the raise time to, for example, 255 seconds. When I watch the dmx output, I would expect to see the 1st channel stay at zero while the 2nd channel goes through 0-255 in 1 second, then the 2nd channel would reset to zero as the 1st channel increments to 1 and so continuing till in 255 seconds they both read 255 and 255. Instead, they increment as 0,0; 1,1; 2,2; 3,3; 4,4 and so on till 255,255 - in effect, only 8 bit duplicated over two channels as far as I can see. Am I missing something? I understand that the board only allows 0-100% control via the faders, in 1% increments, so it can never achieve even 8 bit control from a fader, but was hoping it may be able to automate it via raise time. For reference, I am on the latest version 8 firmware (build 8), running a FLX S24.

Brilliant, great to know it has been added! Thanks Neil

Just having a play and that Rx:Gx is a big time saver, so that alone is a huge help!

Hi Edward Thanks for the suggestion. I currently run a "master" playback where each cue releases and triggers other playbacks (which have only one cue for the lighting I want). So the first cue triggers playback 1, the second cue starts so many seconds later releasing playback 1 and triggering playback 2. The time consuming bit is making up these cues with different delay times and updating the different trigger and release for every cue. It sounds like the macro option isn't a huge improvement on this but may streamline the process slightly by being able to use a macro of "Rx:Gx" on each of these cues, if I have read this correctly? The cues will still have to be calculated for the delay as per what I am currently doing. So, 3s, 2.8s, 4s between each other rather than 3s, 5.8s, 9.8s from the start (which has the advantage of being easily read from the song file). I currently use an excel file and put in all the times of each change and get it to calculate the difference between each. Just something that makes the whole thing a little more time consuming. I appreciate that midi is the route, but the FLX is a little beyond what I can justify for this type of work at the moment, and also means the setup isn't self contained for travel. The little S24 is awesome for the size. Thanks Neil

Hi Edward Thanks for the brilliant zoom session earlier this afternoon and in particular for quickly going into the auto triggering on cues. I was interested to hear if you dropped any bombshells on my knowledge of the subject in the way you did for the record functions. So many little details I had missed! It got me thinking further about this last discussion on the forums here. An "auto trigger any cue in a stack x seconds after cue n" would be an even more flexible and useful option. Having the option for cue 1 but also any cue to reference from for triggering. Just thought I'd add this in in case it gets to a stage of becoming an addition! Thanks Neil

Glad to hear the idea is of interest. If it is feasible, I look forward to perhaps seeing it in a future update!

Another possibility is that "Auto (with first cue)" can only be selected if "Auto (with previous cue)" or "Auto (after previous cue)" haven't been used in any other cues, and selecting "Auto (with first cue)" disables the use of the other two for any other cues in that playback. Creating a cue with "Auto (with first cue)" would automatically place that playback into a setup which reorders the cues based on the wait time. This would minimise disturbance to current coding.

Thanks for pointing this out. It is a good explanation on the differences. I normally use the Auto (with previous cue) and put in the difference in time between the previous point in the music and the next. The learn option is an interesting possibility but would also rely on me getting my timing absolutely right, or I'd have to go back and change things manually. By scrubbing through a music file I can quickly note a list of times and the ideal would be to be able to drop in the right number of cues and add the appropriate "wait from go" times into each in order. I guess my feature request, Edward, would be something along the lines of "Auto (with first cue)", but I appreciate it may be a systematic change in the cue playing. I'm not sure whether that raises programming problems that I wouldn't foresee from the outside. It would likely require an ordering system that reorders the cues based on the wait time entered. The idea that I press go and things happen exact numbers of seconds or tenths of seconds after that go button is released, without having to have a midi file or be against specific real times, is something I think even the FLX is missing. The other interesting advantage is that it doesn't require additional hardware, unless processing power is an issue, so could be an option for all of the FLX range.

I do quite a lot of music videos and find my S24 a great desk for quickly setting up and running basic lighting. Occasionally for certain tracks, I want a pretty detailed lighting setup that runs from the start of the track. I do this by putting three beeps at the start a second apart, then the music plays one second later. I release the go button on the third beep and it runs the first cue which is just black for 1 second. The second cue is then the start of the lighting. I therefore have to go through the song, get the times of each cue change and work out how long it is between the previous cue and the next cue. I would term this setup as relative timing. Each cue reacts relative to the previous cue. My feature request would be an option to select "absolute timing". This would operate such that when I release the go button the timer starts from zero. I could then add in cues based on their start time in the song (plus one second in my case) and they would order according to the start time. Fades in this mode could perhaps be set to work as internal to the cue timing at the start but run half way between on other cues (fading from -half a fade time to + half a fade time across the absolute time of the cue start). I can't imagine I'm the only person who uses a board in this way. Perhaps even productions operating to a fixed schedule (think New Year's countdown, starting at 11pm) could find this quite useful. Start dead on 11pm and 60 mins later your board will have a cue dead on midnight, no matter what cues have come in between, with no calculation. It would also make it a lot easier to add in cues after the fact without messing up timings of anything after.