Search the Community
Showing results for tags 'speed'.
Hi All I am using the Solution at work and have something I can't work out. I have been programming chases with our moving heads which works fine but when I want to run a very slow chase say 5 bpm the movers will go to the first step in the chase then wait for a few seconds before the chase continues and repeats. Once it starts its fine and there is no pause. If I use say the default chase speed of 60 bpm I don't have this problem. This might be how its designed to work, if so is there a work around the issue? On a slightly different note I did the upgrade to 7.8.2 the other day and had issues with channels 31 to 33 on the fader bank. 31 did nothing at all 32 and 33 worked but then got stuck at 1% when bought back down. Restarting the desk fixes this but it then happens after a little while again. Any idea's? Thanks Jack
Hey guys, We recently obtained a jesterML 24 deck and it works really nice. We have updated to v3.3 and we are using fixture library 25. Up till now we have actually only used it in manual mode, but now we are at a stage that we want to program chases. Our basic setup consists of some led pars and some moving lights (scanners). We also have some conventional lights, a strobe and a laser. (for the laser we made our on fixture) We would like to use the build in figures for the moving lights for our chases. As we are primarily working with live acts, we would like to control the speed of the moving lights (by using a submaster) independently of the chase speed used for our led pars. This way we can make a consistent show. In an ideal world we would like to obtain the following: We would like to have 1 submaster fader that affects the speed of the moving lights, but does not affect the type of figure, figure middle position, and figure size. For the figure type and position we would like to use palettes, and for the size we would like to have another submaster fader (affecting x and y). We know that this is not possible, as these parameters cannot be untagged, even if one selects the channel mode in the setup menu. We understand that these parameters are related and thus one cannot untag these (although in theory it should be possible by dynamically adjusting the different parameters, but I guess that the firmware does not support this). So our ideal goal is not possible, thus we thought that making different submasters for each programmed figure, for a fixed size and a fixed middle position should solve this problem. We thus programmed a submaster as a scene with all position parameters in absolute mode, except for the speed in relative mode. Now, after programming we tested the fader, and what happens? If the fader crosses the 5 % the speed of the movement directly increases to the maximum value. Further increasing the fader does not affect the speed at all. We tried different settings between relative and absolute mode, but the results are the same. We think this problem occurs due to the reason that the speed parameter can be a positive and a negative value. Maybe this can be solved by using one absolute speed parameter and one parameter indicating the movement direction. Maybe this is possible by a firmware update? So this is not working for us. The next thing we tried was making a chase and only adjusting the rotation parameter in the relative mode for each step. The only thing we have to figure out is the amount of steps required (and thus the amount of rotation degrees) for a full rotation to make a consistent show with respect to the led pars (we don’t want our moving lights going crazy while the led pars are fading very slowly). We tried to make a chase of four steps with the rotation parameter in relative mode of 90 degrees. Upon testing the chase however, the lights aren’t moving (We adjusted the chase speed). We are thus questioning the difference between relative mode and absolute mode. We tried the same thing for different modes (absolute/relative) but now we made four steps for different rotation settings: step 1: 0 rotation step 2: 90 rotation step 3: 180 rotation step 4: 270 rotation During testing the next thing happens; if the chase goes from step 4 to step 1, the movement direction is inversed and in one step the light rotate 270 degrees, instead of increasing 90 degrees to 0 (the starting position). We tried this also with the last step in relative mode but the same result is obtained over, and over again. So, our conclusion is that we cannot use the build in figures for our chases! Our only option (as we see it now) is to program our own steps with the x and y position, while keeping in mind that a certain amount of steps are needed to match the chase speed of our fading led pars. Now this will be a lot of work as the size would again affect the amount of steps needed. But, we are guessing that we are doing something wrong, as the build in figures aren’t programmed for nothing. Can one of you guys explain how to tackle this problem? Thanks!