Author Topic: Project Status Update 24-02-2015  (Read 3415 times)

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 661
  • Karma: +23/-0
  • Sintra, Portugal
Project Status Update 24-02-2015
« on: February 24, 2015, 01:46:16 PM »
Hi guys,

We're doing the last double-check verifications and refinements on the Ultimation I/O cards design and everything should be ready until next weekend. We are also waiting for the Chinese year festivities to end so we can start printing our prototype PCBs (these guys don't work for an entire 15 days).

The first ones coming out will be the Ultimation I/O cards and a preliminary debug Motherboard (for internal use). This will allow us to validate our designs and make any corrections without too much commitment. We already have the VCA I/O cards designed but these will only be printed after the Ultimation I/O card's has been fully validated on the test bench. This will help us detect any problems early in the process and have the corrections merged back into the VCA I/O card design. Think the Ultimation I/O card as a smaller brother of the VCA I/O card, since the latter is a bit more complex and have more components to it.

----------------

Too continue discussing the entire solution...

You should face our solution as a system than involves several nodes (CPUs/Micro Controllers) to fulfill a goal in a very efficient and versatile way, and not a solo computer as it was designed on the legacy computer.  On the legacy computer you have one big monolithic computer that handles everything. On our solution we have smaller independent pieces (nodes) that come together through the Network, and that's why we call it a system, rather than a computer.

What components do our system has (so far):

I/O Rack:

These are the devices that interface with the console and the Manager. Any input/output with the console goes through these I/O Racks, being either fader related data, total recall data, keyboard data, transport data, etc. These will also assure resilience of the console in case of failure of the system, giving you hardware/software bypass capabilities without the need of any re-cabling in the process (there are some limitations with Ultimation systems that I'll discuss later).

As explained on the last update, you can have up to 2 x I/O Racks installed (each one is 2U size), and each one scales to your needs, by fitting as much I/O cards as you need and each I/O Rack can handle (max 8 cards). If you have a 2 rack system, the channel I/O is spread among the 2 racks, but the TR, Keyboard and Transport, will be handled only by the main system. The secondary will only handle channel related I/O.

These racks are connected with each other by a backlink (RS 232 cable). The main rack will be the master and handle the communication with the Manager through standard IP Network. - You can use your already existent IP Network to connect the entire system.

It's important to mention that the Main and Secondary rack are similar in terms of electronics. The only difference between them, is that the secondary rack's motherboard won't have populated all the electronics related with TR, Keyboard and Transport, and also won't have the small controller computer fitted in. All the rest is exactly the same. This way we can reduce costs by using the same PCBs for both racks.

Manager:

The manager is a piece of software that runs in any computer and is the brains for the entire system. This software will control and manage everything related with the I/O Racks and also synchronize the entire system with the outside world, such as your DAW. At this stage, outside sync will be possible for Time Code/SMPTE (for automation) and Transport Control through the DAW and vice-versa.

The Manager will be your portal to the entire system, and it's where your workflow will staged. This is a window based application (with more stuff behind the hood) where you'll be able to do tasks such as: system configuration, manage sessions, manage automation, manage total recall, and have all the necessary calibration and debug facilities. Now, this is all done through a modern window-based/point-and-click fashion application.

But you should be asking, what does that have to do with the legacy workflow? Nothing you're correct... This is only to help you interact easily with the system and do the more complex tasks in an easy and intuitive way. Which brings me to the next topic...

We love the SSL workflow, it's a winner workflow that has been designed and proved on the field during the last 25 years. We believe this is something we need to retain, although not fully (explained after). Its magic lies with the actual session interface, where its modes are extremely intuitive, the keyboard shortcuts you can drive with a blindfold and the automation writing and management is a breeze to handle. Once you got the hang of it, you easily take your brain and eyes off it, allowing you to focus completely on the sound and the creative process. This is what the SSL workflow offered you, once in session and once acquainted with it, you can drive it intuitively and focus on the task, not the tool.

For this we decided not to reinvent the wheel, adding you the same interface that you're used to, taking out the unnecessary complex parts and adding the modern touch and robustness it desperately needs. For this we designed a kind "virtual console" that's fired through the manager and allows you to enter in the SSL workflow mode (it runs in parallel with the Manager window application). Your console's keyboard will interact with the system inside this virtual console and allow you to input and interface with the same commands you are used to (unnecessary ones will not be support of course - no one handles with floppies anymore! ;)), retaining the same workflow as much as we can and as much as it makes sense. - We might add also some extras in there, to give it even more options that are clearly missing from the legacy system. 

This will allow you to take your hands and eyes from the Manager while you're in your in the zone (creative process). You'll be interacting only with the console, exactly like you did so far. When you need to make more complex/management related stuff then you can turn into the manager and do it in a more intuitive and faster way. We believe this is the best way to do it, by marriage the best both worlds have to offer.

To boost even further this workflow we will enable you to have as many monitors/TVs as you want in the Studio, and display whatever info you want in each of them. How? Wait for the future updates! ;)

We will support both small and large SSL keyboards. If you don't have any keyboard, no problem! We will be exporting the shortcuts to a standard PC keyboard, so you can mimic the same legacy interaction with the system. This way you can be inputting commands with the legacy keyboard and the PC keyboard.

Now that you understand how the Manager works, I can explain and justify the following decisions.

Although initially we thought we would develop this manager so you could run anywhere you want, specially your DAW computer, we soon realized this would be stupid and not very agile way to do it. This is because we want to give the PC keyboard total focus over the Manager application, and if you're running at the same time your DAW, you want this to be focused on the DAW. One application will monopolize keyboard focus over the other. This would give a very uncomfortable interface, switch you needed to be constantly switching from one application to the other.

For this reason we decided one will need a dedicated computer to run the Manager. Thankfully the Manager have very low resource needs and will be developed to run exclusively in Linux. This way you can have a small-form x86 computer to handle everything. We will be choosing one off-the-shelf small-form and very cheap computer and go from there.

More updated soon! Fire your questions if you have them!

Cheers,

Artur
« Last Edit: February 24, 2015, 01:55:32 PM by Artur D'Assumpção »

StarF666

  • Jr. Member
  • **
  • Posts: 80
  • Karma: +1/-0
    • Berlin, Germany
Re: Project Status Update 24-02-2015
« Reply #1 on: February 25, 2015, 01:04:56 PM »
I am new to this forum, so hello everybody.

First let me thank you for your outstanding work and commitment. It's great to see so many SSL dedicated people.
I'm currently trying to find a 4048 for our studio and I'm looking forward to your computer replacement.

Might I ask a question: I like the idea of having a compact dedicated machine for the master system. But as your going with Linux and a network interface, would you really need a x86 computer? Would a Raspberry pi have enough power for the software? This would be a really small package and you could get something like a standardized hardware platform.
May I ask, which protocol the software uses to communicate with the master system?

Anyway, thanks to everybody for your effort working on this project.

Martin

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 661
  • Karma: +23/-0
  • Sintra, Portugal
Re: Project Status Update 24-02-2015
« Reply #2 on: February 25, 2015, 02:36:30 PM »
Hi Martin and welcome to the family! ;)

Thank you for your comments.

Actually when I said x86, I was just trying to generalize. But I believe that there will be no problem in compiling the software to run in ARM architecture, enabling you to use a Rasberry Pi or a BeagleBone black. Actually the main rack uses a BeagleBone Black has the CPU that interfaces with the network and the local micro controllers. We are also using the Rasberry Pi for other system nodes which I haven't revealed yet, but which will be awesome! :D

The only thing you have to be careful is that the Manager will run on a lightweight Linux Desktop Manager. We are currently testing LUbuntu and XUbuntu and go from there.  So the choice of hardware platform should have enough capacity to handle the Desktop plus the manager itself. You'll need also at least 3 USB ports, or 1 USB port attached to a USB hub. This will allow you to have a keyboard, mouse and connect an out-of-the-shelf cheap USB MIDI interface compatible with Linux (we are still evaluating which ones will be the best).

The USB MIDI interface will allow you to run SMPTE TC, for automation synchronization, and MTC for Transport link with the DAW. We are also studying the possibility of using MIDI over Ethernet as an alternative to the USB MIDI Interface, but to be honest I haven't yet dived yet into this issue to have an verdict.

We are using several protocols for achieving different goals, but all are on top of TCP/IP. Some of them are well known protocols such has HTTP (for web based configuration of the system node), others are developed specifically for asyncronous/syncronous communication, with performance in mind.

I hope I was able to reply your questions.

Cheers,

Artur

« Last Edit: February 25, 2015, 07:43:29 PM by Artur D'Assumpção »

StarF666

  • Jr. Member
  • **
  • Posts: 80
  • Karma: +1/-0
    • Berlin, Germany
Re: Project Status Update 24-02-2015
« Reply #3 on: February 26, 2015, 01:03:29 PM »
Wow, thanks for the in-depth information. I have a MA in computer science so these things are pretty interesting for me. Great stuff so far.
I hope our desk will be here within two weeks. I then have to dive into its electronics. Looking forward to the new computer. Exciting times.

Keep up the good work.

Martin