<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>pyware &#8211; MENDEL LEE</title>
	<atom:link href="https://mendellee.com/tags/pyware/feed/" rel="self" type="application/rss+xml" />
	<link>https://mendellee.com</link>
	<description>composer • performer • educator • entrepreneur</description>
	<lastBuildDate>Thu, 07 Feb 2019 22:00:38 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>

<image>
	<url>https://mendellee.com/mendelblog/wp-content/uploads/2022/03/cropped-MCreates512-32x32.png</url>
	<title>pyware &#8211; MENDEL LEE</title>
	<link>https://mendellee.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>The fundamental flaw in Pyware</title>
		<link>https://mendellee.com/2011/06/20/the-fundamental-flaw-in-pyware/</link>
					<comments>https://mendellee.com/2011/06/20/the-fundamental-flaw-in-pyware/#comments</comments>
		
		<dc:creator><![CDATA[Mendel Lee]]></dc:creator>
		<pubDate>Tue, 21 Jun 2011 03:29:52 +0000</pubDate>
				<category><![CDATA[blogposts]]></category>
		<category><![CDATA[pyware]]></category>
		<category><![CDATA[technology]]></category>
		<guid isPermaLink="false">http://www.darknote.org/?p=508</guid>

					<description><![CDATA[so after working with and getting to actually know the fundamental workings of pyware more intimately, i&#8217;m finding myself annoyed at the fact that transitions are not independent elements between &#8230; <p class="link-more"><a href="https://mendellee.com/2011/06/20/the-fundamental-flaw-in-pyware/" class="more-link">Read more<span class="screen-reader-text"> "The fundamental flaw in Pyware"</span></a></p>]]></description>
										<content:encoded><![CDATA[<p>so after working with and getting to actually know the fundamental workings of pyware more intimately, i&#8217;m finding myself annoyed at the fact that transitions are not independent elements between endpoints.</p>
<p>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 &#8220;inked&#8221;, 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 &#8220;transitions.&#8221;  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, &#038;c.  But where this gets fussy is when any drill needs to be rewritten because there&#8217;s no way to delete a transition without deleting an endpoint.</p>
<p><span id="more-508"></span>For instance, John originally moves from point B to C in 16 counts.  Let&#8217;s call the transition move BC and call each &#8220;count&#8221; the transition name+number, as in BC1, BC2, BC3, &#038;c.  animated, then, it looks like:</p>
<p>B, BC1, BC2, BC3,&#8230; BC15, BC16, C.</p>
<p>For whatever reason, i decide that i need to change John&#8217;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&#8217;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:</p>
<p>B, BC1, BC2, BC3,&#8230; BC15, BC16, D.</p>
<p>So why is this a big deal when all i have to remember is to delete point C first?  Because let&#8217;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 &#8211; 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 &#8220;accept&#8221; into a 5-minute process of deleting the original S-curve and rebuilding it.</p>
<p>This is made even more complicated if I want to shift point B instead.  Let&#8217;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 &#8211; 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&#8217;s &#8220;backwards drill&#8221; writing feature to delete the transition backwards &#8211; 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.</p>
<p>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 &#8220;recalculate&#8221;.  It wouldn&#8217;t be that hard to reprogram, developers, and you&#8217;d save drill-writers across the nation (all 50 of us) a lot of hours.</p>
<p>Of course, i&#8217;ve only been using the program intensely for about three days, so maybe that functionality already exists and i just don&#8217;t know where it is.  Someone please tell me that this is the case.  Pretty please.</p>
]]></content:encoded>
					
					<wfw:commentRss>https://mendellee.com/2011/06/20/the-fundamental-flaw-in-pyware/feed/</wfw:commentRss>
			<slash:comments>3</slash:comments>
		
		
			</item>
	</channel>
</rss>
