Posts by autonic


    If anyone else is interested, I've written two functions to extract the attributes for each fixture's sub-parts.

    This is in no way a stable solution, but it works in Use with caution!

    I'm not sure I would call this a virtual attribute. You're directly controlling the real attribute of the (n-grand)child(ren) (doesn't have to be the direct child(ren) - could be an arbitrary number of levels down if none of the levels in the middle have their own real attribute).

    Ok... one could call it an "attribute-link" perhaps? (since no data is modified except on each individual sub-part if I'm getting this correctly?)

    To be able to quickly generate presets for instance... take the quantum wash.

    Main part is: DIM, POS, SHUTTER (but MA3 adds a virtual COL attribute here to control the sub-parts as well)

    Subpart1 is DIM, COL (outer led segment)

    Subpart2 is DIM, COL (middle led segment)

    Subpart3 is DIM, COL (inner led segment)

    Subpart4 is DIM, COL, SHUTTER (aura effect)

    Now, if I want to create an color effect for the LED-rings, i cant automatically select both the main-parts and the sub-parts to generate an effect, since the offsets would be wrong. I would have to use some "Block by" selection (and manually select the correct parts). None of which is hard to do manually.

    - Unless i wanted to create a color effect on both the LED-rings and the Aura simultaneously of course, then selecting only the main part would suffice.

    But if I could use the MA data-structure to figure out which parts that contained which attributes I could automate stuff much more accurately / fast. For instance, I could make the assumption that if both the main part, and a sub-part has it's own shutter (but not the other sub-parts), then that sub-part with a shutter probably isn't a part of the conventional fragmented led-ring cluster, and treat it accordingly, if it has a color attribute (exclude it when generating color presets / create a separate color preset for that sub-part).

    Well, the list could be made very long for all possibilities given, if you could determine which part of a multi-part fixture that contained which attributes just by looking at the data structure :)


    If you look at the Fixture Sheet, you'll see some parent attributes look sort of grayed-out (for example the parent dimmer in a Sunstrip). These are not real attributes and are showing you a summary of the corresponding attribute of their children.

    Quote from Autonic

    So if a SubFixture and the main fixture both has a real Dimmer attribute (unlike the sunstrip - but like the Aura) - does it mean that the main fixture's dimmer attribute always acts like a master for the subfixture's dimmer attribute?

    Yes, that explains the sunstrip in a logical manner (and thank you for that!)... But how do I determine which attributes that exists in which fixture, and which attributes that only are references, just by looking at the fixture?

    The Sunstrip has no dimmer attribute on Fixture 5 - only at 5.1 to 5.10. Which, if I understand you correctlty, means that MA3 then creates a "reference" to all dimmer attributes in all subfixtures and places that attribute reference in Fixture 5 (which "looks" like a real attribute). Now, how do one tell if the attributes available in Fixture 5 are real attributes for that object, and which attributes that only are references to attributes in SubFixtures?

    My idea here was to be able to determine this before maniupulating the attribute, instead of having to go back and undo changes made... is this possible, if so how? (and yes, I'm fairly comfortable using LUA)

    I've been looking at some fixtures with subFixtures, and I'm trying to understand their logic...

    For instance, selecting either the main or sub-part of a Mac Aura @ 100 does not produce output, you have to have set them both @ 100.

    On the other hand, when using a Sunstrip, setting only the main part at 100% also sets all children to 100% - while setting a sub-part at 100% does not require the main part dimmer to be changed.

    What's the logic here? I assume this is according to some paradigm I cant figure out - not just happenstance...

    The online manual mentions nothing regarding this and i cant seem to find any good information here on the forum. :/

    If i just want to be able to run a plugin and pass some parameters to it (not run commands), how do I go about that?

    Ok :)

    I've written a standard iterator for dedecting first available ID for now...

    Btw, in case you haven't found these helper functions already I'll post them (found them today):