Posts by Ryan Kanarek

  • TILT ENC INVERT 1.7

    As far as I understand, this is the correct behavior. Encoder Invert says when I spin the encoder in the direction that would normally decrease the value, increase the value instead (and vise versa). But entering a value of +10 is still +10, not -10. If you want both the encoder and the actual typed-in value to be inverted, you should use DMX Invert.

  • DataPools + Recipes

    When the patch initialization part of PSR becomes a thing, then DataPools become a super easy way to merge show files (e.g. at festivals), because you can just import the entire datapool as a separate object and have your entire show with everything in the same position without having to worry about moving things around, etc.


    Quote from Clintos

    within a preset pool you should be able to select the data pool to use.

    Yes of course you should be able to. This was my understanding of the plan from the beginning. And of course with any object type within the datapool, not just preset pools.

  • DataPools + Recipes

    I would not say this a bug. Copying an object keeps the references the same as in the original object. In this case the references just happen to be in a different DataPool. What could perhaps be added are some options when copying across data pools, maybe something like:

    • Keep Original References (what it does now)
    • Replace References, but keep original if corresponding object does not exist in new data pool
    • Replace References, and discard original if corresponding object does not exist in new data pool (possibly resulting in hard values in some places)

  • Collections

    [Select][Select](holding the button with the second press), then tap a bunch of non-consecutive groups or presets, then move or copy them all in one go. For example.


    Quote from hoss

    Also the release notes say you have to type Collection on the command line to clear them but Select Select PleaseSeems to work.

    I believe that note is left-over from earlier in the development process, and should be getting corrected (at least, in the online version of the notes).

  • 1.7 release notes

    Quote from Clintos

    I think what is being missed is in previous versions if you change the programmer parts in the parts window and then used an Encoder then it would jump back to part zero.

    Yup, because it was always using the part as determined by that presettype pool's Cue Part setting (which for everything was by default Part 0), even for spinning the encoder.

  • 1.7 release notes

    Yes, that is my point. It is the same setting - the {Cue Part} setting of preset pools affects both presets and values.

    • In v1.6 the Cue Part definition was always used for both presets and values regardless of the currently-selected Programmer Part.
    • In v1.7, if the Cue Part definition is not default, that will always be used. If the Cue Part definition is Default(0), such presets and values will apply to the Selected Programmer part instead.

    And that is what that Release Note is saying. I don't think this is an undocumented functionality change in v1.7.

  • 1.7 release notes

    If you changed the "Cue Part" setting in the preset pools, then that information would go to the specified part in both the programmer and in cues. The part I quoted from the Release Notes is the improvement that makes this way easier (because before, everything defaulted to Part 0 and would stay there even if you selected a different Part). So it was technically possible to work that way before, but now it is much easier.

  • 1.7 release notes

    That is actually not new to v1.7! It's been that way for a few versions now.


    What was improved in v1.7 includes this note from the "What's Changed" section:

    Quote

    Presets that are set to CuePart 0 within their settings are now called into the selected programmer part, and not into programmer part 0 anymore. Presets with a different dedicated programmer part will always be called into this dedicated programmer part.

  • What's taking so long?? (a.k.a. Where is my software release?)

    I can't say I know the internal arguments against, so I'm just speculating here with my "distributor tech support" hat on. Just because a single tester found a issue in the lab doesn't necessarily mean that it is going to be a problem for most users in real-world shows. So it's helpful to know which issues people are actually running into, for prioritization. If someone runs into an issue and sees it in a list already, there isn't the incentive to report it to their distributor because "it's a known issue", so then the feedback is lost about who and how many are running into an issue and under what circumstances. Additionally, the process of reporting also enables the conversation about temporary / intermediate solutions (which the distributor might already have worked out) rather than the programmer having to try to piece it together on their own.


    There are potential solutions to that, of course. For example, a dedicated forum section for reports (both bugs and wishes) that allows voting or something, would be one approach.


    Again, I don't know for sure all the arguments, the above is just speculation. A dedicated forum or something like that would certainly make some things easier. But, again, speaking as a distributor, I think I would miss many of the connections and conversations with customers that arise while discussing the bugs and requests they report.

  • What's taking so long?? (a.k.a. Where is my software release?)

    The bugs that are reported during beta testing it seems to me generally have a higher priority for fixing than feature requests (because, again, the "Feature Development" portion of the cycle has passed). Off the top of my head, I would guess that the majority of user-reported bugs post-release were not previously known. Feature requests, maybe a little more likely.

  • What's taking so long?? (a.k.a. Where is my software release?)

    Well, as I said, the beta testers already provide more feedback than can be addressed in a single cycle anyway. :) And the more people that have access the more risk there is of it getting leaked. But all that being said, every so often the factory adds a couple beta testers to the pool. Your best bet would be to make sure your local distributor (Hi! 8o) knows that you're potentially interested, so that if and when the factory asks distributors for possible candidates yours is in their mind.

  • What's taking so long?? (a.k.a. Where is my software release?)

    <Full disclosure: I am not an employee of MA Lighting International or MA Lighting Technology. However, I am an employee of a distributor of MA Lighting products, and also a Beta Tester.>


    As a new version of grandMA3 software approaches and everyone gets antsy for its release, some common refrains I hear include the likes of "What's taking so long?", and "Is there a scheduled release date?", and "Can I see the release notes?", among others. And inevitably these choruses get louder in the echo chamber of social media. So I thought maybe a brief explainer of what goes into / leads up to a software release might be interesting for people to know.


    Without any further ado, here is a rough outline of the life cycle of a grandMA3 software release:


    Step 1: Feature Development Happens

    The amount of time spent at this step varies. Suffice it to say that a shorter amount of time here generally means fewer features are added, and the ones that are added are likely to be less "major". A longer amount of time means more work on bigger features (but of course a longer time between actual releases).


    Step 2: Beta Testing Happens

    "Feature Development" has finished. The software is shared with a pool of beta testers outside the factory to test the new features, their interaction with existing features, migrating show files forward, etc. More bug reports and feature requests are generated than there is time to fix or implement if the software is to be released in any reasonable amount of time! So of course prioritizing happens (crashes, freezes, and booby traps first, and so forth).


    Step 3: Getting Closer

    After the heavy beta testing period, there are a few weeks of bug-fixing as the highest-priority items are addressed, and more clean-up happens. At some point in this step, MA International gives a presentation to their Distributors showing what's new in the upcoming software. Distributors may also get a version of software and release notes to prepare their technical support and education teams (this version is not allowed to be shared of course).


    If a big trade show (e.g. ProLight&Sound, PLASA, LDI, etc.) happens to line up with this period, the current software will be shown on the booth. This serves dual purposes. One, of course, is to generate interest in the upcoming features. Another is to have an additional good period of people banging on the software who aren't already familiar with how everything new is supposed to work, which can reveal previously-unknown crashes, freezes, or booby traps.


    Step 4: Release Candidate (a.k.a. "We're juuust about there!")

    Step 4-A: The developers say "We think we're done," and send a version to MA International that could theoretically be released.

    Step 4-B: MA International (and the testers at the factory) do a little more last-minute testing to try and see if anything obvious was missed. Depending on the calendar, the trade show reveal may line up with this step instead.

    Step 4-C: Sometimes, a release-blocking issue is found, which goes back to the developers. Then loop back to Step 4-A. This looping may end up happening several times.


    The A→B→C→A loop in Step 4 is what really causes the antsy-ness I mentioned at the start (<Edit> and as I write this post this is where we are right now</Edit>). Everyone knows a software version is about to be released. And everyone pretty much knows the big features that are going to be in it. But MA International can't say for sure when it will happen, because they don't know how many times through the loop they will have to go before reaching a version they feel comfortable releasing.


    Now you might be asking, "Well why not at least publish the release notes while we're waiting?" And the answer is quite simple: Until the software is actually released, pretty much anything can be taken back out. If a last-minute issue with some feature is found whose fixing would take too long or have too many potential side effects, the feature might just be removed from this version and postponed until the next version (and yes, this has happened in the past, even within the last couple weeks before that software was released). If MA published "release notes" before the release, there's a good chance that the actual released version would not match the previously-published notes. Which then leads to complaints about the missing feature (not that there aren't complaints anyway :P). But worse, someone who read the initial notes might not re-read the actual notes, or might not catch the difference, and then in a show-critical moment could run into an issue because they try to do something based on their outdated information.


    Step 5: Release!

    The software is finally released! HUZZAH! Everyone is happy, and no one finds any new bugs that were missed. Shows use the new software, and much merriment is had.

    ...Meanwhile, back at the factory, the developers are already back at Step 1.



    So there you have it! That's a(n, okay, not so) brief outline of the process that leads up to a new software version getting released!