Question ref. track start points

Here's my very long n00b answer.   The table uses math (obviously) to do its work, and there are two useful numbers to know.  0 is the center of the table.  1 is the edge.  If you're one of those people who hates math I promise it won't get scarier-- those are the only two numbers you will need for this.  

All tracks start at either 0 or 1 and end at 0 or 1.  You can have any combination of those-- a track that starts and ends at the edge (11), starts at the edge and goes to the center (10), etc.

Some tracks are reversible.   The erase track is one of those, and it's super simple.  It has two lines that read like this, in non-math terms:

- Start in the center
- Go to the edge, but take the long way around

Because it's reversible when you play the erase track the first thing the table does is check to see where the ball is.  If the ball is in the center it plays it normally.  If it's at the edge it plays it backwards-- start at the edge, go to the center but take the long way around.  If erase wasn't reversible and you tried to play it when the ball was at the edge the table would zoom the ball into the center and then play the erase out to the edge.

Those are the key concepts.  Still with me?

How do you know where a track starts and ends?  The only way I know of to do it is to create a playlist and start adding tracks.  When you do that you'll see that the tracks are labeled something like "Rho Start/End: 01".  That means... well, you know what it means now.  How do you see if a track is reversible?  The best way I know of to do it is to click on it and see if the "Reversible" box is checked. 

I like to live-DJ my table rather than creating playlists so I would love it if tracks were labeled with their 01R status everywhere.  (My recent feature request.) 

As for the two specific tracks you mention:

trialdn1: 01, reversible
tensig2$: 01, reversible

That means that if you run triald over tensig2 one of two things could happen:

#1: The ball started at the edge.  You played tensig2 from the outside in, then trialdn1 from the inside out
#2: The ball started at the center.  You played tensig2 from the inside out and then trialdn1 from the outside in.

I hope that all made sense!

My question is not about the distance from rho=0, but about the initial position on the circle defined by rho=1 when a track begins there. I appreciate your effort, though. 

Ah!  I think the "Force Orientation" checkbox is what you want.  It should make it predictable.  Check this out:  https://sisyphus-industries.com/community/app-updates/delete-track-capability/#post-1541

No, the question concerns the relationship between the end point of a track that ends at rho=1 and the start point of the next track in a playlist. I want to know what (if anything) determines the start point of track 2 on the circle described by rho=1.

OK - there's a bit more to the story. Patti did a great job of explaining the Rho part. What's Rho? It's the name of the linear axis (which moves the ball out from the center (Rho=0) to the edge (Rho=1). But Sisyphus is a 2D plotter. The other axis is called Theta - and it moves the ball around the center. It's the start and end Theta that @adambrower is asking about. Most people are familiar with 2D Cartesian geometry, where the two axes are called "X" (horizontal) and "Y" (vertical) - the classic example is an Etch-a-Sketch. But Sisyphus uses polar geometry (hence the different axis names). Like the X and Y of the Etch-a-Sketch, the Rho axis has limits - if you go too far in either direction you hit the "end of the track." If this happens with your Sisyphus, it makes a knocking noise, which doesn't hurt the mechanism, but is no fun to listen to.  Our software is designed so that this should never happen - the ball must always stay between Rho = 0 to 1. Theta, however, has no physical limit! The ball can go around forever without running into anything. When I created the first polar Sisyphus (over 20 years ago) I was only making algorithmic tracks (geometric / mathematical), and wasn't concerned about which direction the track faced on the table (Theta). So the answer to your question: the default start of the next track is the end point (both Rho and Theta) of the the finish of the prior track. Not only is this "seamless" (no extra "connector line"), but it leads to random overlaps between tracks in a playlist when played in "shuffle" mode (which I like!).

But if one wants to control track orientation (say, a company logo that you want to be drawn with "up" always in the same position, regardless of what track came before), that is where  "Force orientation" is enabled.

On re-thinking your question, I see fully answering your question is even a bit more complicated. Are you putting those two tracks in a playlist, and playing it sequentially (not shuffled)? If so, you should see the same overlap ever time. How exactly are you playing those two tracks? When you click on each of the tracks - what are their settings with respect to reversible and force orientation?

An easy way to force this would be to create a track called something like "Top" that just read "0 1" and was set to force orientation, yes?   Assuming two tracks back-to-back that were both 11 a sequence of Top, Track1, Top, Track2 should always produce predictable results, yes?

Thanks for looking into this, @Bruce.

The playlist has the following (2-ball mode), run sequentially (not shuffled):
:
Attach
spmrph1r (0/1)
tensig2$ (1/0 - reversed)
trialdn1 (0/1)

All are set "reversible." All are set to "force orientation." When I run the playlist, spmrph1r runs as expected. I can see the main ball in tensig2$ moving to the proper Theta in accordance with "force orientation," as expected, and tensig2$ runs reversed.

Unfortunately, though, at the transition between tensig2$ and trialdn1, sisbot inserts ye olde looping connection line—and then runs trialdn1 in reverse!

So something is not functioning as expected.

Thanks for the detailed info. Sending Matt (our lead dev) a heads up and see if he can identify the cause...

This is the kind of thing I want to recreate intentionally. When one of these is formed, I pause the process, and sometimes leave the table in that state for quite a while.

I think I've found the issue. Rounding (or lack thereof) error on track loading. Fix in upcoming update.

Update 1.10.86 is out, and addresses this issue.