XK-System (community project) > Hardware Development

Computer architecture design

(1/2) > >>

Artur D'Assumpção:
Hi guys,

I'm now opening the discussion for the architecture design of the SSLMixed Computer. I'd like you guys to discuss this matter taking into count several view aspects such as: electronic design/software design pros and cons, costs, supported features, supported workflows, etc. In the end the idea is to come up with an architecture that most complements our needs and facilitates our mission.
 
I haven't opened this discussion earlier because I wanted to have the requisites threads open first and rolling. This allows for a more enriched discussed since we are already on the process of defining what we want and what we don't.

Happy discussions!

Cheers,

Artur

Artur D'Assumpção:
Hi,

I've been thinking about the architecture issue through the last couple of days and based on the prerequisites we've been discussing I've come up with 3 difference architectures designs (and 1 variant design) to kick start the discussion.

I'll just ask you to ignore the details part of it since there's much that's not yet looked at. Look at it as a macro architecture idea.

Bellow I explain each one of the designs:

- Architecture #1:


This architecture as the following features:

- There's a modular an scallable I/O component that connects the SSL to a Computer;
- Modules and Computer are together in the same box and use some kind of bus (GPIO for instance)
- A microcontroler can manage this if bus (depending on the electrical design)

-The computer only offers the core routines to access the console functions:
   - VCA read/write
   - Led control
   - Total recall read
   - Mode read/write 
- These routines are then exported to the network through an TCP/IP application protocol via the Ethernet port.
- There's a remote computer (example: laptop/desktop that can be the same as you run PT) that hosts a master client application that handles all the high-level and stuff:
      - GUI environment to the SSLMixed computer
      - global configuration
      - calibration features
      - snapshoting (total recall)
      - automation:
               - automation be autonomous or synced via MTC, DAW, etc.
      - etc.

- You can connect to other client controllers (for instance, ipad) or support remote displays to display mixed info, such as automation moves.
 
Pros & Cons (comparing with the previous architecture):

- Computer more simple and less heavy computing.
- we have to develop our own bus between the I/O cards and GPIO on the core computer
- The computer core doesn't need any time reference, just follows the master remote application lead and reacts promptly.
       - The remote application keeps with time (via DAW, MTC, SMPTE, etc.)
       - The support for SMPTE has to be provided by the master remote application computer;          
- You can't work with the computer in an autonomous manner, you'll always need to run the master remote application if you want to support automation and features such as snapshot management.

- Architecture #2:


In this architecture we pushed the "master remote computer" into the core computer. This way we'll have a much more closed and autonomous solution.

The differences from the previous architecture are:

- The computer now offers the core routines to access the console functions and full blow GUI environment to deal with every aspect of the console and applications.
- You can connect a screen, mouse and keyboard and interact directly with it. You can have this integrated on your console.
- It still exports core routines to the network and lets you hook remote clients, such as controllers e displays.

Pros & Cons (comparing with the next architectures):

- Computer more complex and heavy computing due to the GUI.
         - you can now interact directly with the computer with it's own environment (keyboard, mouse, display)
- we still have to develop our own bus between the I/O cards and GPIO on the core computer
- The computer now needs time reference since he's now in charge with time sync/generation. We have to develop the MTC/SMPTE/etc interface.
                - We still can chain time to a master DAW.        
- You can work with the computer in an autonomous manner, so you can mix and have all features without needing to have second computer
- You still can use remote clients for control and display.

- Architecture #3:


In this architecture we've spitted the module I/O with the computer and hooked it through USB bus.

The differences from the previous architecture are:

- You now have your main computer (core+gui) on a separated box. The modules and the computer are interconnected via USB bus.
- This simplifies the development of our own bus.

Pros & Cons (comparing with the previous architecture):

- You don't have to develop your own bus between the I/O cards and GPIO on the core computer
    - easy to develop software
- You can't work with the computer in an autonomous manner, you'll always need to have to power on the second box or your PC if you have it hosted in your computer.
- You can run it on a standard PC (this can be good or bad depending on the view)
- You still can use remote clients for control and display.


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

There are more into these architectures but I think those are the relevant aspects of them.

I personally think the 2nd architecture is a good compromise between the three. It can cope with more workflows without compromising the autonomous system side of it. Analyzing the three architectures I can still come up with a 4th one, which is combining the 2nd and 3rd, replacing the inner BUS with a USB bus to communicate between the modules and the computer, all in one box. It's an idea, I don't know now what is the most advantageous in terms of performance and level of complexity.

Comments and suggestions are welcome!

Cheers,

Artur


Matt Sartori:
Absolutely fantastic work Artur!
my opinion:

-the computer should be stand alone so people can run it with or without protools or with a tape machine with SMPTE if they wish so
-also if possible it should be possible to draw automations from protools (or logic for that matter) directly from the DAW into the SSLMIXED computer

Mattia.

Artur D'Assumpção:

--- Quote from: Mattia Sartori on November 09, 2013, 07:30:54 PM ---Absolutely fantastic work Artur!
my opinion:

-the computer should be stand alone so people can run it with or without protools or with a tape machine with SMPTE if they wish so
-also if possible it should be possible to draw automations from protools (or logic for that matter) directly from the DAW into the SSLMIXED computer

Mattia.

--- End quote ---

Added this to the prerequisites thread! ;)

pascal.verdet:

--- Quote from: Mattia Sartori on November 09, 2013, 07:30:54 PM ---Absolutely fantastic work Artur!
my opinion:

-the computer should be stand alone so people can run it with or without protools or with a tape machine with SMPTE if they wish so
-also if possible it should be possible to draw automations from protools (or logic for that matter) directly from the DAW into the SSLMIXED computer

Mattia.

--- End quote ---

Hello Artur,
I agree too.
There is possible to have your architecture design in pdf format ? It's more readable than an screen
Thanks
Cheers,
Pascal

Navigation

[0] Message Index

[#] Next page

Go to full version