Davidmk

Hi Jon and thank you for asking. In order to explain my anticipation for OSC I first need to explain how I operate shows currently (using midi) So I primarily busk for music gigs. I usually don't know the music and have limited information about what is coming so I need to produce "looks" on the fly. I do this by having pre-prepared colours, positions, gobos & PT FX for moving heads that I combine as required. These are stored in multi cue PBs so that only one state is live at any time and they fade from one to the other. To select the cues I want I use a couple of Novation Launchpad Minis giving me 128 buttons sending midi notes. These fire PBs containing 1 cue each. Most of these are actually empty queues but I use the cue macros to fire the cues in the multi-cue playbacks as required. My show file is attached but, to explain... My Launchpads have 8 rows of 8 buttons it is difficult to label them (you can't write on them and most self adhesive materials that you can write on simply don't stick) but you can set their colours. As I need to be able to pick the correct unlabelled button quickly and correctly the 8th column is reserved (more on that below) leaving me 14 buttons. The first two rows of the first Launchpad are used for colours on our LED pars with the button colours representing the colour it sets. I have 12 colours plus White so one of my 14 buttons is spare. PBs 1 through 7 and 9 through 14 are for LED colours. As described above, these each have a single, empty, cue with a macro that triggers a cue in PB 128. PBs 8 (row one, button two) & 15 (row 2 button 7) have empty cues but no macro as they are unused. The cue macro in PB 16 (row two, button eight) releases PB 128. This 8th button is used for the same purpose in other sets of buttons. PB 128 contains cues that set all LED PARs to a colour (again Red, Pink Magenta, etc) All the buttons on the 1st Launchpad and the first few rows of the 2nd operate in this manner controlling colours of the even numbered PArs only, the colours of our MH6 moving head washes, the colours of our MH7 hybrid moving heads, PT positions of the moving heads plus gobos, zoom and PT FX of all MH6 & MH7 moving heads, The last few rows of the 2nd Launchpad work differently. The PBs matching these have actual information in the cues and the macros are not used. Typically these control things like strobing or scanning the audience with moving head lights. When I want these I press and hold the relevant launchpad button. Now all that works nicely if used carefully but there are problems. First there's the issue of labelling the launchpad buttons, I have to use cunning colour coding and even then I have to rely on memory a lot. Setting it up is clunky, the launchpads can only be set up with musical notes (not note numbers) and that takes ages and is prone to error (which is why my early mistake of starting at note one instead of zero which resulted in the last button of the 2nd Launchpad being unusable remains uncorrected) This clunkiness means it is risky to modify anything on the fly so I stick with it even though I could be using empty buttons for gig-specific effects. In fact I only do modifications when I find something wrong or when I have several days to make changes then manually check and debug them I have found, to my cost, that sending midi commands too quickly can result in the desk locking up. The 1-to-1 relationship between midi notes and playbacks means I have to leave PBs unused and take up the first 5 and a bit pages with PBs for midi triggering (i'd much prefer to have them all at the end rather than the beginning). It also means I have to change o lot of stuff on the desk if I wish to re-arrange my buttons as well as running the Launchpad editing software. Not being able to trigger a specific cue in a specific PB using notes means using a lot more PBs than is ideal It should be noted that I did, initially, try ordinary macros fired by the cues - this was even more clunky, less maintainable and, because macros use the command line, fraught with problems because they are slow and can fail or mess up other things if you are doing anything on the desk while they are running. So, I'm hoping OSC might provide a smoother way of achieving the above. I've used it before with a software lighting control (QLC+) and Touch OSC (both have moved on somewhat since then so I'm not sure if what I used to do would still work - even if I could remember the details). My dream is that I could use Touch OSC (or something like it) to create a control surface with buttons. Each button being configured to trigger a specific cue in a specific PB (i.e. transfer the T128/1 from my dummy cue to the OSC control). This would be easier to create & maintain, could even be customised to particular shows (or genre at least). An Android tablet (running Touch OSC) would be smaller & lighter to carry and quicker to connect up although I would miss the tactile nature of the Launchpad buttons. OSC won't help if, like midi notes, the relationship between controls and playbacks is fixed and I will probably stick with midi if that is the case. Beyond that, it will depend on how OSC is implemented. I don't really want fader controls through OSC - they are the reason why I bought a proper desk with proper physical controls (having tried both QLC+ and Martin M-Touch - now Onyx Touch from Obsidian - however things like Speed Override or Programmer Time could be candidates for fader controls. Stables Default 2023 03 27.zos

Doh! It was highlighted and I just read the first post, saw the link and followed it. I swear my brain is turning into Marshmallow.

Nice try but when I followed the link you gave I got this I don't see how it makes Zero 88 information easier to find. The products drop down does mention FLX if you look carefully.

A behaviour which seems at odds with the way pallettes work, especially when you consider that they are acting a bit like intensity pallettes. Buskers and tourers might be quite pleased if there was some sort of selection pallette referenced by cues. Just saying.

For OSC, you wouldn't need a laptop on site. You would need a tablet/phone iOS or Android and some sort of wireless router which could just be a travel one as long as it has an ethernet connection and WiFi. When I last used OSC you couldn't actually run it on Windows.

I'm pretty sure that this would not work as you envisage and that macros will not help. Group 2's fixture would need to be controlled by both sets of faders and would show whatever level of each colour was set last. Other than long and complex macros that add and remove group 2 in group 1's faders there seems to be no way out of this. A far simpler solution might be to arrange your faders by colour rather than group... Instead of G1-R, G1-G, G1-B, G2-R, G2-G, G2-B Use G1-R, G2-R, G1-G, G2-G, G1-B, G2-B That way, when you want 1 & 2 the same you use the pairs of colour faders together at the same level. PS I have an FLX and use a midi keypad to set all LEDs to one of 13 colour pallettes but I can also set the even number fixtures to a different pallette. This is not possible without the midi inputs of course. It takes 28 buttons & 30 playbacks on pages that are not current to do it but it works pretty well. If or when OSC becomes available on S24/S48 you could PM me and I'll explain it. Would take too long here.

Me too, then I read the rest of the line, twice, and my heart rate went back to something like normal. Went back up again, but in a good way, when I read

For the benefit of the community... Edward has taken a look at this and it turns out it is confined to consoles (phantom ZerOS doesn't have the issue). It has been logged on the system to allow the software team to investigate. Initially, this is at a low priority which is fair enough as it doesn't cause any actual harm. Whilst looking at old show files and collecting screen shots to help with this I discovered something else which is worth knowing. I loaded an old file but forgot which so I went into save to check and found it had a different name. I asked Edward about this and it turns out show files contain their original names and these are used as the default when you save them. This means that, if you change the file name (in Windows for example) then it will revert to the original name when loaded into the desk. @Edward Z88 is truly the fount of all ZerOS knowledge. Just wish I could copy & paste from his brain to mine😀

3 mails sent to support with attachments. Ignore the first one - sent in error with bits missing.

Welcome back, hope you've had a good holiday. I see them consistently although the actual characters vary. My showfile is a bit of a work in progress but based on one I've been using for a long time on this and my other desk and across more than one version of ZerOS. It has a lot (127) of cues triggering other cues or releasing playbacks. Not sure when it started or on which desk. I'll try and send it tonight but before I do I'll do some checking on older versions, maybe even the other desk.

What's with the "8fpn12" and "Hhpn12" in the attached image? I'm getting these (apparently) extraneous characters whenever I put a single or - as here - double cue-trigger in the macros field. The playback(s) & cue(s) do exist and they are named.

Yep! 😞

Glad to hear you are sorted. If you apply a pallette to a fixture that wasn't included in the pallette (but the fixture type was) then it gets the values from the first fixture of that type. I'm not a big user of any pallettes except colour so the first thing I do after patching is create colour pallettes for all my LEDs in a range of colours adjusting each fixture type so that they look the same. That way I can be confident that selecting a colour will give me consistent results across a number of fixture types and in different cues. Also if I, or the director, decide the colour isn't quite right I can adjust it once for the whole show. I do something similar with beam & shape but in a more limited way but, reading up on pallettes for this I am reminded that pallettes can contain attributes from other groups, handy for zoom & focus which change with position due to the different throw.

I haven't, at least not on a regular basis (I'd put a one-off down to finger trouble I suppose). As it happens I'm doing some offline programming today, part of which is correcting a cue that should have some fixtures in it but has actually got all of them. I'll let you know how that goes. If you could send me your show & capture files I could load them up and have a play. Got the desk & computer already set up.

Itwould be good if you could report back to the community so we all know what it was.

Oops, missed an important bit, should read... ...select the fixtures you DON'T want in the pallette (and only those), press Home and then press Update... Anyway, now you have Keith on the case you won't need me 😀

Sounds like you have all the movers in both groups and probably in your pallettes as a result. First, check on the groups screen whether you have "multiple select" or "single select" highlighted. For this you need single. Select one of your groups - if the other is highlighted then the group you have selected contains the fixtures in the other group. Delete both of your groups and recreate them. This will not affect your pallettes. You could delete and recreate you pallettes making sure you deselect Snapshot and Smart tag in the record options window. Alternatively, select the fixtures you DON'T want in the pallette (and only those), press Update and select remove in the update options window before tapping the pallette.

The fine channel may not display any recognisable pattern, it certainly wouldn't follow the sine wave. Forget about DMX and binary for a moment and consider this... Imagine a parameter, increasing linearly by 0.75 per step. It would go 0.75, 1.5, 2.25, 3.00, 3.75 and so on. The whole numbers are going up while the fractions are going down and yet it would still plot an ascending straight line on a graph. The whole numbers are analogous to the coarse byte, the fractions to the fine byte. As @Erics says above, calculate a 16bit result then output the most significant byte as coarse, the least significant byte as fine. Couple of other tips... I may be wrong about this but I think some (most? all?) fixtures ignore some of the least significant bits of the least significant (fine) channel so, even if the fine output value changes by a small amount the fixture will not move. Most programming languages use signed integers with negative numbers represented in "twos complement". You need unsigned integers so, unless your language has an unsigned integer data type you may have some work to do there. Maybe you should do your calculations in floating point and write functions to convert results to 8bit, 16bit MSB and 16bit LSB. This will be easier if you use the right language to start with. Some, at least, of a finished project will need to run in real time and it should be capable of multi threading and interrupt handling. Its a bit like a swan, serene and beautiful to look at but paddling like anything under the surface. 😀 Full disclosure... Before retiring I was an analyst programmer for 40 years or so and, while I never attempted the project I have spent time thinking about it. Feel free to DM me, maybe I can help here & there.

Just finding out if I have issue. If I can post this then I'm not.

From the release notes for 7.13... "To update a console running ZerOS 7.8.2.39 or older, please visit zero88.com/manuals/zeros/software-updates/zeros-usb-creator for instructions." There are two version numbers that are displayed by the desk - one of them is the underlying LINUX version number something like 7.8.1.2 - you are not interested in this. I think the ZerOS version is displayed somewhere in the startup text and probably elsewhere. If your showfiles have a .zos extension then they were saved with v7.9.8 or later. If the version in your desk is actually newer than 7.8.2.39 then you start the desk in the usual way and use setup to initiate the software update. Try reading the release notes again, in particular the instructions on the last page.

Yes. (Nice short answer 😀)

How good are you with spreadsheets? If you recorded one cue with everything in it on the master playback and output it as a CSV then, I think, the top row would give you all the used channels and what they are used for. Turning that into what you want would require good spreadsheet knowledge but it ought to be possible. Have a look at it and see what you think. (I've used CSV output once, to get details of cues alongside the script for a play, took some doing but at least, once it was done, I could refresh it with a new CSV as the cue stack changed.

Why didn't I know that? Thanks!

Any chance of "everything" pallettes allowing a combination of colour, beam, shape and position? Edit: Oops, just realised that this is already in the list a "looks" pallettes.

Absolutely! Please.