Posts by gabe927


    Trying to write a plugin that can mimic rotating the attribute encoders.

    I already tried looking into the GraphicsRoot directory to see if I could find the functions that the UI is using, but I was unsuccessful.

    Anybody got ideas here? Alternatively, if there's a way to do it via OSC/MIDI that'll work for me too.

    Did some deeper digging into this. (This is pretty neat btw!)
    Also discovered that instead of typing the command using Keyboard(), you can interact with the graphics element directly and change the contents using

    Root().GraphicsRoot.PultCollect[1].DisplayCollect[1].CmdLineSection.DisplayCommandLine.content = "Insert CmdLine content here!"

    Do note that it seems that using this method puts the keyboard cursor at the beginning of the command line instead of the end. Still works however if you say change the contents to "Store" then tap some pool item or something.

    A_art is correct. In terms of workflow, merging the timecode events into one doesn't really make a ton of sense. Still, if that REALLY is what you want to do, it is possible with the API. I'm only familiar with the timecode API for some other projects I'm working on ;)

    I think I get what you're asking here (yeah I know it's an old thread, but whatever. I've been busy on shows lol)

    From my understanding, you want to "merge" timecode events from multiple timecode pool items into a single timecode pool with offsets for each item.

    This is actually fairly easy. From the command line, you can observe all your timecode data using "cd timecode (timecode pool number)". Then you can keep cd'ing through the different objects in the pool item.

    As for the lua element to this, you'll need to use the object API to copy data from the objects in your existing timecode and append that to the objects in your new timecode. For example, to add a new track group to timecode 1, the code might look like this:

    local timecodeHandle = ObjectList("Timecode 1")[1]

    local trackGroupHandle = timecodeHandle:Append("TrackGroup")

    This can be a bit daunting if you don't understand the object API, but biggest thing that helped me was the :Dump() function that you can add to almost any handle and get a print out of the data in that object.

    Hope this helps!

    Ok, so I did more testing. Here's what I found.

    Andreas Is correct, the plugin appears to be handled as a coroutine... at least when it's called via the MA Cmdline, not when the plugin is loaded. Here's a code snip-it of a test function I made to test this. See the notes I left as comments.

    Big takeaway here is that code not in functions is executed when the console is started or when you click "Save" after making changes in the plugin editor. This makes sense so that the functions can be made available for reference by the LUA engine (ie "loading" the plugin). Note that this code is run in MainTask, not a coroutine, compared to when you call the plugin via the MA cmdline or by tapping the pool object, it will run in a LUA coroutine. This can also be seen in the output of the System Monitor. (Notice the significant time differences!)

    So I came to realize that the initial flaw in my testing earlier was that I didn't put the testing code into functions and it was getting executed inside and hogging up the MainTask as soon as I clicked save... DOH

    (PS, gotta laugh a little when the test ends and you see watchdog errors for DataBase, LuaEngine, and Graphics... Those might be a little important lol)

    Going back to trying to run a TCP server from an MA plugin...
    Since the plugins are run as coroutines and not threads, calling server:connect() or client:receive() still causes the UI to freeze while it waits for a connection/data to be received. The only solution I could find is setting a small enough timeout for those functions so that it doesn't cause too much issue on the rest of the system. Not ideal, but it works I guess.

    For those curious, the code I used to test the TCP server is below. The coroutine.yield(2) calls were so that I could see the Echo outputs in the System Monitor and so I know which functions were causing the UI to freeze. If I remove all coroutine.yield(2) calls, the UI will freeze until the plugin is finished. I used Telnet via PuTTY as a client.

    I've been doing some experimenting with LUA. I have a project that would benefit from running a TCP server on the MA plugin and I've discovered that the LUA engine in GMA3 handles processes completely differently than in GMA2.

    In GMA2 this was no issue since each plugin kinda ran it it's own thread (seems to run a lot like the GIL in Python in my basic observation). You could have a TCP server or any forever running loop for that matter and it would just run in the background. Actively running plugins would display a little yellow triangle while it was running and you could call other plugins and continue using the UI.

    In GMA3, it seems that the LUA engine is running critical parts of the UI and does not create new threads for plugins, meaning if you call a plugin with a constant running loop, the UI will freeze and the software will become unusable because the plugin with the loop is now blocking any other code from executing.

    So, knowing this limitation and my limited knowledge with LUA, does anyone know the best way to create non-blocking code (coroutines, threads, MA API, etc) for MA 3 plugins?

    Disclaimer: My observations are simply observations from testing plugins and the MA software and I do not claim that it's how the software really works under the hood. If I'm wrong about something, please feel free to correct me :)

    Also, my observations are only with onPC for Windows. I have not tested this on Mac or on a console.

    Dude this plugin is killer! I will give it a try later, I think that is a fantastic resource you've chosen to share here!

    Side note... what JDC profile are you using?

    Thank you!

    It's one that I built from scratch from what data I can gather from datasheets (I don't have access to one unfortunately). It currently only has the dimmer/color channels for the elements. Still working on getting all the shutter/control stuff in the profile. Getting each channel set made can be a pain sometimes, though I might just try to copy-paste that stuff from the converted MA2 profile and see what happens.
    I'll put it on GDTF-Share whenever it's done. I've only been using it for messing around in 3D, so progress is low priority. If there's enough demand, I can make it a higher priority.

    hi gabe just download your lua but i think it miss the xml file to be recognize when import it in Onpc (shared Lib_pluging folder)

    My bad, I did not upload the XML anywhere. You can find the XML file for import in the releases on the github page now.
    FYI, for future reference, you can just copy-paste LUA scripts into the plugin editor instead of importing an XML.

    V1.1.0 has been released!

    The major addition for the version is group layouts. This will create a group for each subfixture element for ALL fixtures selected in the main layout view and create a "groups layout" which is identical to the template layout, but with group elements instead of subfixture elements. Enjoy!

    As you all may or may not know, in MA 3 you can use the camera views to help arrange elements in layouts, however this only works for the primary fixture instances, it does not work for subfixture instances.

    As a result, I built this plugin. It takes the layout view built by the camera arrangement and replaces each element with an array of subfixture elements that you provide via a template. I thought it was quite handy to have in my programming, so I figured I'd share it with all of you lovely people :)

    Code and usage instructions are on the Github page.

    Please let me know if there's ways to improve the code or if any issues show up.


    Feature request on this topic: Could we get a toggle switch in MAtricks to switch between the current behavior and that which is calculated with the encoder bar? I can see a use for both instances, but I would like to dynamically change the number of fixtures in a recipe and not have to change the phase every time.

    When fixtures of different beam types are set to an non-zero intensity at the same time, the 3D window tanks.

    For example, I have a fresh show file with an x4 bar using the "Wash" beam type and a JDC-1 with the "Rectangle" beam type placed next to each other.

    As shown in the pictures below, when either fixture is turned on independently, it works fine showing 63 FPS in the upper right corner.

    However, turning both fixtures on at the same time causes 3D performance to significantly drop down to 3 FPS.

    This was observed while running onPC with v1.6.1.3 and previous versions as well. I'm not able to test this with other hardware as I don't have access to them.
    Turning on 3D Priority has the same behavior.

    This behavior exists in all BeamQuality modes except None and Line.

    I've also observed that while both fixtures are on, GPU utilization is LESS than idle utilization with both turned off but 3D window still visible.