SSlmixed.com Forum
XK-System (community project) => General Discussion => Topic started by: Artur D'Assumpção on November 06, 2013, 09:28:25 PM
-
Guys,
It's a good a idea to start the discussion on the prerequisites for the new SSLMixed computer. This is important to discuss at this stage because there might be certain requisites that will later have influence on hardware and software design decisions.
Some of the major-topics I think are important to be discussed at this stage (among others) are:
LIST LAST UPDATED: 10/11/2013
- Overall solution requisites (macro features)
- 100% open solution (hardware + software) - MANDATORY
- Low manufacturing costs - MANDATORY
- Support for SSL 4000/5000/6000 consoles (E, G and G+) - MANDATORY
- Support non-moving (vca) and moving fader (ultimation) consoles - MANDATORY
- Keep fader automation status button support - MANDATORY
- Replace completely the old SSL computer - MANDATORY
- Based on 100% new hardware (don't use old parts) - MANDATORY
- Full/partial SSL keyboard support (besides transport)- UNSUPPORTED
- Support legacy monitor- UNSUPPORTED
- Support 100% autonomous system - MANDATORY
- Support client assisted system (ex: DAW support, etc.) - MANDATORY
- Windows and OS X Support - MANDATORY
- IOS Support (tablet support) - SHOULD
- Android Support (tablet support) - SHOULD
- Hardware specific requisites:
- Low power consumption - MANDATORY
- Noiseless (no fans) - MANDATORY
- Small form factor - SHOULD
- No need to preform console modifications/customizing - MANDATORY
- I/O connections specific requisites
- Interface with the SSL through the same flat cables - MANDATORY
- Network support (TCP/IP) - MANDATORY
- Support for external monitor - SHOULD
- Support MTC MANDATORY
- Software specific requisites
- Comprehensive VCA + automation support - MANDATORY
- Comprehensive total recall support - MANDATORY
- Transport support - MANDATORY
- Console surface status support - MANDATORY
- Console modes support (MIX, RECORD, REPLAY, etc.) - MANDATORY
- DAW Integration - MANDATORY
- DAW Transport support - MANDATORY
- DAW Automation support - OPTIONAL
- DAW Control (VCA to DAW / DAW to VCA) - OPTIONAL
- Client side (laptop/desktop) configuration and management - MANDATORY
- Client side (laptop/desktop) live session management support - MANDATORY
- Comprehensive Project management - MANDATORY
- Console live debugging and calibration features - MANDATORY
- Multi-client support - MANDATORY
- Channel live monitor and VCA control support via remote devide (ex: tablet device) - OPTIONAL
- Support multi-display (over TCP/IP) - OPTIONAL
This is totally open for discussion, so lets discuss and define what we really want to do for this project. I will be filling the requisites while these are becoming defined in the next days. :D
Cheers,
Artur
-
Guess I just posted on this already :-)
http://forum.sslmixed.com/index.php?topic=442.msg2495#msg2495
-
I'll go ahead and post some ideas I have to start the discussion:
* It should replace totally the current computer
The old computer hardware is getting very old and very difficult to find and EXPENSIVE!!! So any solution that uses any piece of the old hardware will be limited from the start, it wouldn't be a solution for all SSL users (there are users which don't even have a computer today), could pose challenges to integrate with a modern platform, specially if we're aiming to a low power consumption and small form factor solution and could also prevent the development of new features.
* Should connect trough existent flat cables and without needing any console modifications
This would be nice to have, a 100% plug and play solution.
* Should be small form factor
A small solution would be totally pervasive in the studio and wouldn't need to occupy rack spaces.
* Should be small low consumption and zero noise
* Should fully support automation
* Should fully support total recall like feature
* Should fully support the transport
* Should support moving and non-moving faders
* Should provide DAW integration
* Should be remotely controllable (via desktop application or tablet)
All SSLMixed computer features would be controllable via a controller application.
* Should be multi-client (several simultaneous clients can connect to the computer)
This feature would allow for scenarios were the laptop is the main controller station but you could also interact (only view or view and control) at the same time with one or more tablets/desktops.
More ideas to come...
-
Guess I just posted on this already :-)
http://forum.sslmixed.com/index.php?topic=442.msg2495#msg2495
Could you repost it here please?
-
>>
You guys are really picking my brains here! A couple of thoughts…
These are the components/products/features I think we need to come up with:
VCA TO DAW and DAW to VCA
- turning VCA-Fader Voltages into data that ANY DAW can read, preferable via TCIP
and vice versa of course:
- turning DAW controller data into VCA Voltages
TOTAL RECALL to DAW
- sending Total Recall Data into a DAW by using a Control Surface Protocol
- designing a AU / VST / AAX GUI that receives the total recall data and allows us to use the PlugIn Library Functions of a DAW to store full channels as plug-in patches, so the user can build a library of his favorite channel settings.
Obviously with these features we DO NOT NEED to invent any recorder for the automation as everybody is using their favorite DAW for this purpose. It would also allow people to control their DAW tracks with the VCA Faders, pretty much like on a Duality. My point is, why invent another recorder, when there are thousands out there and everybody already has their favorite one. Same for the Total Recall Data. Let us just NOT write another library software - Logic Pro, for example, is excellent at this, and all we need to do is write a DAW plug-in (with no audio functions or audio passing thru) that receives the controller data. The DAW user could also put our Plug-in at the end of his DAW plug-in chain and store the Recall at EXACTLY the place where the Console Channel is in his audio chain.
These would be an essential "extra" to keep the "feel" of the console:
- Interface for the build in Computer Keyboards, Funtion Keys, Transport etc. (both E and G-Series compatible) which - again - translates to a Control Surface Protocol.
I guess my main point is, let's ONLY develop what is needed and not come up with any redundant stuff.
« Last Edit: Today at 10:19:24 PM by marcmozart »
Report to moderator Logged
www.mozartandfriends.com - A song can change your life
1992 SSL 4048 G-Series
See you at www.facebook.com/mixedbymarcmozart
Konnektor
Newbie
*
Posts: 17
Karma: +7/-0
[applaud] [smite]
London
View Profile
SSL 4k automation to DAW interface
Personal Message (Offline)
Re: the e/g computer - actually a direct to disc recording system
« Reply #3 on: Today at 10:37:56 PM »
Quote
anything can be done :)
it's just a matter of time
due to the footprint of the ribbons the box will have a certain size anyway
if there's a way to output voltages with a beagle board or sthg similar without the need of sample&hold circuits that would be awesome!
maybe we could use an lcd controller? i think these use s&h on every dot
i totally agree Marc!
Quote from: marcmozart on Today at 10:16:22 PM
I guess my main point is, let's ONLY develop what is needed and not come up with any redundant stuff.
TOTAL RECALL to DAW:
i did some packet sniffing on digidesigns pro control (ethernet) which would be ideal for pro tools
it would make already large sessions into extremely large ones, though
« Last Edit: Today at 10:42:19 PM by Konnektor »
-
TOTAL RECALL to DAW:
i did some packet sniffing on digidesigns pro control (ethernet) which would be ideal for pro tools
it would make already large sessions into extremely large ones, though
Eucon could certainly do the job as a Protocol to interface with most DAWs. Not sure what a license would cost. What other alternatives are out there? HUI (shows age now I think), what is the protocol SSL is using on the Duality?
-
The person or company we should be contacting is Adafruit (http://www.adafruit.com/about/). This is right up there alley. The company was started to promote DIY electronics and spur on the youth of today to get involved in electronics and engineering.
Adafruit sells all the parts we need and the can work on customization. It would be worth a call over there especially if you are talking about making the parts available as DIY kind of a kit. They are all over the Raspberry PI computer and the interfacing parts that go with it.
Here is a summary from the about.
Adafruit was founded in 2005 by MIT engineer, Limor "Ladyada" Fried. Her goal was to create the best place online for learning electronics and making the best designed products for makers of all ages and skill levels. Over the last 6 years Adafruit has grown to over 45 employees in the heart of NYC. Adafruit has expanded offerings to include tools, equipment and electronics that Limor personally selects, tests and approves before going in to the Adafruit store. Limor was the first female engineer on the cover of WIRED magazine and was recently awarded Entrepreneur magazine's Entrepreneur of the year. For all press inquires, click here.
-
A personally agree with DAW integration at the possible extent, but at the same time I don't think we should delegate the core control to a DAW plugin, for several limitations.
I would prefer to see a standalone app where I could configure every aspect of the computer and control automation, total recall and maybe new features there. This would be good since it would support every case scenario (people are still using tape) and integrate easily with several DAWs without having to rewrite complex plugins.
In the DAW side i think we also shouldn't flood a plugin with infinite features, sometimes the simple solution will be the best one.
For instance the Duality A-FADA feature is a nice idea on paper but in reality a poor one.
The idea is interesting but in practice it is time consuming to setup and a user ends up using directly the legacy way of SSL automation. My overall impression on this matter:
* Minute correction automation moves are nice to have a pencil tool, making the automation inside protools perfect for that
* broad and musical are much nicer to do directly on the surface and specially if you're not looking at a screen and having to mouse click
So I think both realities are valid and work together, each one shining on each application.
But it would be definitively doable to integrate a DAW with this main application. The automation can be chained and locked to the DAW automation.
Cheers,
Artur
-
These are the components/products/features I think we need to come up with:
VCA TO DAW and DAW to VCA
- turning VCA-Fader Voltages into data that ANY DAW can read, preferable via TCIP
and vice versa of course:
- turning DAW controller data into VCA Voltages
TOTAL RECALL to DAW
- sending Total Recall Data into a DAW by using a Control Surface Protocol
- designing a AU / VST / AAX GUI that receives the total recall data and allows us to use the PlugIn Library Functions of a DAW to store full channels as plug-in patches, so the user can build a library of his favorite channel settings.
Obviously with these features we DO NOT NEED to invent any recorder for the automation as everybody is using their favorite DAW for this purpose. It would also allow people to control their DAW tracks with the VCA Faders, pretty much like on a Duality. My point is, why invent another recorder, when there are thousands out there and everybody already has their favorite one. Same for the Total Recall Data. Let us just NOT write another library software - Logic Pro, for example, is excellent at this, and all we need to do is write a DAW plug-in (with no audio functions or audio passing thru) that receives the controller data. The DAW user could also put our Plug-in at the end of his DAW plug-in chain and store the Recall at EXACTLY the place where the Console Channel is in his audio chain.
These would be an essential "extra" to keep the "feel" of the console:
- Interface for the build in Computer Keyboards, Funtion Keys, Transport etc. (both E and G-Series compatible) which - again - translates to a Control Surface Protocol.
I guess my main point is, let's ONLY develop what is needed and not come up with any redundant stuff.
-
The person or company we should be contacting is Adafruit (http://www.adafruit.com/about/). This is right up there alley. The company was started to promote DIY electronics and spur on the youth of today to get involved in electronics and engineering.
Adafruit sells all the parts we need and the can work on customization. It would be worth a call over there especially if you are talking about making the parts available as DIY kind of a kit. They are all over the Raspberry PI computer and the interfacing parts that go with it.
Here is a summary from the about.
Adafruit was founded in 2005 by MIT engineer, Limor "Ladyada" Fried. Her goal was to create the best place online for learning electronics and making the best designed products for makers of all ages and skill levels. Over the last 6 years Adafruit has grown to over 45 employees in the heart of NYC. Adafruit has expanded offerings to include tools, equipment and electronics that Limor personally selects, tests and approves before going in to the Adafruit store. Limor was the first female engineer on the cover of WIRED magazine and was recently awarded Entrepreneur magazine's Entrepreneur of the year. For all press inquires, click here.
You're talking about the guys of Raspberry Pi right? I used a lot this fantastic board and share its spirit. But I believe i've found an equivalent but more powerful/complete solution for a base for use. I will post about it soon. But just to spice your curiosity check this out:
http://beagleboard.org/products/beaglebone%20black
Cheers,
Artur
-
I mention Adafruit because they have a full compliment of part and support engineers that could help with the creation of the AD/DA cards which seems like that will be the most challenging part. I think they could be a huge resource. It wouldn't hurt to chat with them especially since this a community type of project and that is right in their wheelhouse.
-
You got me - I agree you do not always want to look at the DAW screen. However, did I tell you I just ordered a small 5" screen that will connect as a second monitor to my DAW. It will go into the centre section, replacing the old SSL display.
Since I also have the Alan Smart 2Tools which basically makes my Transport on the SSL work, I will control basic DAW functions from my console.
Just as a side-note.
A personally agree with DAW integration at the possible extent, but at the same time I don't think we should delegate the core control to a DAW plugin, for several limitations.
I would prefer to see a standalone app where I could configure every aspect of the computer and control automation, total recall and maybe new features there. This would be good since it would support every case scenario (people are still using tape) and integrate easily with several DAWs without having to rewrite complex plugins.
In the DAW side i think we also shouldn't flood a plugin with infinite features, sometimes the simple solution will be the best one.
For instance the Duality A-FADA feature is a nice idea on paper but in reality a poor one.
-
I think every solution and extra people thinking about it would be nice!
Yes I believe the magic trick will be on the extra logic (including AD/DA circuits) that will have to be developed. Scan them to see what they can provide. I will eventually need someone to manufacture these cards when they are developed.
The BeagleBone Black board seemed really powerful and perfect for our needs:
AM335x 1GHz ARM® Cortex-A8
512MB DDR3 RAM
2GB 8-bit eMMC on-board flash storage
3D graphics accelerator
NEON floating-point accelerator
2x PRU 32-bit microcontrollers
USB client for power & communications
USB host
Ethernet 10/100
HDMI
2x 46 pin headers (Insane amount of I/O that we can use to connect our special purpose hardware)
I'll really have to find 30mins to write a post only about this.
Cheers,
Artur
-
I think all those features will come with time and are good to save on our "ideas" list. We will eventually have to prioritize because in terms of software this will be an insane amount of work trust me. So at start we need to work on a solid foundation and build our way up.
You got me - I agree you do not always want to look at the DAW screen. However, did I tell you I just ordered a small 5" screen that will connect as a second monitor to my DAW. It will go into the centre section, replacing the old SSL display.
Since I also have the Alan Smart 2Tools which basically makes my Transport on the SSL work, I will control basic DAW functions from my console.
Just as a side-note.
A personally agree with DAW integration at the possible extent, but at the same time I don't think we should delegate the core control to a DAW plugin, for several limitations.
I would prefer to see a standalone app where I could configure every aspect of the computer and control automation, total recall and maybe new features there. This would be good since it would support every case scenario (people are still using tape) and integrate easily with several DAWs without having to rewrite complex plugins.
In the DAW side i think we also shouldn't flood a plugin with infinite features, sometimes the simple solution will be the best one.
For instance the Duality A-FADA feature is a nice idea on paper but in reality a poor one.
-
I love the website http://www.adafruit.com - great resource!!
I mention Adafruit because they have a full compliment of part and support engineers that could help with the creation of the AD/DA cards which seems like that will be the most challenging part. I think they could be a huge resource. It wouldn't hurt to chat with them especially since this a community type of project and that is right in their wheelhouse.
-
The BeagleBone Black board seemed really powerful and perfect for our needs:
I'm wondering life cycle of this board. I mean, with time this board will be obsolete and we find ourselfs at same point where we've started.
Artur, you have mentioned that USB2 has limitations of somekind, but I'd like to ask is there any way that we could use normal pc hardware as a base and then interact via usb, fw, tb, you-name-it to external ad/da box which handles interaction with the console?
-Paavo
-
Great point - the platform we're choosing should have some kind of future-proof roadmap. Not sure - given the size of our consoles - if miniaturization is really a priority? I mean, there are small cases in the PC world, too!
What about making the AD DA a 19" 1 or 2HE box that fits in the console (patchbay) and interfaces with USB3 (that shouldn't be a bottleneck)?
I'm wondering life cycle of this board. I mean, with time this board will be obsolete and we find ourselfs at same point where we've started.
Artur, you have mentioned that USB2 has limitations of somekind, but I'd like to ask is there any way that we could use normal pc hardware as a base and then interact via usb, fw, tb, you-name-it to external ad/da box which handles interaction with the console?
-Paavo
-
Not sure - given the size of our consoles - if miniaturization is really a priority? I mean, there are small cases in the PC world, too!
IMO not really, I would like to use 2U server with dual PSU:s and and raid-1. It's allready something like 11U smaller than current solution.
-Paavo
-
If we use standard PC hardware, everybody could get his CPU in a different form factor. Especially if the AD / DA is an external box, ideally 19" 1HE that fits under the patch rows.
Not sure - given the size of our consoles - if miniaturization is really a priority? I mean, there are small cases in the PC world, too!
IMO not really, I would like to use 2U server with dual PSU:s and and raid-1. It's allready something like 11U smaller than current solution.
-Paavo
-
Well actually the beauty of this is that we are not dependent on this board. This is a simple development board based on a ARM A8 CPU. THis is pretty standard CPU with ARM architecture that you'll find on any cellphone, embedded system, tablet, etc. ARM CPUs and development boards are here at many years and will stay for many years to come. They are a goto CPU for these applications, due to their capacity and lower consumption. ;)
The development board is also a good idea because you have lots of I/O that you can interconnect with your special purpose logic. This is what they are made for, so you can test and develop your hardware applications.
Actually my idea was that we could start with this type of solution since we have a base already made at a very low price and in the future if we feel the need we can build our own board based on a ARM CPU. There are few frameworks that you can use to select the components and functions and that will design a board for you. With the small form factor, ethernet, usb support, we can take it everywhere and plug it on any SSL if we like to and work through our laptop, desktop or tablet.
Working on a PC directly i think it's not a viable option since you'd have to develop a PCI card, which is more complex and PCI on a slot is getting deprecated to thunderbolt. You wouldn't be able to take it with you and connect it to your laptop/table. We could use the USB port on the development board to connect to the PC/Laptop, but I think that if we use the ethernet port and IP protocol we would be opening our possibilities placing the console connected to the network. For instance, we could connect several clients to the SSLMixed computer imagine this cenario:
* main client on the laptop where you control the console working, monitor its status (VCA, channel strips), take snapshots and build the automation.
* one ipad client that can monitor the console faders and interact with it at the same time has the main client
* one client can have the automation vew exported to his screen
And the most interesting is that then can all theoretically be on the other side of the planet! ;)
THese are some ideas that I think are really modern and thinking ahead. All of these are possible and done everyday on other applications.
I hope to have catched your interest to this vision.
Cheers,
Artur
-
If I undestund you right regular PC can't offer required amount of IO without specific PCI card? Even via firewire etc?
I totally agree server-client topology through tcp/ip.
-Paavo
That's correct. I don't know exactly how much I/O does a current x86 (intel/amd) CPU has, but i'm sure the amount they have it's already being very used by the MB components and cards. This is where the PCI enters, but for this you'd have to develop a PCI card which would be much much more painful.
Of course you can go for a peripheral such has USB/Firewire/Thunderbolt, but then for you to support network you would need to have the following configuration:
sslmixedcomputer <----USB---> computer/laptop <-----> network <--------> (other clients)
if makes much more sense to me doing it the following way:
sslmixedcomputer <---- network ----> (other clients, including main computer/laptop)
Unless i'm not seeing some problem now, i believe the network approach should be the way to go because of its easiness of implementations and versatility of options that it gives you. The latency you'll be dealing in a LAN trough an Ethernet cable are sub millisecond if there's not congestion on the network. For remote applications through the Internet of course the use and interactivity of the system would be dependent of the latency between endpoints.
Just as a reminder, we still don't know how many I/O ports on our main board we will need. That will depend greatly on the design for the I/O interface for the console. The supports around 65 multipurpose/configurable GPIO ports, which is a more than comfortable number for advanced applications. We just need to know if our SSL computer project will fit this! ;)
One thing I forgot to mention regarding these development boards, being the beagle a Raspberry Pi or any other is the support you have. You already have an OS base prepared, and various types of full support SDK developed in multiple programming languages to fit any purpose. This is a huge advantage because it will cut down ages of development and gives you an already test-prove base.
Hope this makes any sense! ;)
Cheers,
Artur
-
Hi Paavo,
Well it can, PCs (x86 CPUs) actually have to handle with lots of I/O (most in form of data buses). What happens is that this I/O is limited and a desktop computer nowadays has lots of integrated chips and slot cards that make use of this I/O (firewire, usb, i2c, thunderbolt etc.). Because the I/O is limited and not enough for everything at the same time have to be shared and multiplexed (at very high frequencies). That's where IRQs enter that will enable to multiplex the access to these data buses. We can access this I/O (although shared) through the PCI bus, USB, Firewire or Thunderbolt buses. Each one offer different set of capabilities and features, such as data rate.
For our computer we could find a way to use a standard PC, or by developing a PCI card or a separated interface that connects via USB (such has the Beagle or any other, such as one made by us). What I think is opting for the PCI option will be much harder since designing a PCI card gives lots of trouble and you need to send it to a factory for manufacturing. If we go with the usb/thunderbolt option we will be loosing the benefit of having our computer directly attached to the network taking advantages of it, we have to relinquish that function to the Desktop.
Cheers,
Artur
-
Guys,
I've updated the prerequisites list with what we've discussed so far. Keep discussing the subject so we can continue brainstorming on the subject.
Please let me know if you find anything wrong.
Cheers,
Artur
-
Hey,
Weird for me to read about this now. I've gone thru all this a couple of years ago.
Anyway, I have backplane and interfacing cards for you that are plug and play for the SSL.
It's using standard USB HID protocol. So it doesn't need a driver. Has a MTC reader as well.
Maybe my complete system will be for sale some day, maybe not.
I don't wanna spoil the fun of making it from scratch ... but
just saying...
-
Hi Pelle,
Thanks for sharing your design. Is this a schematic for a card module to handle 1 channel bucket?
Currently your design can handle everything from the console? (not speaking about software):
- vcas, totall recall, leds, transport, operation modes ? Can you already tap on all these signals/buses?
Your insight on the SSL info would be much appreciated since we are going to have to go through the same reverse engineering path you went through.
We're trying to start a new design for the SSL computer open for the community, designed and supported by the community (please read the thread I made about the SSL letter from the community so you can understand the motivation).
Cheers,
Artur
Cheers,
Artur
-
Hi guys,
I agree it's kinda weird to have Pelle on the forum, who already did most of what we set out to do, and not have him participate on this in some kind of way.
The question is - what does it take to work that out?
Let's say, Pelles Know-How goes into the cards that will be manufactured at one point. Pelles participation will probably allow us to be faster and build a better product. One option would be to attach a certain %-based license fee to the sale of the AD/DA-cards. If we can find a reasonable solution that works for both Pelle AND the community - why not?
This way, Pelle might have a better shot at recouping his investment than doing it on his own.
Just throwing it out there - would be stupid not to bring it up.
Hey,
Weird for me to read about this now. I've gone thru all this a couple of years ago.
Anyway, I have backplane and interfacing cards for you that are plug and play for the SSL.
It's using standard USB HID protocol. So it doesn't need a driver. Has a MTC reader as well.
Maybe my complete system will be for sale some day, maybe not.
I don't wanna spoil the fun of making it from scratch ... but
just saying...
-
Hi guys,
I agree it's kinda weird to have Pelle on the forum, who already did most of what we set out to do, and not have him participate on this in some kind of way.
The question is - what does it take to work that out?
Let's say, Pelles Know-How goes into the cards that will be manufactured at one point. Pelles participation will probably allow us to be faster and build a better product. One option would be to attach a certain %-based license fee to the sale of the AD/DA-cards. If we can find a reasonable solution that works for both Pelle AND the community - why not?
This way, Pelle might have a better shot at recouping his investment than doing it on his own.
Just throwing it out there - would be stupid not to bring it up.
Mark I agree with 100% on this. I believe Pelle has a product that is ready to see the light of the day and he has done a substantial amount of work along with what I would image to be a substantial capital outlay to design, decode, and prototype these cards and this process. If Pelle would like to bring his expertise to the project there absolutely must be some way for his to essentially get paid for this knowledge. We have no idea what his gameplan was, but I would be okay with attaching a licensing fee or something to the products that he was able to have a large in desigining.
We don't know if Pelle was positioning this to be a viable business, a small niche opportunity, or just something that was about solving a great problem.
Bottom line is Pelle is part the project, I would agree to compensation for you.
-
Mark,
I agree to.
Cheers,
Pascal
-
Hi guys,
Pelle's knowledge would be more than welcome and most appreciated to our community project, after all he's one of us! Of course it would be nice to have Pelle's work somehow integrated into our work since he has done a great part of the work and R&D we will have to do if starting from scratch.
We all would like to compensate Pelle's for his work and investment on such a hard task, but before committing to any decision we should also ask ourselves if Pelle's project integration with the SSLMixed Computer community project is the best way to compensate for Pelle's work and investment so far. The are several questions we need to evaluate beforehand. Let me share with you my current thinking process:
- Is Pelle willing to contribute with his work to the community?
- If YES at what level is he willing to contribute?
- A) He's willing to contribute with his entire Automan project (R&D + Hardware + Software) to SSLMixed Computer;
This option makes sense if he's deciding to drop out his system development and support;
- B) He's willing to contribute with R&D only (the knowledge he acquired while reverse engineering and designing the system);
This option makes sense if he wishes to continue with Automan's development but also contribute with his know how to the community open project;
- If YES what does Pelle wants in return (cost)/community wants to give back (compensation)?
- He's willing to sell/license his work (A or/and B):
- Is this compatible to the project mission (this it's not yet defined and open for discussion)?
- if YES how can we actually repay Pelle's contribution ?
- A one time pay out?
- A percentage fee of SSLMixed Computer donations/fees?
- A percentage fee of SSLMixed Computer of selling profit?
- He's willing to donate his work (A or/and B):
- if YES how can we actually repay Pelle's contribution ?
- A one time pay out?
- A percentage fee of SSLMixed Computer donations/fees?
- A percentage fee of SSLMixed Computer of selling profit?
- If NO he's not willing to contribute.
- This makes sense total if he wishes to protect his investment and secure Automan's intellectual property, keeping projects totally separated and his time focused on his business investment.
I personally would love to have Pelle's onboard, no matter the way he wishes or sees more appropriated to contribute. That being said, I don't see any problem having other systems out there (Pelle's, Dramastic Audio, etc.), there's space for everyone to shine its way. For sure each system will have things they will do better than others (feature wise, cost wise, project wise).
Just as a side note, the way I see the SSLMixed Computer project is as an 100% Open Project that's made by the community to the community (I've already explained the motivations and advantages for this position). I don't also see it as a project to build and compete in a market as a business-oriented solution, that would definitely defeat the hole purpose. This doesn't mean it should all be given for free. Definitely the knowledge (schematics, source code, related documentation) should be open and free to the community, since this would propeller the development and the continuous enrichment of our solution. But there should also be some kind of retribution fee or option that enables the donation/contribution of funds to sustain the community and compensate those who have personal costs with the development. Also I envision that the community could have some return if wants to sell related services, such as support or manufacturing/assembling services, selling pre-built parts by request (not everyone knows how to solder). This is often typical in open projects, where's there's always an auto-sustainability side of it.
Of course the way we would like to define and embrace this SSLMixed Project is still open for discussion so the is the time to discuss, evaluate options and make decisions. After all its the community project.
Cheers,
Artur
-
Hello guys,
Please, keep in mind, that if we want to preserve the consoles in the state of origin, without any modification, then the new material will have to take into account all the functions described in the diagram block (page 2-18):
- VCA analog inputs
- VCA analog outputs
- Led’s & Switches Interface
- Transport control
- Smpte Generator / Reader
- Console VDU, and keyboard
- Video switcher ? (I’m not sure, may be a standalone unit …)
Please, give me your felling about them.
Cheers,
Pascal
-
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
-
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
-
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
-
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
-
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.
-
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.
-
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
-
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
-
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
-
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. ;D
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. 8)
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 ;D - 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.
-
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
-
Any progess?
-
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.
-
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
-
Artur,
if I can help for anything for reversing stuff, let me know.
Cheers
Pascal
-
Hi Pascal,
At this stage I am just asking people to help me documenting the SSL I/O. Please check the research forum where I posted this request.
Currently I can't dive deep on the reverse part on my side since I'm about to get a new console commissioned. So until then I don't have access to a console. But there's all this stuff that we can do before laying hands on the console electronics.
Cheers,
Artur
Artur,
if I can help for anything for reversing stuff, let me know.
Cheers
Pascal
-
just going to chime in for a quick sec...love the idea love the ambition....do you guys realize part of the computer extends into a few parts in the console? And not everything in the computer is completely relevant to the auto or recall or audio but without certain components in there you cant get certain things to co operate with each other and work right....
I have a computer sitting downstairs with a supply too i might add, il look at it, if its complete and hasnt been raped il donate it to you guys for reverse engineering.
Key points of a new system....it NEEDS to work as it currently does, key functions etc etc but be more modern, workable in a hybrid enviornment( analog and digital (daw)). Im a mixer, producer and developer and thats just a few hats ive worn for the past 25+ years so what i use my console for goes above and beyond what it was made for but if it doesnt have the basics it was born with its useless to me. Again just my 2 cents
-
Hi,
This is the perfect time for everyone to express their concerns and give suggestions. With the contribution of everyone we will be able to make a solution the serves the most scenarios possible. It's also feasible that this won't be a project where we offer all the features from day 1 of the release. Instead we will be upgrading the hardware and software with relevant updates to rollout quicker the solution to everyone on the forum. Since the mindset of the project is a community one, everyone with little set of skills will be able to manufacture the new boards and install the software. Of course we are thinking in providing these boards for a small fee, but this will be almost certainly only for major revisions.
By the way, I know i've been very quiet on the forum, don't panic! I'm on top of things, I'm just currently overseeing the comission of my new SSL 6K console, which will be used also as a base for the SSLMixed Computer development.
Merry Christmas to you all!! ;)
Cheers,
Artur
-
Sounds exciting! Merry X-Mas Artur!
-
I can't help thinking this is over-complicating the job. Whilst there are some people who want to just replace the computer with a modern equivalent, I can't help thinking a lot of people would be happy with machine control, fader control, cuts and Total Recall
Leaving TR aside for a moment, what about machine control and faders/cuts? Most people use a DAW, not tape, and for them a way to write & update faders and cuts would go a long way to integrating the SSL back into the studio
My suggestion: a simple interface on the console reading the faders & cuts. Midi in and out. Faders controlled as Midi continuous controllers. Data written to the DAW as it is now with Pro Tools / Logic / etc
Yes, I agree that 127 levels of resolution may not be ideal for a fader. So use a non-linear scale and two controllers per fader or some other bastardisation of the Midi spec.
My feeling is that making a system that will work with every DAW out there will guarantee a significant take-up and that take-up will help the project succeed rather than kill it
Nick Froome
-
Sorry for hijacking.
I posted some news in the thread about Automan:
http://forum.sslmixed.com/index.php?topic=118.msg2988#msg2988
End of message.
Best,
PelleG
-
Hi Pelle,
THanks for the info! You're always welcome to hijack! ;) Gonna check it out!
Cheers,
Artur