Prerequisites specification list for the SSLMixed computer

[kilmister]

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

[marcmozart]

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

[kilmister]

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

[marcmozart]

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

[Artur D'Assumpção]

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

[kilmister]

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

[Artur D'Assumpção]

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

[Artur D'Assumpção]

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

[PelleG]

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

[Artur D'Assumpção]

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

[marcmozart]

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

[perfectsnd]

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.

[pascal.verdet]

Mark,
I agree to.
Cheers,
Pascal

[Artur D'Assumpção]

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
   

[pascal.verdet]

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