ice

No, I mean running a chase on (for example) the shutter parameter and then changing the gobo. I thought, because you program the whole beamshape group; the gobo would reset on every step of the chase (since you programmed it!) but that's not true. When you program a chase, and only alter the shutter parameter; the gobowheel is left alone. That means when you execute the chase, you can change the gobo and It'll stay on that one.

Last week I noticed something... there is a way of somewhat programming individual parameters! For instance; when you program a shutter chase, it is possible to alter something in the beamshape menu, without affecting the chase. That way you can create a shutter chase, and manually add a gobo. I don't know if this was an already known fact, but it's kinda neat as a solution for individual parameter programming. The only thing is you'll have to "add" things with the wheels, of course when you press a pallet all info is lost and the chase stops (I think). Oh well, it's not individual parameter programming, but it saves some work in some situations.

:oops:

Lol, now everyone is going to buy CAT5 cable anyway; you have to when you go ethernet! The multi-cable is indeed very useful as we currently use it the same way. I don't really get the argument of 110 ohm cables being more flexible; we've got some CAT5 wiring for AVIOM systems which is just as flexible as our DMX wiring?

Yeah I'm sorry, my Dutch is still a bit better than my English, but I should have read what I wrote Taking everything into account, next OS update is going to rock once more

Maybe this sounds silly, but I never use the same show twice. That sounds silly

Je slaat een showfiletje op op de diskette, gewoon op de normale manier; * save show01 Vervolgens steek je m in de PC en geeft het filetje een andere naam * rename show01 -> show15-10-2004 Die diskette steek je in je Frog, en wanneer je nu wilt saven staat er in het "save as" lijstje ook show15-10-2004 Op dit moment kun je alleen maar als showXX saven, niet als een ander bestand... zou handig zijn als dat wel kon, dan kun je namelijk per band een showfiletje "bandnaam.isf" maken en dat elke keer als je iets veranderd wijzigen... Moet geen moeite zijn om dat te programmeren, en scheelt wel een boel wel voor mij (ik rename nu elke keer weer opnieuw). In English, this is what I would like: Save a show on the floppy disk. Stick that into the computer, and rename the file to "bandname.isf". Okay so now you've got your show for that band but you want to change some things. Stick the floppy in the Frog, load the show; alter your stuff and go to the save-screen. It should list "bandname" there, so you can overwrite that file with the new show! At this time after each show I stick the floppy in a PC and rename again, okay it's not that bad but hey; LD's are lazy

Anyone has a proper conclusion for that article? It gives the sheets and test-results, but I can't make nothing useful out of that with my little knowledge of electric wiring. Thanx in advance.

If you use the same show you're going to use the same pallets, so deleting them would be rather foolish. It's more useful when you want an entire different show with the same equipment. You can empty the subs, empty the memories, but you don't want to reprogram all the colour and beamshape pallets you made (those are almost the same ones everytime, at least when I'm programming they are). What you do want to do is lose all of the positions since they've become irrelevant for the new venue. That about it, it's just useful to re-use colors and beamshape and lose positions.

Yeah but this isn't naming shows! When you open the "save show" dialog, the console checks which files are already on the floppy, and marks them as being programmed... it should include other show files too.

Why use CAT5 instead of DMX wiring? Perhaps it's cheaper (I don't know), but that would be the only advantage I could think of. Don't get me wrong; we use it too, but we've connected several XLRs to it so there only one cable needed for DMX, smoke and haze channels (I don't run smoke and DMX off the console).

Glad to hear that. Keep suprising us with that excellent support we're used to I guess there hasn't been a meeting discussing whats going to be in OS X, right? I like having a list of things to wait for, but that just luxury 8)

And if you want to do it right; use proper DMX wiring (that has a resistance of 110 ohms) and a terminator (120 ohms specificated by RS-485). This is a good scheme for a terminator: It should be soldered between the data- and data+ (2 and 3) and uses 2 220 ohm resistors, and one multicoloured LED. By placing the resistors in a parallel connection they will resemble one ~110 ohm resistor, and the LED is going to tell you what you're broadcasting. All channels 0 will give colour 1, all channels 255 will give colour 2, and everything in between... you get that, right? Proper wiring solves a load of problems with DMX, it's simple but delicate protocol! Long live ethernet, wohoh!

Is there a floppy in your diskdrive? Oh and that blacking out off all the lights is called a "feature" Just kiddin'; that's not normal if you're sure you're not doing anything which can cause that. Have you checked if your DMX output signal if good enough. Blackouts can easily be generated by faulty DMX wiring; max. 25 aparatus on each line, use DMX cable, NOT microphone; use a terminator and if you're making distances; use a proper (galvanic seperated) booster to get your signal to the other end of the line.

But that wasn't my question now, was it... Just kidding... I'm getting a little bit afraid that the next software update (next year right?) is going to be not much more than some bugfixes and small features and the suggest a feature forum is going to be closed soon. Not that I don't understand all the effort going to F2, but it's still a pity. And in the other topic K-Nine mentions that a save-file should be validated to check if it's alright. I beg to differ that. If the loading method is decent it'll complain about non-valid files and just not load those. If it doesn't that would be a MAJOR bug report, and I really mean that; that would be louzy programming all the way (not saying I'd do better though).

Okay, so it's possible to rename a show using a normal computer, but you cannot overwrite that show. I think it would be a nice option if current shows on the floppydrive which have a different name than the default ones are included in the "save show" screen; that way it would be possible to name your show (that's a lot better than writing on a piece of paper which show is what) and save when you update it.

Maybe a weird request, but I would like an offline editor for pallets. I'm not that much interested in the positions, but I am in colour & beamshape pallets! Because almost every fixture manual contains a specification of what the different channel values represent it would be a quick & dirty way of pre-programming your show. If you want to do the same thing now, you'd have to open the Phantom Frog, select the fixtures, use you're mouse to scroll to those values and then save the fixture. This would be a lot quicker if you could just load a show with assigned fixtures, map values to every pallet (spreadsheet style) and save it, leaving all other data intact. I guess it's going to be covered in Frog2 with the numeric pad, but since I won't be owning one any time soon (or just not owning one) this would be a nifty little piece of software. If you could specify the way the shows are saved I'll write one myself

YEAH! Now thats a good one indeed, clearing manually takes about 5/10 minutes I've done that a couple of times now....

Laubfrosh is right; check which mode you're running and you'll see it has to do with that... I fu**ed up a few times with that fault!

Ok if that's true this is indeed a major bug, and should be solved! I was planning on creating a really well thought of default show, but that's really no use if I can't delete any fixtures from it.

Hehe I thought about that, but decided not too... putting in dimmers & console for this, a little overdone don't you think But maybe in the future, I've been looking into some LED solutions, there's definitely some cool stuff available. I'll just stick with this for a while, although I might get some more PARs.

Most operators seem to be posessed by everything that illuminates How does that reflect on your life? Give us the most uncommon things you do so people know you do lighting. For instance, I redecorated my room and couldn't help putting in some PAR20/PAR30: And NO: those are not gay colours, that's just the photo! This winter I'll be putting in 180/115 for a somewhat cooler atmosphere (hey, I'm called ice for a reason!)

That gets thrown around a lot here. I know budget matters, but I don't think it has anything to do with user friendly-ness... The term user friendly doens't apply to the features of a device, but to the way those features can be operated by the user, and that has little to do with budget, more with the smart thinking of the designer (they always keep on bugging us with "think like the client would think", a stupid line but I guess it does work). Just a little reminder because a lot of requests are met with "budget" lines.

Did you try reprogramming the submaster? I've ran into some weird stuff using the subs, but reprogramming always solved the problems (too bad because it's hard reproducing bugs like that )

Thinking of that... it would be a rather cool feature if pallet 1 became the "HOME" pallet. Programming pallet 1 would overwrite the fixtures HOME parameters. Okay that won't work for brightness, too bad. Leaving pallet 1 unprogrammed would not change the home parameters and use default, fixturetype programmed values. I noticed I always program the HOME values at pallet 1, so it wouldn't change my way of programming And for the operators unwilling to sacrifice a pallet for such a function, add a superuser option "overwrite default HOME" with yes/no as options... done deal!