K-Nine

I shall find out if there is a maximum length of filename for show files. Note - if you rename the show file on a PC make sure you give it the correct file extension (.isf) or the desk will not recognise it as a Frog show file.

The status of FR #5401 is that it is still a future item to be reviewed. Do you mean the maximum length of the show file itself, or the maximum length of the filename ? There are many suggestions for future improvements and upgrades etc. to the frog series, but it is not up to me to say what or when any of these suggestions may be implemented. That is a decision for the sales and marketing department, and the brand manager. They will have to decide the commercial viabilty of spending time and effort in improving the existing range, against developing new products

Frog Series Software - Version 9.2 We have released Version 9.2 of the Frog Series Software. The new operating software can be downloaded from the Zero 88 website by CLICKING HERE Version 9.2 of the Frog Series software contains some bug fixes relating to the Edit Blind function.

I don't have time to be bored, what with all the new software updates, administrating the frog and illusion support forums, updating the manuals etc I'm not sure if we are planning any more functional updates for the Frog series at the moment, that will be up to the Sales/Marketing people to determine what impact the latest update package has had on sales and perception of the frog range. All comments and suggestions are welcomed and even if they don't make it into the frog range, you may well see them in later products under development :wink:

One possible method is as follows: Program each of the separate states as scene memories. Make the first memory have a Go trigger or timed trigger (as appropriate) Set the dwell time to the length of time you wish to have this state on the outputs. Make all subsequent memories have automatic triggers. Set the dwell times to the length of time you wish to have each state on the outputs. Put a Jump on the last memory back to the second memory. Trigger the first memory and watch it run continuously For example: Memory 1: Initial state : Go or Timed trigger. Memory 2: state 1 : automatic trigger. Memory 3: state 2 : automatic trigger. Memory 4: state 3 : automatic trigger. ... etc. Memory X: state X-1 : automatic trigger: Jump: memory 2

Nothing to do with me .. honest 8O

An Interesting idea There would need to be two different layouts of the submaster screen to cover all the desks in the Frog series: Frog, Fat Frog, Leap Frog 12 submasters (3 groups of 4) Mambo Frog, Bull Frog 24 submasters (4 groups of 6)

I've just checked the fixture library and there are 12 fixture types which could be classed as pro 1220 scans: Pro 1220 CMYR (Modes 1 - 4) Pro 1220 RPR (Modes 1 - 4) Pro 1220 XR (Modes 1 - 4) Check which of the three models you actually have and in which mode they are working.

First of all congratulations on reading the manual You'll be pleased to know that both the Frog Series and Mambo Frog Manuals will be re-issued shortly. Both have been updated to include all the recent functional updates including version 9.0 As to the movement effects - it's the combination of the extra parameters such as offset together with the fan wheel editing modes that make generating those fancy effects really simple

OK, just tested it here again on the fat frog and it appears that for colour chases running on a submaster, you can adjust the colour attack from snap to fade but not back from fade to snap :oops: I have tried it with beamshape and position chases running on submasters and they appear to work fine 8O Frog Reference No 5475 - Live adjustment of Colour attack for chases running on submasters - cannot change from fade to snap - Bug.

Were you running the chase from the Playback X, a submaster or an SX button (mambo frog). I have just tried it on a fat frog here, and can adjust the colour attack between snap and fade, when playing back on the playback X.

Cheers Ice, I wasn't sure how the mspeed parameter worked on some of these fixtures :oops: So presumably, you send it a new pan/tilt dmx value and an mspeed value and the fixture makes the transition as smoothly as possible in the required time 8)

A bit of a stab in the dark this (excuse the pun) I've never really used mspeeds to determine how long it takes for a fixture to move from one position to another. Maybe this is conflicting with the natural speed of the chase itself (ie how often it triggers the next step). The chase may be sending out the data for the next step before the fixture has completed its movement. Perhaps you could ignore the mspeed parameter and get the fixture to track the actual dmx output from the desk for the pan/tilt parameters. By setting the Position action to fade the movement should be fairly smooth between chase steps. I don't think I've used these particular fixtures, so I'm only guessing that this may be possible 8O

When a memory is transferred onto a submaster, it's name, fade times etc are copied onto the submaster. The only link between the submaster and the memory is the actual channel/fixture data stored in the scene/chase memory. Once the memory has been transferred, all the submaster parameters are then independently editable by the user as required, and do NOT affect the original memory on the memory stack. This is something that we modified in version 9.0 of the frog software as a result of numerous requests from users, such that the HTP fade times, LTP fade time and LTP actions could all be adjusted as required on all submasters, regardless of whether they contained channel/fixture data which had been programmed directly, or contained a transferred memory. Previously submasters with channel data were manual only and none of the fades or LTP actions could be adjusted. The current situation is that once a memory has been transferred onto a sub, the only thing that will affect the submaster data is editing the memory contents (ie the channel/fixture data of the scene/chase).

Firstly, by 'effect' do you mean a chase using one or more of the beamshape parameters on the fixtures ? Having talked to our software engineer for the Frog series and tested it on a fat frog here - outputting a beamshape palette for the fixtures will stop the beamshape chase running on the submaster for those fixtures. This is because beamshape (like colour and position) parameters are processed LTP on the desk. If for some reason it continues to run the beamshape chase, then that is something we will need to investigate further. I've just tried this on a fat frog ... Program a scene memory with generic channel data only and save. Select memory and press edit (to edit live). Set fixture data as required. Press EDIT to exit Edit mode. A "Data Modified" popup window is displayed. As there was no C/B/P data programmed originally in the memory, the attributes recorded line of the LCD says "C<No > B<No > P<No >". Therefore, before you save the edits to the memory you need to change the attributes that you wish to be recorded to "Yes". The simplest way is to press the COLOUR, BEAMSHAPE or POSITION button as required, which will toggle the state of the attribute.

There's also the Frog Screen which effectively gives you 130 remote switches 8O Frog Screen Topic

As Pipo correctly said, Offset is one of the six parameters which defines a movement effect. Offset determines how far through the movement, the effect starts when it is triggered or resynchronised. If you have say 4 scanners all doing the same movement effect (effect, size x, size y, offset, rotation and speed). if the offset has the same value for each scanner they will all do the same effect, starting at the same position. By adjusting the offset parameter for each fixture using the fan-functions on the wheels, you can create a 'wave' effect or you can set the offset absolutely for each fixture using the control wheel. Example: Set up four scanners with the same movement effect (effect = quad, size x as required, size y as required, rotaion = 0, speed as required) Then for each of the scanners set up its offset individaully as follows: Scanner 1 offset = 0 Scanner 2 offset = 25% Scanner 3 offset = 50% Scanner 4 offset = 75% Save the data to a memory, and then trigger the memory. All four scanners will do the same effect but each will start at a different corner of the quad effect.

As I said above, the dwell time only needs to be specified if the following memory has an automatic trigger. The dwell time is the time that elapses after the fade up/down has completed. If you had a memory which cross-fades in 3 seconds but you then wanted the next memory to trigger automatically say one minute later, you would make the dwell time 57 seconds. The dwell time in combination with automatic (and sometimes real tme triggers) can be very useful when playing back shows automatically without user intervention, for example from a Frog Box. Imagine a show in a shop, exhibition hall, museum etc where the first cue is triggered at say a specific time (eg 9.00 am), and the rest of the cues/memories are automatic or real time. If you are playing back the memory stack (playback X) manually using the Go button (or via remote switches set to GO), then it is probably best to leave the dwell times at their default values of zero.

I just noticed that my number of posts had reached 666 8O This reminded me of a spoof version of Iron Maiden's "Number of the Beast", so with apologies to Bruce and the boys .... THE UPSIDE DOWN POLICE I was alone, One quiet night, I heard a noise downstairs, and it gave me a fright, What did I see ? Could I believe ? A bunch of lowly thugs were breaking in to batter me. What did I do ? I grabbed the phone, But in my struggle it fell, landed upside down, I made the call, dialled 999, The lady said the police would be there in no time...... Their car was black, a light was on the back, And I could clearly see, their Sarge was watching me, He plainly was, no ord-in-ary fuzz, He wore baggy threads, his men stood on their heads, 666, The upside down police, Loved by thugs, they're easy to defeat. Torches blazed and deep voices were raised, Thought I heard a cry, thug kicked in the eye, But in the fight, the cops the thugs did blight, They weren't that hard to ground, cos they were upside down, 666, The upside down police, Pushed aside, they really weren’t that bright. This had to stop, I phoned the proper law, This was really real, and not some crazy dream. By the time they'd come, all the thugs were gone The nutters on their heads, all got locked up instead ! 666, The upside down police, 666, they're challenged mentally They're coming back, they will return, And on their foreheads they'll have a nasty carpet burn, Next time you scared, and all shook up, Please check that when you dial, your phone's the right way up !

I could have But seriously, I think the 'preserve data' option should do what you were looking for - ie it essentially moves the programmed channels/fixture parameters in the memory you are about to delete to the next available memory, thereby preserving the overall 'look' even though you have deleted a memory from the stack. 8)

The way that the tracking function operates internally was reworked significantly for the moving light software. When playing back cues from the memory stack, it should not matter whether you play them back in strict numerical order or if you just select a memory and then press the Go button. In either case the DMX outputs should be the same. If you are experiencing problems with the scrollers, could you please send me a copy of your show file, with details of where the outputs are not as expected, and we can investigate further.

Fortunately, we thought this may be a feature people might like so we have an extra option when deleting memories in partial Mode When you delete/clear a programmed memory, you have the choice of simply deleting it, or preserving the programmed data in the memory into subsequent memories. See Illusion 500 Manual page 5-17 for further details.

That's fine Haytech - we may not implement all the various suggestions on the current range of desks, but they are very helpful in developing the functionality and user interfaces for future products :wink:

I think Haytech has covered most of the things you asked but here is a quick recap for you. The Fade Up, Fade Down, LTP Fade and Dwell times are in the format mm:ss.t (minutes, seconds and tenths of a second), so 3 seconds is displayed as 00:03.0. The range of times is 00:00.0 (zero) to 99:59.9 (just under 100 minutes). The various fade times and dwell time always relate to the incoming or Next memory on the memory stack. For example if the current memory is 23 and the next memory 24, when you press the GO button the fades and transitions of the outputs are determined by the times programmed into memory 24. The Fade Up and Fade down times relate to HTP data only - that is the generic channels and the brightness parameters of any fixtures set up on the desk. As you go from the current memory to the next on the memory stack (playback X), the generic channels and fixture brightness parameters will fade according to the corresponding fade times as follows: If the channel is going from a lower level to a higher level - it will fade up in the Fade Up time. If the channel is going from a higher level to a lower level - it will fade down in the Fade Down time. If the channel is programmed at the same level in both memories, it will remain at that level during the transition. If the next memory contains fixture data, the transition of the colour, beamshape and position parameters/channels is determined by the LTP actions and the LTP fade time. For example if the LTP fade time was 3 seconds and the colour, beamshape and position actions were set to snap, snap and fade respectively, then when you press the GO button the following will occur: The colour parameters programmed in the next memory will snap to their programmed values. The beamshape parameters programmed in the next memory will snap to their programmed values. The position parameters programmed in the next memory will fade from their current value to their programmed value in the next memory in 3 seconds. The dwell time of a memory, is only really applicable, if the following memory has an automatic trigger. It determines how long the current memory remains on the outputs before the next memory runs. For example: memory 7 is the current memory; memory 8 is the next memory with fade up/down times of 3 seconds and a dwell time of 7 seconds; Memory 9 is a memory with an automatic trigger and fade up/down times of 2 seconds. Press the GO button - the outputs will fade to those programmed in memory 8 in 3 seconds, and then remain at those values for 7 seconds. After the dwell of 7 seconds, memory 9 will run automatically and fade to its programmed levels in two seconds. Memory Triggers: Go - The most common trigger for memories being run on the playback X is GO, which requires the user to press the GO button to trigger the memory and start the fade to its programmed levels. Auto - The memory will be triggered and run automatically after the previous memory has completed - see example above. Real Time - The memory will be triggered when the time ( as displayed on the monitor screen equals the programmed start at time for the memory) Timecode - This is used when the show is being controlled by an external SMPTE or MIDI timecode signal - Frog Box only at present. Hope this clarifies matters for you - if you have any further questions please ask

That's a new one on me 8O We will be producing a new version of the Phantom Frog soon which will include a number of bug fixes, some relating to the frog series software and others to the Phantom Frog program itself.