XK-System (community project) > Software Development
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
Navigation
[0] Message Index
[#] Next page
Go to full version