Davidmk

@Archie D has made this assumption because you have posted in FLX S. If you actually have a full FLX then recording a macro that is then triggered by OSC would be the way to go. However, all may not be lost if you are really on FLX S. You could record a cue that releases playbacks (see manual here) and then trigger that from OSC. A similar cue could also trigger all the cues you want to run. I'm not sure of the timings (whether releases are done before or after triggers) but you could even try putting all your releases and triggers on the same cue.

Ah, well, while the manual reference provided by @kgallen gives you the structure of OSC messages you still have to choose which ones to use and that will depend on what the you think is the easiest to program. For your panto I would look at simply sending a "go" for the next cue in your show. This probably simplifies your sending system and you are not going to get away with not programming states whatever you do. For live music you may want to use a manual input to trigger specific cues or playbacks. I work in music venues and have a fairly sophisticated (new) TouchOSC interface to select colours, positions, gobos and effects quickly. These are all stored as cues in separate playbacks for each of colours, positions, etc. You could use the (free) original TouchOSC to do something similar. NB Neither of these solutions fit well with chases. While there is an OSC command to control a playback's level you are probably better off triggering a cue that, in turn, triggers a chase playback (like you would have to if you wanted a chase in a programmed show). Check out the OSC "release" message, you may need this to stop chases/effects when busking. Also, look at macros for setting bpm (for panto) and/or having a tap button (for music but, maybe, for panto).

That is pretty neat and creative solution, one which I might try myself. Not sure if the timing of it, but a cue can release another playback so you might be able to automate the release that way.

In my years working in IT there was "established wisdom" that you don't install even numbered releases (especially 0 releases) these generally contain new features and that often means new bugs. Odd numbers are usually bug fixes for the preceding one. Not always true of course but worth thinking about. There is also a theory of software decay. Essentially changing software can introduce bugs, even in the unchanged parts. This accelerates with the number of changes so, at first, very few bugs are introduced but, as the software becomes more complicated and new changes are built on top of old ones the number of bugs per change increases. Again, not always true but something to bear in mind as, eventually, all you are doing is fixing the bugs caused by fixing bugs. As the comments in one program I had the "pleasure" of working on said "this program is like an old car, you set out to change the air filter and end up replacing the engine" 😁

Should have updated with results. Sorry. I replaced the fader and found that the ribbon cable was missing clips. Made sure the ribbon connectors were properly in (although not clipped) before closing up. The fault seemed fixed although it did re-occur. Lent it to a local AmDram with a warning about the fault. Even with the fault the monitor shows the correct information so they were happy enough and after the show they bought the desk for what I'd spent on it (no charge for time). It did go on to have issues with faders (also intermittent). Still think it's the ribbon cable. The AmDram's tech's dad is an electronics engineer so left it with them. Not heard since.

There is an oddity with the FLX grand master (and inhibit masters) in that they do not take effect until they have been taken to full from zero. If you turn on an FLX with the master physically at full then the first time you bring it down nothing happens. Pull it down to zero, put it back to full and it will work. If the fader needs attention (doesn't go to FF in test mode) it will never work (because you can't take it to full). Not saying this is the problem here but you do need to eliminate it.

I have been doing what you describe. It does work for me but there are limitations. The first is that you cannot separate speed and size. When you use the fader to control FX it has to control both speed and size. The second is that for most of the faders travel you don't get a visible effect just a messy mixture of colours until the fader reaches about 75% and the speed/size has to be adjusted in the last 25% I don't use colour mixing faders though - my colours are set by a playback with a cue for each colour and I use OSC to trigger the cue for the colour I want.

@Phil Kiernan How did you hear about this? It passed me by. Not that I care much, I didn't upgrade to 8.0.0 and probably won't risk 8.0.1. @kgallenI'm going shopping for ChamSys once the new tax year starts.

Going back a version shouldn't give any problems with the desk however you do, obviously, lose any new features and there is, potentially, a risk that your show files do not load. In practice, if you haven't used any of the new features, these probably won't bother you, 7.14.4 was the final release for the legacy desks (Frog2, LeapFrog, Solution, Orb) - You don't want this version. You want 7.14.3 for FLX & FLX S and the main difference is that you will go back to a maximum of 48 fixtures and fewer playbacks. Make sure you backup you v8 showfile. If you have used fixture numbers or playback numbers greater than the v7 limits then edit your show file to fit v7 and back that up to load after installing v7 The beta test forum for the new version (currently known as v8.0.0 build 11) seems to have been greeted with general apathy, possibly explained by being released when pantomimes are prevalent. There are no new new features and it consists of bug fixes for live version (v8.0.0 build 8). I don't know why other testers have failed to respond - for myself, I'm a full FLX and LeapFrog user and I'm not very interested in the newer versions now that FLX S has become the focus - I prefer to stick with v7 for now but might make a move to Chamsys. There has only been one tester response. This may have been on an FLX S and was favourable but did not cover any programming functions.I suspect FLX S users are under represented among beta testers.

@drscoop If you need this then using the same address is not possible. (Well, it is if you arrange the colour rolls appropriately but that would be a faff and still might be impractical.) @kgallen, as always, makes a good point but wouldn't keeping the dummy fixtures dark just mean that they skip straight to the last state in the cue list? Surely the dummies need to follow the real fixtures. Maybe they should be added to the same desk channel as the dimmer?

Is there a problem putting the pairs of scrollers on the same address?

@Archie D @Simonkbike Very thorough response as always Archie. If I've missed this in your post I apologise but I'd suggest ch1 should have a default value somewhere between 240 and 255. This is because my reading of the chart suggests this will be needed to make the virtual dimmer work.

@kgallen The only thing I can think of is adding to the release playback (Rx) in the cue macros to allow release cue (Rx/y). Not hopeful it will happen because it would probably involve a lot to implement it.

@Sol That seems a nice idea but ye "Cannae change the laws of physics" (or LTP). If you did then everything else would break. @kgallen @Archie D Opinions on that?

@Sol That seems a nice idea but ye "Cannae change the laws of physics" (or LTP). If you did then everything else would break. @kgallen @Archie D Opinions on that?