cheers RK. Very useful info there man, Thanks!
Simplified.. IS there a plan to change or modify what we refer to as executors in Ma3, in the future?
Thanks guys. But that brings me back to the previous question again. Now that a seq is essentially its own handle, what is the point of having execs at all now?
We may as well do the same thing with any object, and then scrap the executor all together. To be clear here, I have a an expert understanding of ma2 (bold statement I know) and I completly understand what you guys are saying already. I know that execs handle other/non seq object types. I think maybe I'm not asking my question clearly so I will try rephrase it.
What was/is the intension or reasoning behind changing playback ownership from the primary vehicle built to handle playback objects in MA3 (The Executor) to the Seq (object) When the exec is still primary the vehicle of handling playbacks of all other non seq playback objects? What is so special about the seq now, or what was wrong previously that required this to be reviewed?
Previously playback handles had one of the highest priorities within the system, only exceeded really by output and some other things for example. So changing playback ownership back to the object its self could kind of mess with insurance we used to have here. If you've ever experienced ma2 go into a loop, you'll recall that touch and most other functions (Fixture output calculations, any HID ect) become unresponsive, But mission critical stuff like canbus, networking and physical execs are still maintained to the highest degree possible to sustain output. Will a move to a more virtualised handling of seq object playback be better or safer? Or is this a sacrifice for less restrictive development conditions in the future? Or a change made for reasons i haven't or cant imagine?
Forgive me for wasting anyone's time with this, I'm just very curious about changes to stuff like this, as these things will shape some of my discussion making processes while I try develop new workflows for my transition to from Ma2 to Ma3.
Yea I know all about execs as playback handles, what I dont understand is when you say "seq owns playback in ma3". Normally its the exec that owns the playback of what ever object is assigned to it or a seq could own playback if it is called directly without being assigned to an exec.
Eg if a seq is assigned to an exec, playback is owned by the exec when that exec is called. If that seq (not the exec its assinged to) is called via the command line, then the seq would own the playback?
Tapping on the Label in the playback window acts as tapping on the label in the playback bar (i.e. opening the assign menu). Tapping on / otherwise interacting with the executor section (i.e. buttons / faders / knobs) will act on the button/fader/knob.
This is all working as expected. "Page 1.201" = Page 1 Exec 201. In general in grandMA3, "<object> x.y" = <object> x <child_of_object> y, and executors are children of pages (in the tree structure). If you just say "Exec 201" without specifying the page, it will be Exec 201 on the current page.
This contrasts with grandMA2 which had lots of inconsistency in the syntax "<object> x.y.z" for which of x, y, and z was the grandparent, parent, object, child, or grandchild object.
Select + empty exec behavior is expected.
Master 201 At 100 = illegal object is expected. "Master" is the parent object for all selected, grand, speed, and playback masters. "FaderMaster" is the keyword to set the master fader level of a sequence. In general, perhaps have a look at this thread.
Hey Ryan, if playback is owned by the seq now and not the executor, what is the point of executors other than them just being a handle for a sequence? Is the idea to eventually scrap the "executor" handle and just refer directly to seq handles as playbacks or something?
using Page x.y to refer to executor y on page x is not mandatory.
If you are more comfortable with using the Executor keyword please do so, and use either of the first three of the four syntax variants below
Go+ Executor 201
-> Go executor 201 on current page
Go+ Executor 201 Page 2
-> Go executor 201 on second page
Go+ Page 2 Executor 201
-> Go executor 201 on second page
Go+ Page 2.201
-> Go executor 201 on second page
Thanks mate! Unfortunately this isn't what I was looking for. I was looking for a way to action an exec from the exec tool bar at the bottom of the onpc screens 2 and 3 with the mouse or a touch gesture, without needing to open the playback window. The master level indicator would be a perfect place to build this function into, as its intuitive to try and click there, and has more screen resolution than the the virtual fader in the playback window. Also syntax to control the level of an exec fader. Direct control in the main UI is needed for objects such as special masters, eg for the rate multiplier functions, so it makes sense to at least have a gesture build in or to give parts of the exec (not including its label) some form of direct user interaction control.
You comment brings up a good point though in regards to what I was saying is an inconsistency with syntax in my situation. where its not possible to address an exec fader level using the exec keyword, but it is possible to address an exec fader using the the page keyword. Your example syntax shows that both can be used in some circumstances, but not others. which I think needs to be addressed at some point.
Cheers for the response Ryan. I tried variations of fadermaster to set exec 201 to 0 and full and those didn't work either. The only way to make it work is to omit the working name of the object I am working with (the exec id) and refer to the object as a page part, which seems counter-intuitive to me, but its not all about what i think i guess.
I am able to control the exec using the playback window, but am disappointed I cant just run an exec's fader up via the exec master level indicator with the mouse, or at least a click and swipe gesture or reset an temp exec with the mouse, from within the main letterbox/playback bar. That was a really handy feature that negated the need to call a new window or have a new view that I would only ever use for that purpose.
I'm far from having a robust understanding of MA3 yet, but I still think something fishy is going on with execs though. an illegal or wrong syntax shouldn't create a new seq, assign it to an exec then move said exec to a random place in the second playback bar. especially when non of the syntax used referenced any exec id/number. IE when trying to effect a change on only exec 201, using only the numbers 201 in the command line and not using any action words like "move" or "copy" or "assign" or object handles like "sequence". Its strange to see a new random seq created, and it be assigned to say exec 150 by its self. or an exec or seq that isn't referred to at all being moved.
For example if i click in a the empty seq 7 pool tile, i would not expect a new seq to automatically be created at seq 11 for example. Defiantly not just by clicking, and without having the store keyword or shorthand in the command line.
Thankyou for your patience, and for explaining thins! Going to take a long time to get used to the new structure. "exec 2.201 at 0" was a far cry more logical and easier and to remember than "fadermaster page 2.201 at 0", But i understand their reasoning here. I just hate that I cant make "this" do "that", without omitting the real world name of the object. its like the statement "Something else do this" . kind messes with the whole point of nomenclature in an object ordinated system if that makes any sense? Maybe they can allow for both in the future as a compromise
Activate dimmer layer
Store cue x /r
Hi, with MA2 we used to be able to flash or toggle an exec of change the level of an execs master via the mouse/touch screen/HID
How do I do this now?
Clicking anywhere on the exec 201 icon pulls up its edit context menu, regardless of left or right click or where those clicks are made or if the click is held/dragged, or if gestures are used like the spinning motion used to drive the rotation of virtual encoders. it seems to me that i am going crazy. OR like there is no way to physically handle basic controls of an exec using touch or any human interface, which I would think is counter intuitive to the heavy emphasis on UI gesture with the rest of the applications functionality. or maybe I'm doing something wrong?
Also, if I try to edit exec 201 by typing edit exec 201, the edit context opens and exec 201 flashes red as expected, but if I right click exec 201, CLF says the the syntax executed is "edit page 1.201".
I can then say "on 201" or "off 201" and this works.
but If try "on exec 1.201" nothing happens, while "on page 1.201" this does toggle on exec 201.
for a command (where i want to specify the page the exec is on) I have to use on page 1.201" even though the object that I am really meaning to refer to here is an executor. This is confusing and in my opinion should change no?
Other oddities i have noticed are listed below: (not using keyboard shortcuts)
store exec 201
If I type "fader" into CL and touch exec 201, a new seq is created and assigned to exec 102. doing this again moves exec 102 to exec 103 and so on.
If I type "fader at 100" into CL and touch exec 201, a new seq is created and assigned to exec 102. doing this again moves exec 102 to exec 103 and so on.
if i type "fader 201 at 100" the command is valid and executed, but the listed level of exec 201's master remains at 50%.
if i type "sel" and then click on an empty exec a new seq is made and assigned to the empy exec and is selected
if i type "master 201 at 100" i get CLF "illegal object".
if i type "exec 201 full" nothing happens.
if i type "Fader 1.201 at 100" CLF is "can not create object"
If i type "fader exec 201 at 100" a new seq is created and assigned to exec 102 and is selected
If i type "page 1.120 at 100" the previously (unintentionally created seq occupying exec 102 moves to exec 120
If i type "Page 1.201 full" the command is executed but nothing happens.
That was it. Cheers mate
Hey mate, what is your previous level of experience on other consoles and what were those consoles? do you have any specific questions, or do you now know where to start at all?
re mvr, i am seeing similar behaviour in mvr from capture.
almost non of the ma3 library fixtures ma replaces the mvr fixtures with, work.
Instead i have to swap kinds using the ma2 library, and only then do they work. however 3d info is usually always retained
Hi I recently updated to the latest onpc build from the previous minor version.
When I opened my show file, my fixtures in the visualiser continue running the phaser they were last running when the show was saved in before upgrading onpc. This was, running in the programmer when it was saved in the previous version.
The following does not release or stomp the phaser..
off page 1 thru
off seq 1 thru
off exec thru
off dmx thru
The off menu shows no playbacks are running.
The 2 seq i have in this file also display as not being active
I have no playbacks stored.
Highlight does interrupt the phaser output
positions can be called and can be cleared.
I am in session with a vis-key and a supported visualizer
There are no default presets assigned to any fixtures
The show file is basically a clean file with some views and an imported mvr stage
calling fixture thru, then toggling encoder page 4 thru 8 on, then releasing and stomping does not stop the running phaser.
oh well in that case, just assign fade or delay time to the cue ; replace the preset ; go the cue
what you are looking for is potentially done via program time when stepping out and back into the programmer, or by using presets with time data only and merging them. depends on your setup and if you are using the programmer or not.
Yea I have to disagree with you on a few points Jason. I think there is a decent foundation. if anything, having such a void in functionality will make it easier for people to start, as opposed to a software that has 50 unique ways and 500 tools to complete one task. They ended up loosing a lot of money at the end of the ma2 product cycle due to counterfeiting, so I feel as though that was at least some part of the seemingly rushed decision to make a move on ma3, and I'm pretty sure (but not certain) that the might have been let out of the bag a little to early on that too, which would have forced their hand a little to get it out quicker also as new sales on ma2 practically stopped at that point. Overall I really like the direction I can see them taking with this software. I can see a lot of placeholders for a lot of features that also had placeholders in the MA2 architecture, there were at least on a DEV roadmap, and I'm pretty thankful that these exist now, and will finally be coming personally.
I can see a future with in console video and audio capabilities, which will make the lives people working in timelines a lot easier, and defiantly provide some cool new ways to utilize large amounts of fixtures. Being a bit of a data nerd, I love the way data is handled now, and how they have given us tools to make thigs clean and elegant, efficient and organised like never before, but also secure which has always been a big deal to me. DEV is hard. So are interfaces. everyone has their own preference based on their own subjective experiences so its basically impossible or near impossible to create a system of software and interfaces that everyone will feel comfortable on, or even like.
That said, your absolutely right about hardware option. I know for a fact that bringing a single or 2 universe micro console that runs seamlessly in the ma3 ecosystem, and is small enough to lift in one hand and throw into the seat of a car (like the ma1 ultralite) would have been the ideal move.
I think MA Lighting has a robust product line in the onpc solutions, lite and full-size, but I see waste in control options unless they are built to order.
most importantly I think that a big market opportunity was missed with the middle and lower tear offerings. There are a lot of new people who are being exposed to hardware and software solutions that are now just as capable as MA2/3 AND backwards compatible! So the value of MA in this new and emerging user market is not there. I think that the dot2 was at its heart supposed to address this to some degree, but from what I can see, it didn't because to cost prohibitive for the market here, and with such a short lifespan, and economic downturn, I see many companies and individuals in my part of the world seriously looking to alternatives now. Mainly driven by the ultra high entry cost in my part of the developed world, which is not in line with local inflation or the economic conditions most businesses have been working with since way before Covid-19. Conditions that have been worsening over time for the last 10 years now due to prohibitive government innervations, and generally poor economic conditions that have continually reduced budgets, investment and and spending (public and private) across all facets of the sector. While many analysts predict a boom in entertainment next financial year (post covid) It is clear to many national stakeholders that they will not be able to afford to upgrade for a very long time if at all. And many are now cautious of buying into an ecosystem that is no longer as value competitive in our market. Maybe a subscription model for onpc and a drastically reduced hardware price would be beneficial to both MA, and its end users/clients?
I think a large payday will come for MA when covid is over in the big global markets, and that should see a boom in dev speed, but the biggest investment they as a company can make now, is a cheap robust product offering that is as common place to factories, shows schools and rental houses etc, as a utility tool is to anyone who works in technical and theatrical production.
Something like ETC/HES hedgehog, but at a price point that is actually less. Even if it costs money to get them out there, it would address the needs of many who are not even considering MA's awesome products. MA should also address what I see as economically adversarial pricing in regions with lower populations like mine. Because right now I could buy a console brand new (with cash) from north America, Asia, or Europe, have it shipped to me and it would cost significantly less than it is thru official distribution, even after the settlement of currency conversion, tariffs, taxes duties and all other importation fees and liabilities. Of coarse that doesn't jive with the sales model, and technically distributors over seas are not allowed to export, but when an arbitrage opportunity arises like this, someone will always be looking to take advantage of it, even if it means no service or some kind of punishment, because desperate times call for desperate measures, and times are very tough for a lot of people out there right now, including companies like MA!
This is just some observations I've made within my local market though, and to be fair the industry here is tiny so no product manufacture really cares at all about such a small market. But they defiantly should be more proactive when it comes to on-boarding new users all over the world, especially given that those new users will eventually be the ones that are requesting consoles for shows, and requests drive purchasing. I fell as though I got a bit off topic HAHA.
I'm looking forward to 3d mapping large 3d fixture arrays, really fast workflow automation, and spending more time being creative with less time spent on administrative tasks. All of which are features MA have brilliantly built into the core of ma3 [if you know where and what to look for] after listening to what we the users want/need. That's another hard thing to do too, because of the variation in how people use MA software, and the kinds of applications they are using it for. In the future i think developers will ultimatly end up cornering the different markets, rather than trying to offer a one stop solution, although MA has done a pretty good job in making a one stop shop solution for a very long time now.
So for me the future is one of caution initially, but very bright with MA3. Some people will find its more work, others will find its less. I'm somewhere in the middle at the moment, but I'm not an expert yet.
If its for timecode, you can apply a physical speed master to the timecode and adjust the curve as you like. You can also use a dmx remote to control the speed master, then just store the dmx remote into the cue as a dim value and fade it as part of the cues fade time, or with individual timing
Its in the cue part.
I swear ; I saw it ; yesterday ;
Call it then
If you dont want to physicly call it you could try to do it in blind maybe.