VisualK-OS (Control Console) [Prototype]

I had always thought of this as an open source project, despite the niche need it fills and the unlikely possibility that someone may seek to recreate parts of the rig, but now it is official; Supplying the command line argument ABOUT to the main "VKCC.py" script on launch will trigger a display of the GPL license and then exit. This was largely necessary to obtain a free license for WingIDE, which I've included a link to the company's web page in this project's external links. I could have kept using the free 101 version of the IDE, but free stuff rocks for us poor people that don't feel like dealing with hunting down a crack/serial/patch.

The first release of all of the Python source code to the VisualK-OS Control Center has been posted. I have also uploaded an initial documentation for the system, available in the files of this project.

I've realized some of the limitations that the current protocol imposes (parameter specification for more complex device control, among other things I can't think of at the moment), so some things needed to be addressed. Namely, keeping the constant values synchronized between the Arduino/Python sides of things was becoming tedious, so the serial comms approach needed reworking. I'm trying to break the dependency on strings (as it is expensive overhead on the Arduino side of things), so commands and parameters are now limited to one byte. Granted, this puts an arbitrary limit of 256 on the number and size of commands and any associated parameters. For now, I can deal with that... By the time that becomes a limitation, I imagine I will have thought of or been exposed to a new methodology to accomplish what is needed.

So, with this addition of the standardization of the headers/constants, I need only refine the serial implementation's use of delimited strings to a series of bytes and then I shall be ready to post the code. I hope it may be help to someone, but I doubt anyone will be replicating my work as such. Stay tuned! >: )

The Flood Bank Array (FBA) boards now have completed enclosures, have endured a bit of drop-shock testing and are fully debugged... Each board now works on all channels (R/G/B/W). The Control Console (CC) software has had some further debugging work, with the addition of the manual FBA control screen now fully functioning (which is how I tested/repaired the FBA boards just now, which is exactly what that screen is primarily intended for). Yay, progress!

I may upload a video of it working, but it's a set of RGB lamps on a board... What's to see? The guts are a bit hacky (due to some unforeseen PCB repair issues related to how the board was laid out), but they work, despite some of the seemingly-exploded TIP120 transistors that have leads attached and are glued down in no certain order looking like a weird dead-bug style of construction.

Now, to add in more commands and automation. The code was cleaned up on both the arduino and python sides, but I'd still like to implement a little bit more before I post any of it.

Greetings! First of all, I'd like to thank the ~25 followers this project now has. Usually people don't give two shits about the technical details of my electronics projects, as they just want to see footage of it working; I understand it's not everyone's thing (programming logic, circuit efficiency/design, etc), so for those that are actually interested in how this system is made/evolving, I sincerely thank you for giving a fuck and I genuinely look forward to any questions and/or constructive input you may have. I intend for there to be much more frequent updates, but we'll see if that actually happens or not.

First off, the versioning system used in the source code files (currently v3.5) are generally all from 3.0, onward. There are two reasons for this; I have been working on this project for a couple of years now, generally expanding and modifying it on an as-needed basis without any real documentation so-to-speak of the work. Resultantly, when I decided to standardize the code across all of the VKOS devices (both for efficiency and readability by someone other than myself), I began at a favored and reasonable major version of "3"... I'm also semi-irrationally fond of odd numbers. The individual module files are versioned from 1.0 on, though it is arbitrary as well since the split into different files occurred very recently and makes the progression through version numbers quicker than visually implied.

I hope my code and hardware documentation may be of some assistance to someone, someday, as the published work of other aspiring engineers has similarly helped me out in my work when I couldn't figure out how to do part-x. In retrospect, I now look at the circuitry of some of the devices and think of how I could have done it in a more efficient and aesthetically-pleasing manner (though I am a lover of all types of circuit porn), but it's not worth re-doing everything... This is not a commercial product, so what matters is that it works and isn't exhibiting any glaring ineffiencies.

[Source code overhaul]

The code has been successfully split into files relevant to each class, object and driver instead of the 800+ line python script that drove the control console and the few hundred lines of Arduino source that was hacked up to work with each device as needed. The code is now structured as follows:

"CS" = Curses screen (UI is in curses, mainly because I like the look)

\\ Visual K-OS Control Center

| - globals.py[All global constants/object definitions]

| - _screenCfgFBA.py[CS - FBA configuration]

| - _screenCfgMain.py[CS - Config. selection menu]

| - _screenCfgSS.py[CS - SynthStation configuration]

| - _screenCfgThor.py[CS - Thor configuration]

| - _screenClientScan.py [CS - Display status and/or scan for slave devices]

| - _screenDisplayMapping.py [CS - Display the current GamePad mapping profile]

| - _screenMain.py[CS - Main menu]

| - _screenManualFBA.py [CS - (limited) Keyboard-driven FBA control]

| - VKCC.py[Main script]

| - VKCC_Constants.py[Constants used everywhere: Serial, color, etc]

| - VKCC_objFBA.py[Flood Bank Array object definition]

| - VKCC_objGamePad.py[GamePad I/O driver]

| - VKCC_objScreenManager.py [Curses/console UI manager]

| - VKCC_objSerialManager.py [Serial I/O manager]

| - VKCC_objSynthStation.py [SynthStation object definition]

| - VKCC_objThor.py[Thor object definition]

[FBA Enclosures]

The FBA boards (2 total, currently) have finally gotten wood backings. One has had a full back piece for a while now, but the 2nd's circuitry has been exposed since its inception until last night. Now, to finish sanding down, leveling and re-painting. The good part about recycled palette wood is that it's free... The downside is that it is often semi-warped and/or irregular in dimension, which is why the enclosures have a bit of "character" that I'm attempting to minimize. They will eventually have hinging mechanisms so the boards can be angled and supported without needing to be propped up precariously on the stage.

Since the previous post, the first 2 flood boards have been built and used live at a concert (unexpectedly, but helpfully, allowing me to find where my protocol and approach has had some inherent weak points). To simplify, I shall just post an itemized list of the current state of things:

[VisualK-OS Control Center]
- Remodeled interior now uses a side-mounted AC port instead of a hardwired cord for the main power input to the system.
- Flood Bank Array controller/driver is mounted on top of its' PSU with a DB25 connection used to send the SPI control signals to the 2 shift registers in each flood bank board.

[Flood Bank Array (FBA)]
- Arduino driver sits inside control center, connecting to a small 3D-printed breakout box (carrying 5v+/12v+/SPI/GND signals) that currently has two RJ45 connections. Each RJ45 port sends 5v+/12v+/SPI/GND to each flood board with 3 pins allocated for current (GND) due to the relatively high amount of ~198 RGB strip segments per flood board. All transistors, resistors, capacitors and shift registers are located on a PCB mounted inside the flood board, to save from having to cram all the wiring into the already-crowded control center and run one cable to the stage to control both boards.

- Connected by RJ45, each board contains 4 RGB lamps and one board-wide set of white LED strips (5 addressable lamps total). The 2nd 74HC595 register's serial out pin is connected to one of the RJ45 pins to send the data back up the line and into the next port on the breakout module. Basically, the boards are one chain of multiple 74HC595s (as far as the Arduino is concerned).

New photos of the PCB fabrication for the newest and coolest module (Thor) have been posted, component list has been updated and the general info has been better articulated... It's still a whole bunch of words to me, but at least it's much more accurate, now. haha

After some compromising due to budget (I suppose this plagues a lot of us DIY folks, at times), the flood panels have been put on hold. However, this resulted in forcing me to re-think how I was approaching this project and relatively simplify the mechanics of it a bit more, ideally reducing future headaches. The Synth-Station, previously running off the RPi/Arduino duo, now uses only the Arduino and simply listens for commands over serial. The Synth-Station will later be able to be controlled from the main system, for off-stage management and to allow the synth player to focus on what they're playing, rather than selecting the proper lighting routine for x-song). So now, said Arduino is commanded by a Python script that sniffs the messages coming from the MIDI controller (being used by FL Studio for live synth generation) and reacts accordingly as the script determines if each note is to trigger a light or sequence.

Once I had colored the "Back-Bone" channel LED strips black (Yay for Sharpie ghetto-art!), I then changed the shelves' connector out from tedious terminal blocks to relatively convenient D-SUB 9 connectors for improved modular functionality and connection flexibility/stability. Yea, having to unscrew 4 terminal blocks from each shelf just to allow the shelves to be removed for easier storage and transport was quite cumbersome, time-consuming and annoying. For the needs of this component, terminal blocks were clearly not the great idea I thought they were. However, D-SUB casings filled with hot glue have proven to be much more reliable for making a secure and easily-removable connection.

Now, with the guts all nicely glued (at least as well as they can be) into the container, this component only needs some more automation routine programming and it will be the first finished piece of this new system... Yay!