ice

I've tried working with the memories, but it isn't a really fast way of working with movers. I'm also not that good in remembering where I left everything (and for variation; I do program loads of things). I also can't stand the fact that when you're using the memories you're limited to one chase at a time. For instance; you've got a song which starts rather peacefully... ok you hit a memory which has a position for your movers; and then hit a slow colour-chase... Now when the song starts to build up you want to add a gobo-chase to this for your backlight fixtures; that's impossible without using a sub; hitting another memory will cause the colour-chase to stop again So that's why I'm using the subs quite often. Another question; do you guys use the group selection button often? I find that patching in a useful way mostly kills the use of that button, cause the normal way of selecting what you want is just as fast. I understand it's useful when you've got 4 pages of movers, but with only one I don't really get the point. Keep it coming!

The MaXXyZ has flash buttons in which the name of that sub is displayed; that feature ROCKS! Motorized faders would be great too in some occasions, and indeed a different way of programming. Combine that with the use of 2 touch-screens and you've got a whole different desk than the Frog. It's the question how cheap u guys can acheive that; when it doesn't differ a lot; most opps would want the Pearl I guess (it is the standard indeed). That beta-test thing sound great indeed, and I hope u do listen to the remarks made here, and maybe ask our opinion on some of the development questions; it's mainly the communication to the customers which I value in your case!! Really doing a good job, I'm eagerly waiting for new development. Oh and a new feature which would be great; overlapping transparancy... it's really cool when a desk is exactly remembering what it's doing, and which things have priority. Kind of like the LTP things; but I'll try to explain the difference; you run a colourchase A, and then by-hand select a colourpallet. The fixtures should change colour accordingly, but when the opp tels the desk to "exit" that step; the chase should continue where it left off. That, combined with a good way of parameter programming is really getting nere the high-end desks.

I'm still struggling to develop a quick & easy way of programming, as well as running the show. My method of programming nowadays (gen&fix); [*] patching & assigning (duh, but that also has some logic in it; fronts e.d. are on faderset A, backlighting and effects on bank B; so the ones you flash are nearby!) [*] making pallets for the fixtures; first of all the first 12 colourpallets are used to select the same colours in each fixtures (so 1 = o/w for all, 2 = red, 3 = orange etc etc). The second half will consist of combinations of colours with match (of course!). The first 6 of beamshape pallets are frequently used gobo's with a slow rotation. The second 6 are the same ones, but with the prism on. The next 6 are strobes; open-slow-mid-fast- and 2 with random strobes, one slow/mid and one fast. The last 6 pallets I use for rotations around the gobo wheel (don't know how to put it differently...) and things like frost & blackout using shutter. The position pallets will be different depending on the show; it's a combination of fixed positions (like drums, guitar, bass etc), or good looking positions (crosses and stuff with movingheads/scans; just something nice) and finally some movements since the last OS update; also in order from slow washes / moves to some rapid stuff. [*] Ok now its up to the tricky part which I haven't figured out yet... I'm trying to make some kind of system here but it's not there yet. Usually, when performing with a band I group the colours of my PARs (4 most-used in most cases) under the first 4 submasters. But because I hate it that i cant change a page that way (want to flash 'm a lot) I program those in each page (okay; that's not really a good solution, but I don't know another way). Then the other 8 subs are used for fixture things, like gobo-change and color change chases. That's also a tricky thing because I try to program them like 4xgobo, 4xcolour on each page; each page for a different fixture (I like groups, so I tend to program some things for scans, some for the macs, some for colorchangers etc etc). But this method kind of sucks. [*] The stack I use mainly in theaters; the way it was meant to be used. During live operation with a band I don't really see how it can be used other than like a 13th submaster. I really wonder how u guys go with these things, especially when working (like i do a lot) with a bunch of scans, some movingheads spot, some washes and colorchangers. I haven't been able to find a quick way of programming. It's almost impossible to re-use programs/pallets when the combination of fixtures is different everytime, since there's not a quick way to copy that information? Great topic this is, I really hope to learn a lot from this one; especially from the Frog creaters; what were your intentions when building the desk; how should it be used!?

Good question... you keep repeating that the Frog series of desks were meant for the "budget" range of lighting desks (okay; it's definitely not for free, but cheaper than avo / MA / hogs!). What about the sucessor of Frog? Will that be a desk which has everything we want (kind of working itself to the Pearl) or a compromise (if so; what will be changed? :S) Was that "sucessor of the Frog" idea of yours real; are there plans on that, or is the project already started as we speak? I'm very curious about that!

Does it work correctly on the Playback X itself?

Why? There are some solutions; if you want the fixtures to act exactly the same (thats what I get from your question...) just make them listing to the same DMX address, that works just fine. If that's not the case; you could always write a fixturefile and copy the parameters. But beware; all of your menus will be copied too, so one fixture button will contain 2 colour selections, 2 gobo etc if you place 2 fixture there. I think that would suck bigtime Whats your problem? (Why do you want to do this???)

As some users already requested here; why not make pallets with all attributes recorded? That would almost be an SX button. Well, that's not exactly my idea (id still love the focus-pallets), but it illustrates how, and why we're working with the pallets. Hope that clarifies some things too?

That's indeed the case; pallets work perfectly live! Ie for a colour or gobo switch, it's a lot quiker just using a pallet than creating a chase / memory for that purpose. When using memories for instance your submaster run out quite easily (different subs for gobo, position, and colour isn't easy at all when you've got a fair number of fixtures). Pallets are a great way to do this. But as other users already said; 24 is a little short for me too. For instance; mac 250 krypton's colour wheel fill up the first 12, then you'd only have 12 to work with. But what I often use: a button for each colour (so that's 12), some buttons for combinations (colour combi's with all fixtures), and some with combi's for seperate fixtures (most fixtures support a kind of half-way use of your colourwheel). Using the pallets this way takes some space, and 48 would be great. As for the desks not having a switch-button; too bad. Okay, that may be not so very nice of me, but as we all know there are variations in the Frog range because each desk has its own specifics. Desks having a switch-button could be equipped with some more pallets, the other desks just have to do without that function; it's not like a feature is taken from the desk; it isn't possible now!

Jup, you're damn right! I guess I'll wait with my translation to Dutch until the next issue is out? Is that going to take a long time, or is it a matter of days / some weeks? I learn something new everytime I use the desk; all those hidden features; they're great!

You could try this: step 1 = position 1, with a slow movement speed step 2 = position 2, with a slow movement speed (position = snap) step 3 = home with the fastest movement speed (position = snap). This way you can easily time your movement; when the head moves to slowly, it won't reach its final destination, and therefore snap to home somewhere in between. When you've figured out what time / speed setting you want to use, u can implement this in your final program. I'd also recommend to use the memories stack for this; you can change the individual fadeup/down/dwell/LTP fade etc for each step. Use the auto-function to step through the memories; and everything can be timed exactly the way you want! When you understand all of the parameters the creation of this chase should be easy using memories. Good luck!

It is... I was unaware of the FAN-FIRST function, so I always used it by setting first head to 0, next 10, next 20 etc... sh*tload of work, while this fan-function does it all for you! Damn, and I read the manual! Must have missed somethings somewhere

I don't know... where would those pallets be located? And what exactly would you place there? Okay; it would be rather nice to have selection buttons for the different gobo's and colours if that's what you mean? So when you load your fixture the first x pallets of the colour pallets would become all the different colours your fixture had etc? But that would suck when it consumes space (for instance; I'll program about 12 different colours with washes; that would mean a default pallet would contain 12 colours, limiting my "free" options to 12! that's way too less). Maybe these kind of things could be selected by the channel-flash selector; ie first 24 will be exactly the same as they are now; 25-48 would be these programmable things? Don't know... don't really think it's going to be on the list; loads of work I'm afraid, just as my topic considering focus-pallets.

I was running on a submaster I think. I created the chase with only the colour attribute (so pressed colour+program), set the colour to snap, and transferred it onto a submaster. When I output the chase (output screen shows 0->255->0 and so on), select the fixtures and press COLOUR+attack, the attack changes! The values start running up from 0 to 255 and back again; so it does work. But now I tried to set the attack back to snap (that's the first option, right? |_| that one turned 180 ), but the values didn't. I had no fixtures attached at the moment (was at home), so I don't know if it even was a visible error. Anyway; I guess the first option should display 0->255->0 again, or is that my mistake?

Yeah that's the idea, you can snap the parameter and the fixture does the rest. Just a matter of splitting up tasks; because the fixture knows its own details it's far better in calculating a suitable movement. I guess that parameter was thought of because there's no way of knowing whether the desk is outputting a slow transition, or highspeed movement. Without that parameter all movement would be considered fast, using motors at highest possible speed. Above problems (unsmooth movement) will occur in those cases

Of course, but it won't restore it's original value when I select another fixture, that means a lot of work. This maybe a really specific function, and it isn't really nescessary, but would be very clever when the brightness pallets aren't going to be used for something else.

I seem to have found a minor bug in the new software versions. I created a colour-chase with a fixture, just recorded 2 steps with 0 and 255 as values. When running the chase, I press COLOUR and then adjust the attack parameter. I can effectively use it to alter the attack to fadein-fadeout, but returning it to snap won't work? I've also tried the same thing using beamshape / position parameters, it seems to work fine with those. You can easily recreate the situation for testing matters. The colour-action was set to snap, and i used a normal chase with 2 steps (as described).

Using the desk-fade for movement isn't going to be as smooth as the movement speed. Why? Simple; when fading DMX values the fixture will receive minor changes in position parameters, and therefore move slow. But When this is really slow the small "steps" will result in unsmooth movement. When you snap the parameter the fixture will use the movement speed to calculate the best route to its destination, and therefore moving very smooth. At least that's what I found out with out MACs; using the movement speed was a lot smoother (but when you consider what's happening that's kind of figures). I guess (to answer your question) you should play with the movement speed parameter a little bit. I think the actual speed-rate is at top speed... the fixture needs time to gain speed and slow down again, so maybe that's the problem?? When you snap the position with the movement speed set; the fixture will continue moving to its end-destination; if it receives a dimmer=0 value in the meantime; the shutter will close! So I guess your timing is off somewhere, try to figure out where that is and your problem is solved I think.

Saving the file with Illustrator makes the files grow larger and larger. If anyone knows a way to compress the PDF files? Or save them differently? I can't figure out how to edit them with Acrobat Prof. but I'll give it some more time next week or so.

Teksten aan de rand zijn plaatjes, die kan ik zo 123 niet editen... zal eens kijken of het opnieuw opslaan met acrobat de filesize weer naar beneden brengt.

Ok, 2 seperate references i guess???

Think that actually would be quite some work to implement.. Why not do it yourself until further notice? It's easily done by using position pallets; just program the pallet you're using in memory n to memory n-1, and use fade + some LTP time to complete the move. And if the lights are used in mem n-1, insert one in between to do the same thing... also use the move-while-dark function of your heads and the effect will be the same (ok, it certainly is more programming work; you're right!)

I think you're talking about my topic... if that's the case; this would be great: being able to lock a brightness pallet, which would serve as focus pallets... 24 channel flash buttons = 24 fixtures, so that's easy to do (ok, mambo frog maybe a bit off there?). Selecting numbers 1-24 would home the parameters of color (and maybe beamshape?) attribute(s); but the 'initial' parameter has to be saved there! Then selecting another fixture would do the same thing, and bring back the original values of the previous one. All values would be restored when unlocking the pallet (that would be fixture edited last). This might be a good start for such a function, a reference number would be great, cause I think loads of programmers would like it (right!?!?) and implementation (having the locked pallets in current beta software) would be rather easy.

The Dutch version of the operation manual can be viewed via: http://www.repsaj.nl/upload/Frog_Manual_Is..._Nederlands.pdf I've only made it to page 7, but more will come! I'd like to ask the people who speak Dutch to look at the file and correct me where it's nescessary (and I'm pretty sure it is ). Don't know when my translation habits will continue; but everytime they do, I'll upload it again and make sure to give u guys a notice of it. PS: How do I edit a file with Adobe Acrobat? I don't really get it so I used Illustrator; but look at the filesize! For 48 pages that's going to be rather huge i guess

Aaaaaaah indeed! That sucks bigtime, any chance of fixing? If you say it's the monitor-output lagging: at what refresh rate is that thing!?!? I don't get why that should be any more difficult than refreshing lcd-output; don't know how the frog OS was made but a refresh of 60hz wouldn't be that difficult I hope??? I really thought it was built-in for some reason (but couldn't figure out why what that would be).

And make sure your parameters are set to "snap" instead of "fade". If you notice some slow movement when that's the case: slow fixtures