RFD - legacy software features to port - feeler discussion

[Artur D'Assumpção]

Hi guys,

We are entering the software development stage of our SSL computer. Without flooding too much into details of the new system work overall, there will be a "virtual environment" which allows you to interact with the system in a similar fashion as the legacy SSL studio system. You can do it with the SSL keyboard or the computer keyboard, as you prefer.

This approach will allow us to retain (without taking into consideration any modern features and new ways of interaction at this stage) the winning workflow of the SSL consoles. Of course there will be room to improve, but our first goal is to assure that SSL users will be able to use the new system with little learning curve/workflow disruption as possible.

For this reason we will still retain the same "mixing studio" system approach which we all know from SSL from many many years. Of course this will have to be brought to 2015 standards, but all with minimal disruption.

As you can understand, there are many features that don't make any sense these days which don't make any sense to port back to the new system. One obvious feature is floppy handling... but there are many others.

This puts into light a more important overall discussion: Assuming that we'll keep the same legacy environment/workflow (but modernized) which overall features do you think should be ported to the new system and which ones can be dropped without penalty? It would be interesting to hear all your opinions so we can steer the  resources and prioritize development in the right direction.

Some ideas, think in stuff such as:
     - software groups? - is this used at all?
     - Calibration and test features? this can be much better implemented directly on the "window based" management software, not in the mixing studio virtual environment
     - offline inserts, etc.


Would love to hear your thoughts,

Cheers,

Artur

[marcmozart]

With all respect to the traditional workflow, I think the key feature will be access to the SSL VCAs via a plug-in (AU, VST, AAX) that we can insert in the DAW. All the plug-in needs is a fader, cut-switch and assignment to one of the VCAs.

Just my two cents... of course I'd love to see stuff like support of the SSL keyboard etc. but that wouldn't be the first priority.

Anyway, thrilled by the sensational work you guys have done so far!!!

[Artur D'Assumpção]

Hi Marc

I understand what you say and we already had this discussion. These types of features is something I put in the category of a new workflow vision for the new system. This will allow to add other ways of exploring the SSL, other than the legacy workflow.

Anyways, this is something we'll be definitely looking at, but not in the first major releases. At this stage the priority is to port the SSL workflow into a modern platform and allow a user to plug and play and continue working with little to any learning curve necessary. Of course there will be some differences, such as, architecture, graphics, extra features, etc... But the main mixing workflow will remain basically the same.

This is what I am looking with this discussion. Regarding the legacy mixing workflow, which features should be ported and which should be dropped. I am making my own list, but I really want the opinion of the community because my vision is limited... and experience in the end of the day talks louder.

Cheers,

Artur

[marcmozart]

I disagree here, brother. A simple DAW connection to the hardware, that can connect to any DAW should be first IMHO. Considering that reproducing the old workflow in a new software is probably the task of a year vs. the task of a month for the basic DAW connection.

[Artur D'Assumpção]

Hi Marc,

Actually it's not the task of the year to be honest. it's just a matter of prioritizing what's a must have right now and what's not... or even drop out.

The interface is really simple if you look at it, specially if we opt to maintain the same look and feel (but rather modernized graphics). The only thing that I see it can increase the task is if we were to replicate EVERYTHING, which I really think it's a mistake and redundant. There are loooots of features which will not be needed anymore, specially because they are replaced by the computer manager (window software) and are much easier do develop, display and interact on a window based application. These types of features which I would simply drop out completely. 

The underlying engine is common, either on a "virtual environment" or to connect with remote plugins. The engine is the first step and the big work. This is all the mechanics and logic of the hardware. The engine will abstract all these aspects to the upper application layer, would that be the "mixing system"/virtual environment or plugins.

Of course you are right in one aspect, if I rely completely on the DAW to automate, that development overhead would not exist on the new system, since you'd be pushing that load to the DAW.

Anyways, regarding the plugins, this is something we will do definitely. Looking into this subject without much thought, I'd see the plugins like a modern "mixing system" that's completely separate of the "virtual enviroment" mixing system. So, if you decide to use the DAW to control/automate the faders, this would be mutually exclusive with automating in the "virtual environment" mixing system.

Regarding also the DAW behavior for VCA and Ultimation systems, this will have to be well thought. There are some stuff you can't really control remotely... such as the VCA assignment. You can only do this via the fader thumb-wheel, there is no other way. The will be always some dependency with the hardware manual interaction.

Cheers,

Artur

[PelleG]

Maybe I'm not the right person to interfere here. Or I'm spot on. Don't know :-)

There's one thing that I always found confusing. It's the gap between the accuracy of a synced system versus the HUI (or whatever protocol) controlled.
All the DAW solutions are pretty sketchy when pushed hard. There's not a demand in spec to be super accurate since it's just for display.
This, together with a veeeery expensive product is kind of a contradiction.
I guess no one cares in the end. But where to draw the line?

Just a tip. A peripheral device in the old days had access to memory and interrupts. There was actually much easier to design industrial PC interfaces since you could share clocks and control timings.
To be able to switch between PC software driven sync and on-device sync (as SMPTE or MTC) can be tricky.

[Artur D'Assumpção]

Hi Pelle,

Thanks for your insight/input! I am sure there will be some challenges down the line with plugin integration with the overall system.

Despite that, regarding time synchronization at this point we decided to keep using SMPTE, since it works very fine if you look to successful DAW integration solutions such as THE KONNEKTOR or 2TOOLS. The only difference which I am currently studying is that we are planning to test early on the use of MIDI over Ethernet, allowing to relinquish the use of MIDI interfaces or any other cabling. With a MIDI over Ethernet interface we can send either SMPTE (MTC) and MMC for transport sync trough a common communication media in the studio (IP network).

At this point we really are looking only into TC synchronization and transport control, that's why the use of MIDI. I imagine that going for a plugin controlled fader could require a bit more precision, hence the use of HUI protocol?

Cheers,

Artur

[PelleG]

HUI is unfortunately out of all type of control. I mean, I recall you debated in between frame ticks some year ago and that accuracy is just impossible with HUI.
HUI spec define data must leave DAW within 200ms of an event. That's 6 frames.

So, whatever nice solution you'll come up with the DAW side of things will always be somewhat non-pro.

That being said, whatever gets the job done .. and so on.

[Artur D'Assumpção]

Interesting...

Does the same happen with MIDI? Is that related with the priority DAWs give to the MIDI/HUI scheduler or something like that?

Currently, only regarding SMPTE via MIDI and MTC the level of of-sync TC frames generated are, in my opinion, negligible for the type of work we are doing, which is sync fader movement to a certain Timecode and with a certain precision. The precision amount we are talking about here is not that critical in "computer speed" world! Regarding that issue, I suppose the TC/SMPTE messages over MIDI have higher priority, since these have to be somewhat "accurately" synced frames at 40ms intervals (for 25 fps)?

So if I understand correctly what you're trying to say is, since HUI (perhaps also MIDI) messages are output from the DAW with a variable/maximum 200ms latency (no guarantees), this is not enough (clearly it's not) to sync audio faders which are affecting in realtime the audio correct? Something that is not a problem for control surfaces, since fader movement replay is only for show off.

This will definitely pose a challenge to a plugin approach like Marc suggested...

Regarding my tick schematic, that is a way to sync the SMPTE code in with the fader snapshots timing, without one being dependent of the other (i.e.: different sampling rates). The suggested approach, allows also for any multiple amount of  demultiplexing of the SMPTE sync, for bigger precision values between SMPTE frames. This way you can have 2,4,8,16,32... intervals between frames, allowing for a more precise alignment of the movement in the SMPTE timing between frames.

Cheers,

Artur

[PelleG]

Exactly. HUI is for display of VIRTUAL faders. Not critical.
Eucon might be different, don't know. But I doubt it.
A plug in might be a better solution, but I'm pretty sure you can't get it to look ahead for auto-data.
Then you have the AAX developer license, which I have tried to get for 6 years. Not even a reply.
A friend of mine from the "inside" said they'll never give it since a product like this is undermining pro tools and its hardware stuff. F**ckers.

[Artur D'Assumpção]

That testimony regarding the AAX license is somewhat shocking! AVID will only loose long term with dated monopoly strategies...

Have you tried a VST plugin? There are some good VST bridges for AAX.

Artur

[KoleThomsen]

For Ultimation desks, would it be possible to incorporate a "Motors on, VCAs on"-function?
It's actually pretty weird the SSL computer doesn't do this as an option, since stereo channels work this way.

Would love to have this feature!

[Artur D'Assumpção]

Hi,

That's a good questions... Never though of a VCA mode assisted by motors. Electronically speaking I would have to look into this... check if it's possible to have both modes enabled simultaneously.

Regarding the operation of that mode, I can see some problems at a first glance....

During the automation replay, or even during writing (such as trim mode), the computer automatically bypasses MOTORS ON into VCA mode to allow for the correct automation writing and replay (when you have your finger on the fader). This would be the major problem I can foresee, since with both modes ON, you would be having a problem in this area... What would happen to replay if your finger was over the fader holding the VCA control voltage?

I will look into this...

Cheers,

Artur