Another observation regarding this:
Cue 1
Cue 2
Cue 3
Move Cue 1 at Cue 4, then Oops =
Cue 1
Cue 3
Cue 2
Another observation regarding this:
Cue 1
Cue 2
Cue 3
Move Cue 1 at Cue 4, then Oops =
Cue 1
Cue 3
Cue 2
Same here.
But only with on-screen keyboard.
Computer keyboard is ok.
CapsLock on On-screen keyboard also switches the numbers to !@£$....
Normal CapsLock don't do that.
With my iPad I have found two solutions to access all playbacks.
The best might be to remove the View bar on the right (Settings/Configure Display/Show view bar)
That leaves me with 10 cells width and room for all 15 executors.
Like this
The other method I mentioned was making the playback window wider than the iPad can show.
I'm sure this can be done with the command line but I can't tell you how.
What I did was log in on the desk with the same user profile that the remote use. Then you can extend the window.
You should now be able to scroll with 3 fingers on the iPad.
Hope we have been talking about the same thing
Note that in Playbacks Window Settings you can turn off Rows you don't need to make things a bit bigger.
E.g. only row 200 for longer faders.
I notice now that if the Playback window is 10 cells wide it shows all 15 executors, if it is 9 cells wide it shows only 10.
If that's the problem you can make the window wider on the console (try 12 cells) and THEN the 3-finger scroll works (On my ipad at least...)
Try scrolling with 3 fingers.
There should be small scroll-handles too, but they can be difficult to grasp.
Thanks hoss, I've tried and the XML was valid.
This is not currently a problem for me, I just tried it out.
The data is just a mess of some days with testing, but I attached it if someone are able to investigate.
I exported the Default Data Pool and tried to import it to another Data Pool.
My Light CRV restart every time.
If I make a new pool, add some data and export/import that it works.
If I copy the Default pool and export/import from the copy it restarts.
Any known issues here?
While editing a DMX Mode that was in use I deleted it by mistake.
Oops brought it back, but all references to it in the patch was gone.
Just like to mention in case you want to make that oops-able too,
I'll try to be more careful next time
After testing MIDI remotes I ended up with the following translation and notes.
Maybe it could be useful to others.
My test was mainly with Target = Sequence, Fader = Master and Key = Go+
MA3 interface name >> Name if I could decide
Midi Channel >> Midi Channel
Midi Index >> Note/CC number + 1 (MIDI range 0-127, MA3 range 1-128)
Midi Type >> React to:
Note >> NoteOn
NoteAttack >> NoteOn + Velocity
NoteAttackDecay >> NoteOn + Velocity + NoteOff
Control >> CC message
- NoteOn will trigger the command in the Key column
- Velocity will be sent to the destination in the Fader column with optional scaling/inversion applied
- NoteOff seem to send fader to zero and disable the selected fader function...?? Need help here!
- CC message will trigger the command in the Key column if its value has changed
- CC value will be sent to the destination in the Fader column with optional scaling/inversion applied.
- I have not understood/seen any effect of the "Trigger On/Trigger Off" values.
- The idle value of 'in' for Note and NoteAttack is 12800.0008, small glitch I guess.
- Not all destinations seem to use Velocity value.
I applaud the flexibility here!
Seems like everything can be controlled with MIDI.
The information is based on my test only so please correct me if I'm wrong or not precise.
Lot's of scenarios here and I have given it some thought.
What if the programmer was switchable Pre / Post sequence masters ? (Called Fader from here)
Values would always be grabbed Pre Fader and adjusted Pre Fader. (As it currently is)
Only the viewing/output of values would be Post Fader(s) ! (Like it currently is with Group Masters)
In "Pre Fader Mode" it would work exactly like today.
In "Post Fader Mode" all jumps would be gone.
Scaling issues would disappear.
Fader could even be adjusted after the grab.
Reference to Presets could be kept, and Presets could be updated as usual.
With 'Grabbed' I mean 'Please Please', On, Edit Cue or similar.
And if we do need the actual current value we can still press the encoder and get that.
Last method could preferably ignore the Post Fader setting, but one could also switch to Pre Fader of course.
What do you all think?
I'm sure there are issues I have not considered, but I think this would solve it for me.
Until now I've actually thought this was trivial
One thing I want to do is get the value seen in fixture sheet into the programmer.
(For instance if I want to adjust a value live on stage and make sure I don't get a jump.)
I've tried On + touch Dim and I've tried to turn the encoder. Both jumps to stored value regardless of fader position.
(Do users really want that to happen when you turn the encoder too??)
What works is to press the encoder and then press please in the dialog box.
This is ok, but are there other ways? Preferably one that could be used in a macro.
Tapping Please Please does not seem to respect the fader position when it grabs values from a sequence.
That mean the output change. I assume this is not how it's meant to be?
(Manual says 'current values')
I just bump it because I was hoping for other views on this problem.
Am I the only one concerned about driving my moving heads crazy?
They don't exactly sound happy
Ok, I see it now. Sorry Ryan.
I was fooled when the numbers overlapped perfectly with no blur.
I also noticed what you describe, but in my case the numbers are actually wrong.
A seemingly random selection of the remaining (and unselected) 31 to 100 showed up.
As I mentioned, only fixture numbers from the same fixture type.
I patched 100 generic RGB just to test MAtricks.
I selected 1 THRU 30 and looked at the grid. All good.
I pressed XWings + one time and a lot of unselected fixture numbers showed up. Only from the same fixture type.
More observations:
10 THRU 30 is OK
9 THRU 30 shows wrong number
1 THRU 30 shows more wrong numbers.
('30' can change to whatever above 10)
It's only Selection Grid that is wrong, not the actual selection.
I noticed that Presets used in Step Recipe's are not considered to be referenced by it.
You will not get a warning if you delete such Preset and the Step Recipe is broken.
I realise that the preset content isn't really used anywhere, but maybe a warning would be good anyway?
To me the default clone scope seems to be Output..
But maybe I misunderstand the term 'scope'
If I clone without any "If", values from both sequences and programmer are used and put in the programmer.
The source is also put in the programmer - is that how it should work? Why do I want the source active?
When adjusting the speed (programming layer) of a Phaser the phase for the fixtures jumps like crazy.
This makes it harder to see the speed change, and for mechanical attributes I would think it's quite bad for real-life fixtures.
I notice now that adjusting Width makes even crazier jumps.
And speaking of jumps I'd like to mention some other issues:
Is it possible to set a fade time....
..when going in and out of "Single step"?
..When changing to another step number manually?
When creating a new Phaser, let's say we move PAN and TILT to the first position.
Adding step 2 leaves the fixtures in the same place and activates RELEASE for this step.
As soon as you start to turn the encoder the position jumps to default.
I believe it should start from the position it's already in.
Hi all
Reading this thread and the "One" thread I understood that I was not alone wanting to use HDMI screen with the console.
So I thought you like to know how I managed to do it.
I went from the console to a repeater that has it's own power supply. (Lindy 38413)
Into the repeater I plugged an active DP to HDMI converter (Aten VC986)
From that I went to my old Sony TV and it worked.
This was on a Light CRV
My theory was that the self powered repeater would supply the missing power to the active converter.
And I guess it did, but please note that while it worked on DP4 and DP5 it did NOT work on DP1 and DP2.
I wonder why...