Author Topic: Computer architecture design  (Read 1520 times)

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Computer architecture design
« on: November 09, 2013, 01:59:34 PM »
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

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Re: Computer architecture design
« Reply #1 on: November 09, 2013, 02:55:00 PM »
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


« Last Edit: November 09, 2013, 03:03:30 PM by Artur D'Assumpção »

Matt Sartori

  • Administrator
  • Hero Member
  • *****
  • Posts: 580
  • Karma: +18/-0
    • London
    • Solid State Logic Fanatics Database
Re: Computer architecture design
« Reply #2 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.

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Re: Computer architecture design
« Reply #3 on: November 10, 2013, 10:43:46 AM »
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.

Added this to the prerequisites thread! ;)

pascal.verdet

  • Guest
Re: Computer architecture design
« Reply #4 on: November 10, 2013, 03:09:41 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.

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

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Re: Computer architecture design
« Reply #5 on: November 10, 2013, 09:12:32 PM »
Hi Pascal,

Here you have a link for a PDF file with the 3 archs:

http://we.tl/qct4BQiYdE

Cheers,

Artur
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.

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

pascal.verdet

  • Guest
Re: Computer architecture design
« Reply #6 on: November 11, 2013, 09:37:14 AM »
Thanks Artur,
Personally, I would be for the second.
I'm not sure the USB supports rapid exchanges

Cheers
Pascal

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Re: Computer architecture design
« Reply #7 on: November 11, 2013, 08:50:35 PM »
Thanks Artur,
Personally, I would be for the second.
I'm not sure the USB supports rapid exchanges

Cheers
Pascal

Well, I think we won't need to use USB, if we endup realizing that the computer and the available I/O is able to multiplex all cards. But if we reach to the conclusion that we'll need the aid of micro controller, such as an ATmega, we need a good and easy protocol to help the computer exchange data with the microcontroler. In this case an USB bus I believe can be a quick way to have it implemented, we just need to drop in the USB chip and we are done!! Instant serial communications! USB 2.0 we can have an highspeed rate up to 280 Mbits (goodput)! I believe it's more than enough!! ;)

What would be your suggestion?  Does this make any sense?!

Cheers,

Artur
« Last Edit: November 11, 2013, 08:53:27 PM by Artur D'Assumpção »

waltzingbear

  • Full Member
  • ***
  • Posts: 230
  • Karma: +9/-0
    • Portland, Oregon
    • Waltzing Bear Audio
Re: Computer architecture design
« Reply #8 on: November 12, 2013, 06:10:02 AM »
distance should be considered in the equation. The problem with USB is its length limitations. 3M.

Many machine rooms are going to be further away than one run of USB can tolerate, extenders would be needed.

Alan
Alan Garren
Waltzing Bear Audio

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 638
  • Karma: +21/-0
  • Sintra, Portugal
Re: Computer architecture design
« Reply #9 on: November 12, 2013, 08:31:02 AM »
Hi Alan,

If we need a data BUS and opt by USB this is an in-between cards bus. Inside the same box. We are talking about a few centimeters and we shouldn't need a cable.

Anyway if we end-up realizing that we really need to have a micro-controller (or more) there are more communication protocols out there that we can adopt/implement. We just need to choose one that supports enough data rate.

It is not definitely clear that we might need any micro-controller. Maybe the computer I/O (more or less 50-60 available digital pins for our use) might be more that enough to handle everything with the help of some careful multiplexing.

Cheers,

Artur

 


distance should be considered in the equation. The problem with USB is its length limitations. 3M.

Many machine rooms are going to be further away than one run of USB can tolerate, extenders would be needed.

Alan