I see. That makes sense. But that wasn’t the situation in this case. I had data already stored throughout the sequence and suddenly there was release values where I didn’t expect it to be.
However, it very well might be a misstake on my part. That’s why I don’t want to jump to conclusions to early. I’ll investigate some more🙂
Thanks for your quick reply, Ryan. Do you have an exemple of such a circumstace? I need to try to recreate this problem again to find some kind of pattern. I didn’t have a lot of time and needed to do damage control. The manual clearly say ”The existing tracking values are not released but are protected from future changes”.
What I’m looking for is if any other user has run into situations were the break does not behave as expected.
Has Anyone encountered a problem with the break function? I tried it out and it released some fixtures instead. Strangely it was limited to one fixture type, Robe Esprit, and not to any other fixture types.
I don’t know if it is a bug or if I did something wrong, so I would like some feedback from you fellows in MA land before I report it. 
Are we talking 3D or in the real world? I’ll assume the latter for the sake of this; When you invert the encoder you only invert the direction the encoder takes you in, if that makes sense. Say you have two fixtures, of the same type. But one is hanging with it’s display pointing upstage and the other pointing downstage. You can invert the tilt encoder so they both tilt in the same direction.
However, if you put 45 in to the calcylator one fixture is gonna tilt in one direction and the other one in the opposit.
You wouldn’t notice this when using the encoder though, because on one of the fixtures the encoder is inverted and therefor tilts in the opposite direction.
I hope this make sense.
Disable the Sequence Setting "Wrap Around", and then you can give the OffCue a Trig Type, e.g. Follow. (I know this does not solve Logan's request, since they want to have multiple break points in the sequence. But it should solve your scenario.)
Cool! I'll do that!
That mode functionaility haven’t been implemented yet, as far as I understand. I have just made an auto cue in the end of the sequence with the command ”off sequence x” as a workaround.
There is a lot of workarounds needed at the moment, unfortunately.
Are a software release around the corner? I have a quite long list of wishes and bugs, and the theatre I’m working on are considered a ”key user”.
But if MA plans to release a software uppdate in say the next couple of weeks it’s better if I keep the list to my self and check out how much I can cross off it when the new update drops
This MA Tips Video addresses stomping and relative vs absolute phasers.
grandMA3 | MA Tips [EN] | Double tap on Presets
Yes, that’s a good work around at the moment.
Very much disagree. Both familiar tools & workflows we're used to from grandMA2, and also new and more powerful functions should, indeed must be worked on at the same time. If you don't work on the new stuff early on, then once you've duplicated everything from grandMA2, you're back in the exact same place you were before. The groundwork for new core functionalities, for example Recipes, needs to be implemented early or else you have to tear down and redo lots of work later on which risks breaking things all over the place. Additionally, implementing something new, such as Recipes, early on allows users to help shape the direction of the new workflows and interactions while things are still fairly easily malleable.
That is absolutely a good point. I don’t agree completely, but interesting to hear your oppinion.
However, I still would like this funktion to work.
Stomp command doesen't seem to work as expected.
1. The stomp command is applied to both the relative and absolute layer, regardles of where the phaser is. In my oppinion only the layer that has a running phaser should be affected.
2. Instead of knocking in the last single step value on the absolute layer it sometimes brakes the preset reference but I get the right values, sometimes it knocks in a random value that is found somewhere in the sequence. Sometimes it works as expected though. It's really not possible to use at the moment due to this inconsistency.
If I'm using the command in the wrong way, please tell me. I'd be happy if MA looked into this quite quick. I think all the new functions and features of MA3 is great. However I do think that MAs priotities is a bit of the rails when functions that worked perfect on MA2 don't work on series 3 yet. Like mentioned Stomp. But also X-buttons, Brake cue and I could make the list longer, but I won't right now.
In my oppinion, the priority should have been making what worked and what programmers used everyday on MA2 to work first. After that adding new functions.
It would be interesting to hear you fellow MA3 users oppinion in the matter.
Is there a way to clone objects from one layout to another? I also try to clone the appearance inside a layout from one fixture to another. Like multi instance fixtures for example, like I do in GM2 with ”clone appearance fixture x at y if layout z”.
Perhaps I’m just not clever enough to find it how to do it.
The referenced-by-cue symbol is only the arrow, says the manual. So that’s why I suspect this beeing a bug.
But it’s not the end of the world. It probably gets fixed in upcomming versions🙂
Presets get the symbol of referenced by other presets when only being referenced by cues, NOT other presets (downward arrow pointing to a line). My guess it’s a bug?
I may have misunderstood, in that case I apologize, but I don't really understand the changes in the way that the X-keys work now, compared to GMA2. I get that U1 toggles the x-keys overlay in the executor bar and that the U2 key toggles the executor bar. But my problems are the following:
1. If I don't happen to have a command wing at the moment when programming at home for example, then it's really not practical to use the x-keys at all since I don't have an U1/U2 button. I can make a macro of course, but that's beside the point.
2. I realisticly only have 16 x-keys now, compared to GMA2:s 40. Since the X-keys page, or U1 page or whatever you want to call it, changes when I change to another fader page. I can fix my macros to always be accessible, of course. But as I said, then I only have 16 buttons at my disposal.
Have I misunderstood this whole concept? Is this going to change in future software versions? Is there a way, that I haven't figured out, to fix a certain executor page to the "x-keys-executors", if that makes any sense? I mean, a way to not make that page/those pages follow the regular fader pages when I toggle between them.
If I could wish for ONE thing when it comes to MA3, is would be that this would work like it does, or similar, on GMA2, because it works really great there, in my oppinion.
"Wunderbar" wasn´t suppose to have a questionmark after it, sorry:)
Cool! I’ll try that😀
On my wishlist for upcomming software versions, is the posibility to create appearances pool objects with a macro. Kind of an autocreate for appearances, so I easily can get like 40 different colors in the appearances pool. Like I can do in MA2 with the predefined colors.
Anyone having the same wish?
I suppose I can make a workaround by manually creating all the appearances I want and then export/import them to another showfile. But an autocreate would be great.
Hey mlogdstrom,
you are right, this behaviour will change. At the moment the individual timings are grabbed and you have to switch them off automatically. But we are working on it.
Wunderbar?
Hi guys! I have a related issue. When using ind.fade on some fixtures (maybe delay to but I haven’t checked), when I change values on those fixtures for my next look the fade layer automatically gets activated. If I forget to adress that, the next cue will get the same ind.fade values as the cue before.
I suppose that’s a bug?
And also related to that; when I’m in an active cue with ind.fade in it, then programmer time does not work. Actually the individual fade values gets forced to become a ”programmer time” of sorts, when I change the values on the attributes that where using that particular ind.fade time.
You probably know of these bugs allready, but I still wanted to adress them. There quite problematic.
Ahaaa, I think you are on to something! Nice work, thanks! I still use MA2 for all the ”real” programming, but I’m learning MA3 of course:-)
I’ll send MA another mail about it! Have a nice weekend!
