Prerequisites specification list for the SSLMixed computer

[Artur D'Assumpção]

Hi Pascal,

Having a new system, do we need to support the following things?

-   Smpte Generator / Reader
-   Console VDU, and keyboard
-   Video switcher ? (I’m not sure, may be a standalone unit …)

In the case our new computer would have the Timecode directly from the DAW.
Video switch, we don't need it since we'll not be controlling any video input directly on the console. Maybe HDMI output on the new computer and that can be controlled via software.
Console VDU and keyboard? do we really need it? Supporting that old keyboard may be an headache I don't know...

just my 2 cents,

Cheers,

Artur

[marcmozart]

I think the Video-Switcher had the purpose to switch between Automation-Screen and Total Recall Computer.
The console VDU can be any 5" LCD-Screen that is connected to whatever computer will run our automation data.

I personally think the Console Keyboard and build in VDU is very important. It's a different level to be sitting in front of the console not having to turn to a DAW monitor if necessary. I also personally like to keep the screens at the side - when I mix, I am fully focussing on the console.

Anyway, I believe that supporting the build in keyboard of the console will be the smallest problem we have. That is almost nothing.

Hi Pascal,

Having a new system, do we need to support the following things?

-   Smpte Generator / Reader
-   Console VDU, and keyboard
-   Video switcher ? (I’m not sure, may be a standalone unit …)

In the case our new computer would have the Timecode directly from the DAW.
Video switch, we don't need it since we'll not be controlling any video input directly on the console. Maybe HDMI output on the new computer and that can be controlled via software.
Console VDU and keyboard? do we really need it? Supporting that old keyboard may be an headache I don't know...

just my 2 cents,

Cheers,

Artur

[Artur D'Assumpção]

The monitor part is definitely doable, but maybe it will require a new monitor installed. We have to think this in a modular and interesting way to do it without too much fuss with electronics.

I was already adding to the system the possibility of having a screen connected, such has a modern TV where you could put your automation data, like the old SSL did. But we can think this idea better so we can come up with a solution that works with both scenarios.

Cheers,

Artur

[kilmister]

Smpte reader/writer is important for all tape users.
I hope new software has GUI which is used mostly by a mouse instead commands.

-Paavo

[pascal.verdet]

I personally think the Console Keyboard and build in VDU is very important. It's a different level to be sitting in front of the console not having to turn to a DAW monitor if necessary. I also personally like to keep the screens at the side - when I mix, I am fully focussing on the console.

Smpte reader/writer is important for all tape users.
I hope new software has GUI which is used mostly by a mouse instead commands.

Thanks,
I think that we need customer, and sound engineer feedback.

[marcmozart]

Thanks,
I think that we need customer, and sound engineer feedback.

What about e-mailing studios and/or engineers who we know are operating a 4K with automation on a daily base. Ask them the right questions and also inform them about the project.

[Artur D'Assumpção]

Smpte reader/writer is important for all tape users.
I hope new software has GUI which is used mostly by a mouse instead commands.

-Paavo

Can't that be done by today's already existent support with DAW integration? For instance whoever needs that should have an AVID SYNC or equivalent no? Wouldn't we be reinventing the wheel by coding a SMPTE generator?

The reader part is easy since that would be supported by our client side app, integrated with the DAW or we could (if we have a strong reason for that) support directly an TC IN interface in our computer. Otherwise we wouldn't sync it and he would just follow the client app?

I think the question is, we have 2 ways to do this:

- The computer offers a powerful interface for the console, with routines to manage every component and let a host application deal with the more complicated stuff, such as automation. In this case the app would be following DAW timing or its own internal timing (if no DAW is used) and instruct the computer what to do through the network in realtime. Thus the computer wouldn't need to keep up with time actually, jumps react promptly.

- The computer offers the complete package and has to support time sync to be able to cope with automation.

I will give a though about this, maybe there are better ways to do it (maybe another alternative as come up while I was writing this message )

Cheers,

Artur

Smpte reader/writer is important for all tape users.
I hope new software has GUI which is used mostly by a mouse instead commands.

-Paavo

[waltzingbear]

if its not capable of supporting a session in just hte analog domain, its a deal breaker for me. Do I really want to boot up PT to run an analog session??

Alan

[Artur D'Assumpção]

if its not capable of supporting a session in just hte analog domain, its a deal breaker for me. Do I really want to boot up PT to run an analog session??

Alan

Hi Alan

OK I get where you're getting at. With a new computer you still want the possibility to work 100% analog, without any computers and retain automation syncing with tapes and other gear.

The only issue here is that we might be over-complicating the electronics to support that workflow. I support for us to be able to support 100% analog workflow we'll need the follow stuff:

- SMPTE Generator / SMPTE Reader ?!
- Tape remote control support?!

Can you help us describing what would be essential for you in a 100% analog workflow?

Cheers,

Artur

[PelleG]

God damnit.
Where do you guys find the time to write all these essays?
If you wanna touch at least base one of this project, you need to get to work.

I know from all the emails that I've got that out of 8000 SSL 4/6/8K users there are 7999 different work flows.
To port/emulate the old system and at the same time modernize it is gonna end up with hardware 10 times the cost of the actual console.

Ok. This is the decisions I came to:

Mandatory

• Make it work
• Keep cost down
• Clean linear VCA CV voltage
  Very important for clean audio.

   
Not important

• Where the data is stored
  SD card, disk, DAW, internet. Whatever.
  DAW seems to be a high demand:
  -It's soooo annoying to actually open up a file in another software on top of the DAW. Takes up to 10-15 seconds... sigh.
  DAW control can be nice of course. Familiar edit work flow with automation data is one thing
  But, DAW storage has drawbacks.
        - Can't do different layers (versions) of mixes. Not in a simple way.
        - No offset control. There's no way to determine when the DAW sends it's data.
        - DAW can't do snapshots in a sufficient way.
        - HUI is a big mess: 32 channels max. Shuffle a channel and everything will mess up.
  
• SMPTE
  For analog support - a SMPTE -> MTC converter is waaay cheaper than the other way around.
  99.99% of the users have DAW only and the SMPTE gen/reader is gonna be obsolete and very costly.
• Original keyboard
  Well, I speak for myself but .. if I wanna type hieroglyphs on a keyboard I go to social media.
  When I mix on the other hand, I keep my hands on the faders. 
  A good design means NO keyboard inputs.
  Keyboard is good for typing filenames. And that happens once or twice a day. Buy a wireless keyboard. If it breaks, buy a new one.
  
• Video switcher
  !!! Sure, let's put in Space Invaders and Pong and you can switch between these as well
• Transport
  Cool feature. Nothing more.
  Buy a wireless transport unit for your DAW. Case closed.

     
And hey! Please, I don't try to be rude or anything. But, the extensive list you've made is way to ambitious.
Try to find 1/10 of features you agree on and make it work, do some actual mixing with it and add stuff you miss.


And, to return to my hardware and software.

I am putting together a better looking prototype as we speak.
It's the same system I use and I think it's ... awesome. The most user friendly work flow I ever worked with.

Though, It seems like people disagree I gladly sell my cards to another developer.
DIY or commercial. I can even sell them without components.

If you know some coding you can make your own software/tunnel to HUI, TCIP,.. or whatever.
I can put together an API library/component for the data.

If you're inte MCUs, you can also design various gadgets for the I2C bus (check further down).

My base system is ready to hack. It built like this:

Main card - fed with +/- 12 V

Features

• HID support - No driver is needed
• 104 channels of 10 bit fader data in/out
• MTC reader built in

I/O

• USB 1.1
• 12 x slots for 8 channel bank cards
• I2C port that function as the 13:th slot.
  I have a motor fader pack and a Total Recall switcher on this port.
  I also have a EMT 140 control unit here.
  You can hook up 127 units on this bus. Keyboard, motor faders, transport, time code display, red light, whatever you like
• MIDI in

SSL interface card

Features & IO

• 8 channel 10 bit AD/DA
• 2 LEDs and the status switch.
• Mute control
• CV ref voltages are regulated on this board from the +/-12 V
• Basically everything that's on the original.
  Except!!! control of the 9th fader which is used for the master fader.
  I never ride it, and the DAC chip I liked had only 8 outputs. So, sue me.

And again. I don't want to come out as pessimistic about the whole idea.
I spent around 2500 hours on it and maybe $40.000 so far.
Though, I'm not very experienced designing analog electronics.
To me, this was a lot of fun. I've really embraced the educating side of the experience.
Buying tons of books - USB specs, PCB layout, power regulating, DSP, ...

I also did a lot of research on motor faders, and that's maybe outside the borders.

On the other side, I haven't started on the software bit of the recall yet.

[Artur D'Assumpção]

Hi Pelle,

Thanks so much for your input!

You right, we write a lot... sometimes I feel I am writing a book or something! That tells something about our motivation!

The idea is this project won't be a one-man project. It's the goal than everyone contributes with its own skills to accomplish this task. Only by engaging the community we can assure that a solution such as the computer is staying here for years to come. That's something the community needs to be able to maintain and keep these desks in their prime. 

I don't take wrong your comments and suggestions they are very welcome! Your input is very valuable to us. The idea of the prerequisites list is to define a wishlist of things it would be great to have on a new computer, based on everyone's experience and workflow. This doesn't we will implement them all, nor implement that at first. There must be priorities set at some point to allow the system to grow steadily with the most important features implemented first. I also agree that are features that are nonsense, such has supporting the old keyboard or the old monitor.

I am actually very impressed with the amount of work and investment you've put on Automan's development. I congratulate you because that's an amazing endeavor. Can you share what are your plans for the future for the project?

I believe that the idea of a community project is important because it can count with the participation of its members, facilitating greatly the process and the burned such as the one you've gone through. Also the knowledge will be assured to stay in the community, which is very important.

Cheers,

Artur

[perfectsnd]

Any progess?

[StefanNowak]

I would love the centre keyboard to work and all the macros.

Anyone that is quick on the SSL auto would also need this to work.

Stef.

[Artur D'Assumpção]

Hi guys,

At the momment I am evaluating several alternatives for the development base so we can start coming up with some small circuit designs soon and test isolated things to have a notion how it really works under the hood.

Anyways what's important and what I need is the help from everybody on documenting and reversing stuff. This is an insane task with lots of stuff to walk-trough and we need to do it together.

At the moment under the research forum I am asking help to contribute with a little about the cabling and I/O of the console.

I will be opening soon a Wiki page so we can gather all the information discussed on the forum and laying thing right and pretty.


Regarding the keyboard, I think this is something we shouldn't mess at this moment at least. From what I understand that really OLD keyboard is very strange. It has nothing to do with today's keyboards and you'll have to make a specific circuit and weird code to get it working. It can be something we do in the long term if we see it's doable, but in the meantime and because we have other keyboards we should just not look at it at all. Remember that supporting the keyboard, also means supporting the old SSL workflow and commands. Is this something we really want? Can't we get a better system? I leave this up for discussion...


Cheers,

Artur

[pascal.verdet]

Artur,

if I can help for anything for reversing stuff, let me know.

Cheers
Pascal