I really wanted to use DMXControl 3.3.0. And in hindsight, probably would have been able to, and probably should have.
But, Here is why I decided not to:
Before I found the Chromateq Software for the simulation modeling, I was playing with both DMXControl v3.2.3 and v3.3.0 to see what major stability changes there were.
My main test in both versions was to load in as many "Generic RGB" devices as I could to see how it would handle running hundreds of simple devices simultaneously.
I also wanted to test the efficiency of the way DMXControl handled Matrixes.
So in both versions, I began by initially loading 500 "Generic RGB" devices. This was the maximum amount that the application would let me add at one time.
If I wanted to say add another 500, I would simply have to initiate another instance of importing the fixtures.
This was my immediate result which I will attempt to explain as best I can.
First, in 3.2.3, I found that loading that many devices at once took a crazy long time for the application to load in the fixtures, with one exception.
When I began adding devices, I was adding them primarily by going into the "Devices Window" -> Right Clicking -> Add Device inside of the "Devices Window".
With the device window still open, it took probably about 5+ full minutes of waiting for DMXControl 3.2.3 to add all the devices at once if I was lucky. DMXControl 3.2.3 would be locked until all the devices were finished importing into the project. I believe sometime this would also crash the application.
I then discovered that if you do not have the "Devices" window open (rather keeping say the "Cuelists" window in focus), and instead add the fixtures using the "Add Device Button" 
at the top of the main Project Explorer window, adding the same amount of devices produced a progress bar, and resulted in a significantly less time (less than 30 seconds) to add the fixtures to the project.
I also discovered, that in the stage view, when viewing the graphical display, the visualization was very very choppy with that many fixtures added to a stage view window. (I believe it was after about 150-200 fixtures is when the results became choppy) and eventually you could not really tell what was accurately going on with chasing sequences.
I attempted the same test in 3.3.0:
Adding the fixtures with either "Right Click" -> "Add Device" in the "Devices Window", or, clicking the "Add Device" button at the top of the Project Explorer was a significant improvement, almost instantaneous add, and also resulted in slightly better performance in the Stage View, but here was the problem:
When trying to use Fan or Matrix Sorting in stage view (Hold M and then Drag Selected Fixtures), all of the fixtures in the Stage View would randomly scatter all over the place, and you could not organize the fixtures in the slightest way.
I was able to kind of get around that problem by creating a matrix and then making the Stage View Matix icon the same proportions as the full amount of RGB Fixtures, and then removing the individual RGB Fixtures from the stage view, but then this occured:
When selecting the "Bitmap" Matrix effect, no matter what type or size of image used, the only thing that would display was a default DMXControl Projects Logo across the lights in the Matrix.
It actually took quite a while to realize what the heck was displaying on all the lights at that point hahahaha.
So right off the bat, even though I did not end up using the Matrix feature at all in this particular demonstration, without doing too much more testing, I deemed that 3.2.3 was going to be ultimately more stable to program in than the release of 3.3.0, and decided to run with that.
In the future, I would probably use the Matrix Feature to program larger amounts of Static RGB washes and things like that.
I also would have liked to utilize the new version of the Executer, and discover what other improvements there were, but I didn't know when my sanity was going to break xD (Spoiler: It broke anyway 
)
So that is why initially I did not decide to use v3.3.0.
As for the Timecode Player, it's not that I didn't want to use it in DMXControl. It's just that in Studio One, I am able to both edit the musical timeline, add different audio layers and effects, and change them in real-time and as needed within the project, in addition to sending MIDI output (adjusting audio levels, time between songs, etc...).
I guess technically the new Timecode Player in DMXControl would eliminate an extra step of assigning individual MIDI rules in the MIDI manager and Input Assignment, but overall, using Studio One as a Timecode Trigger was just the most efficient way of dealing with this particular type of project.
Plus, I have been using it this way for many years, and am just used to using it as a master timeline trigger system at this point.
Plus, If I wanted, I could also use additional MIDI channels to trigger external video sequences in VJ applications and such, so it is a really intuitive way of using a master application to trigger all sorts of different show commands across different applications and platforms.
Also, triggering MIDI in this way falls in line with how I would program a 'Light Board' using TouchOSC and BOME MIDI, so it really leaves all possibilities open.
There is actually a situation I will probably make a seperate post on at a differt time regarding how Input Assignment treat MIDI Fader Data.
Briefly, I realized it might be possible to use a MIDI Fader rule (as opposed to a MIDI Button) in large cuelists containing things like color cues. Say you have 20 Colors in a color Cuelist, and you want to use "GoTo" to call a specific color cue. Rather than making 20 MIDI buttons and wasting 20 values (notes) in a single MIDI channel, you could in theory use a single MIDI note, and treat it as a fader, using each fader step as a "GoTo" recall number.
The problem is that Input Assignment creates a really complicated floating decimal number on the output, and I have not been able to find a way to "Round" the number with any functions available in the Input Assignment Logic. This results in skipped steps when trying to assign that floating number to a whole number that can easily be used as a "GoTo" step.
Perhaps you know of a method to round floating numbers in Input Assignment.
That one simple feature would allow much more efficient Input Assignment rulesets. I think I am simply overlooking something.
Also, I wonder if there is any documentation on what each Logic Feature of the input assignment does, as there are some I simply just cannot begin to understand what they do. Such as "Rule of Three" and "Smittrigger" along with a handful of others. I have searched the Wiki and Forum, but I think I have been looking in the wrong places.
As for the amount of Cuelists, I have attached images of the full Cuelist tree in the following replys. I will let you enjoy viewing the surface of this list haha.
It seems the number is 154 cues total used in this demo.
The attached Cuelist images will show how many cues are in each Cuelist down the line.
I must add those images in 2 more posts given the image limitation of a single reply (not Spamming)
</Ramble> 
(much like myself haha).
