The fundamental flaw in Pyware

so after working with and getting to actually know the fundamental workings of pyware more intimately, i’m finding myself annoyed at the fact that transitions are not independent elements between endpoints.

as in, say i create a 16 count move and in that move i have John go from point B to point C. Once that move is “inked”, Pyware does a calculation of where John is supposed to be after every count and writes each individual count accordingly for the purpose of animating the drill. Those in between counts are called “transitions.” The transition thing is nice; sure you could create it as just a vector calculation from point B to C instead of writing each individual count, but there are perks to doing it this way particularly when it comes to calculation or modification of important design data such as step size, pathways, subsets, &c. But where this gets fussy is when any drill needs to be rewritten because there’s no way to delete a transition without deleting an endpoint.

For instance, John originally moves from point B to C in 16 counts. Let’s call the transition move BC and call each “count” the transition name+number, as in BC1, BC2, BC3, &c. animated, then, it looks like:

B, BC1, BC2, BC3,… BC15, BC16, C.

For whatever reason, i decide that i need to change John’s final destination point from point C to point D instead. Since point B to C was already established, transition BC is already inked. In order to delete the transition, i have to first delete point C before rewriting it to point D or else i’ll have point B to point D with a BC transition written into it instead of pyware adjusting behind the scenes to rewrite the transition to BD. Animated, it will end up looking like:

B, BC1, BC2, BC3,… BC15, BC16, D.

So why is this a big deal when all i have to remember is to delete point C first? Because let’s expand this example from just John to 50 people. 50 people are marked at point B in a big straight line and their point C is a big S-curve about ten yards away. Now i want to make that S-curve 20 yards away (point D) instead to create more movement and give the color guard more visual breathing room. If i grab the S-curve and just shift it to point D, the end point will look fine, but will have the BC transition problem noted above. If i want to ensure that a transition BD will be built, i need to first delete that transition – and the only way to delete the transition is to delete the point C S-curve first. Which means that i have to rebuild the S-curve and reassign all 50 members individually to where they belong on the resultant D S-curve if i want to ensure that the transition is correct, which moves a 5-second process of just dragging the S-curve 10 yards away and saying “accept” into a 5-minute process of deleting the original S-curve and rebuilding it.

This is made even more complicated if I want to shift point B instead. Let’s say that instead of moving the point C S-curve 10 yards away, i want to move the initial point B straight line 10 yards away instead to point A. Now i have a move from A to C that has associated with it the BC transition – and the only way to delete that transition is to either delete point C and rebuild it even though nothing about point C has actually changed, or use pyware’s “backwards drill” writing feature to delete the transition backwards – which sounds fine, but what if that new point B is in the *middle* of already written drill and has a point Z that it moves from? Now if i want the be able to create a new ZA transition and a new AC transition, i need to set pyware to backwards, delete point B and redo it to point A, then set pyware to forwards, delete the new point A i just created and REDO IT AGAIN.

What i wish would happen instead is for Pyware to assume that it needs to rewrite all of the transitions around a modified spot unless somehow that transition has been manually manipulated for pathways in which it gives you a warning or an option. At the very least i wish it had a mechanism where i can choose a transition independent of the endpoints and say “recalculate”. It wouldn’t be that hard to reprogram, developers, and you’d save drill-writers across the nation (all 50 of us) a lot of hours.

Of course, i’ve only been using the program intensely for about three days, so maybe that functionality already exists and i just don’t know where it is. Someone please tell me that this is the case. Pretty please.

3 Comments

  1. Chris PutnaM

    Use Copy/paste. Change C to D and then select the group that is in a new spot. Copy it and then pasteit right to where they are. It will ask you to rematch the members and then it will re-do their transition counts correctly.

    It would be nice if there was a better way to do it, but that work around has been a life saver for me over the years…

  2. Grant Maledy

    I found this in the Pyware forums:

    “Go to the page(s) you rewrote and select the performers you edited. Click/select the Morph Tool and simply hit “Accept” without selecting/deselecting the boxes or adjusting anything. This will fix the animation between the pages. You will have to do that for any spots that were edited, including going from the last edited page to the next unedited page, if that is necessary.

    I believe there are other methods and new tools that have recently been implemented into the program, but that’s just the way I do it since I haven’t had a chance to learn any other way just yet. This way may seem a bit odd but it works.

    The only time this doesn’t work is if you have any tracking or follow-the-leader moves that were edited and need the animation to be fixed. In those instances, you would likely have to rewrite the move for those performers rather than just editing the dots/forms individually. I don’t know if that makes sense, but if you have a FTL or track in the show and you edit those performers, do not use the Morph Tool technique I just mentioned. I think it would need to be rewritten… or possibly not touched at all since it may work just fine after the edit – but I could me wrong. I’ve never done that before. ”

    Also, hey Chris!

Leave a Reply to Grant Maledy Cancel

Your email address will not be published. Required fields are marked *