From what I understand of the SDK policy about scope platform, there seem to be a "public" version of the scope SDK available for anybody owning a 14/15 DSP board and still a commercial Scope SDK (used by Zarg Music, Digitalaudiosoft,...).
My question would then be: is there such a commercial SDK available to let third party design their own ASB box based on CW Technology. Anybody could give us some hints about that ?
Is there anything like a commercial ASB SDK ?
The only DSP audio hardware as open as you're suggesting is the Soundart Chameleon. If you have the electronics & programming skills it really is all there for you with one of these!! You can program your own application for the Motorola & Coldfire & build your own panel for it. The 100mHz Motorola can run anything from a Rebirth clone (2x303, 808 & 909+MIXER+FX) to an incredible commercial quality 8-part multitimbral polysynth of the same caliber as the Virus (check Australis demos if you don't believe me on that) It's also capable of running modular audio apps, 2 of which were in the making, but have yet to be finished. I've stuck an image below of synth designer Paul Maddox building his own custom front panel for one of his 3 chameleons. Note the actual chameleon mainboard at the back behind his breadboard panel prototype. Since Soundart released the panel protocol, he's been able to re-write the panel software to allow more rotaries, more buttons, leds etc etc (something you can't do with most hardware audio products unless you're one of the world's top synth hackers). There's several guys building their own panel prototypes like this.
It would cost you a lot of money for the tools & hardware to build anything as customised as this with sharcs & CW sure ain't gonna target the DIY market, as it's WAY too small !!
You could build your own 'ASB style' unit with a PC mobo & PSU designed for rackmounting, a Scope card or 3, a midibox64 kit & a nice desktop chassis. Unfortunately it would always be just a PC+Scope card/s inside a midi controller.
It would cost you a lot of money for the tools & hardware to build anything as customised as this with sharcs & CW sure ain't gonna target the DIY market, as it's WAY too small !!
You could build your own 'ASB style' unit with a PC mobo & PSU designed for rackmounting, a Scope card or 3, a midibox64 kit & a nice desktop chassis. Unfortunately it would always be just a PC+Scope card/s inside a midi controller.
what's explained above is just the regular way it can be done with any DSP prototyping kit, regardless if Sharcs, Motorolas or TIs.
The Access Virus in fact started from a 1 chip prototyping board.
Even the interface stuff doesn't need a 'genius' - it's microcontroller programming and more or less identical for a synth DSP or a central heating.
While not necessarily demanding, it's nevertheless a very uneffective and time consuming process.
The Creamware SDKs are a completely different kind of tools.
There are 2 technically more or less equal versions. The older one called DP was sold with a commercial license to deploy solutions, the other one (SDK) may contain a few items more (as it's more recent), but the license EXCLUDES commercial developements.
Both SDKs use a huge(!) library of excellent DSP macros (called atoms) and a state of the art graphic based programming system.
The price range for this type of software reaches from mid 4 figure to low 5 figure Euro values (in industry, usually).
That is what makes the SFP difference.
None of CWA's 'public tools' can create DSP assembly based code and supply it with the proper 'header' information to integrate it in the existing library.
How come ?
All program modules are encrypted with a 2 key process based on the card's serial number and something that CWA provides.
If the information above were known, it would be relatively easy to reverse the process, disassemble and analyse ALL existing DSP code and make ANY part of it run on a prototyping board. It would be a lovely self-service-store...
That is why CWA literally p**s in their pants whenever it comes to detailed documentation, for example to implement low level stuff under a different OS.
Imho the developement system for the current ASB boxes (as for NOAH) is based on the existing one with a couple of internal 'hacks' to make it run in a specialized local environment.
If you publish how THAT is achieved, then you could as well publish the whole system.
my 2 cents, Tom
<font size=-1>[ This Message was edited by: astroman on 2006-06-30 07:47 ]</font>
The Access Virus in fact started from a 1 chip prototyping board.
Even the interface stuff doesn't need a 'genius' - it's microcontroller programming and more or less identical for a synth DSP or a central heating.
While not necessarily demanding, it's nevertheless a very uneffective and time consuming process.
The Creamware SDKs are a completely different kind of tools.
There are 2 technically more or less equal versions. The older one called DP was sold with a commercial license to deploy solutions, the other one (SDK) may contain a few items more (as it's more recent), but the license EXCLUDES commercial developements.
Both SDKs use a huge(!) library of excellent DSP macros (called atoms) and a state of the art graphic based programming system.
The price range for this type of software reaches from mid 4 figure to low 5 figure Euro values (in industry, usually).
That is what makes the SFP difference.
None of CWA's 'public tools' can create DSP assembly based code and supply it with the proper 'header' information to integrate it in the existing library.
How come ?
All program modules are encrypted with a 2 key process based on the card's serial number and something that CWA provides.
If the information above were known, it would be relatively easy to reverse the process, disassemble and analyse ALL existing DSP code and make ANY part of it run on a prototyping board. It would be a lovely self-service-store...
That is why CWA literally p**s in their pants whenever it comes to detailed documentation, for example to implement low level stuff under a different OS.
Imho the developement system for the current ASB boxes (as for NOAH) is based on the existing one with a couple of internal 'hacks' to make it run in a specialized local environment.
If you publish how THAT is achieved, then you could as well publish the whole system.
my 2 cents, Tom
<font size=-1>[ This Message was edited by: astroman on 2006-06-30 07:47 ]</font>
yeah, I'm repeating myself - but these same questions are asked constantly.
I've started using such (or similiar) systems almost 20 years ago, but that doesn't apply to most of the questioners here, probably
You cannot even remotely compare the Chamaleon 'interfaces' with what's contained in SDK or DP, in that context the first paragraph is completely on the topic.
cheers, Tom
2nd half continues...
I've started using such (or similiar) systems almost 20 years ago, but that doesn't apply to most of the questioners here, probably
You cannot even remotely compare the Chamaleon 'interfaces' with what's contained in SDK or DP, in that context the first paragraph is completely on the topic.
cheers, Tom
2nd half continues...
I did not intended people to discard confidential informations about CW intellectual property. Why question was more to know if this CW internal Developpment Platform could be made available to other company providing already plug-in for scope platform for example and let them adapt some of their scope device or even create new ones and let CW produce these new devices (there was some discussion about Solaris ASB for example).
Anyway thanks for your answer.
<font size=-1>[ This Message was edited by: FRA59-HELP on 2006-06-30 14:01 ]</font>
Anyway thanks for your answer.
<font size=-1>[ This Message was edited by: FRA59-HELP on 2006-06-30 14:01 ]</font>
I also thought at a time about the Chameleon platform but I wish devices would have been uploaded through USB or FireWire rather than MIDI.On 2006-06-30 02:30, Shroomz wrote:
The only DSP audio hardware as open as you're suggesting is the Soundart Chameleon. If you have the electronics & programming skills it really is all there for you with one of these!! You can program your own application for the Motorola & Coldfire & build your own panel for it.
And the heart of the Chameleon is a combination of a Freescale main processor (Coldfire) and a single DSP companion (DSP56303 fixed point).
The solution of a racked-PC with scope cards inside could be seen as something similar whereas with this solution the Coldfire processor is replaced by a PC CPU and the companion DSP could be up to 3 scope board letting people combine many powerfull DSP units...
... and you replace the standard chameleon front panel by a PC screen on wich you colud connect kbd/mouse/MIDI controllers...
The only thing which prevented from starting something with the Chamelon platform so far is the power limitation as I would expect to be able to build up much more things with the ability to use several DSP chips.
Cheers.
that's why I put the somewhat lengthy (sorry) explanation above - you cannot do that unless you reveal the basic mechanism how the 'device' loads and executes in the box, and once you've done that (you have to be fairly detailed, as the box isn't a PCI card) the information will leak - sooner or later.On 2006-06-30 10:05, FRA59-HELP wrote:
...was more to know if this CW internal Developpment Platform could be made available to other company providing already plug-in for scope platform for example ...
The problem of a Solaris ASB is a completely different kind, as John explained. What makes Solaris great is it's modular and dynamic character, you have effectively 6 different synths at your command - it would be simply great to have that as a box
cheers, tom
<font size=-1>[ This Message was edited by: astroman on 2006-06-30 11:28 ]</font>
tom,On 2006-06-30 11:23, astroman wrote:
that's why I put the somewhat lengthy (sorry) explanation above - you cannot do that unless you reveal the basic mechanism how the 'device' loads and executes in the box, and once you've done that (you have to be fairly detailed, as the box isn't a PCI card) the information will leak - sooner or later.
<font size=-1>[ This Message was edited by: astroman on 2006-06-30 11:28 ]</font>
I still do not undertsand how the fact that what is possible with PCI card would not be possible with a non-PCI card.
From what I understood with the use of the SDK, you do not directly program the software. The process seems to be more or less assembling so called atom and designing a user interface for it. For me it looks like providing a good software library with a smart tool to help using (calling) the different function contains in the library without providing any source code. From the intellectual property point of view, I was just thinking that CW could provide OEM some of the DSP board that are embedded in its own ASB (I never oppened that different ASB units but I think the main DSP board is the same for every ASB unit). The ASB SDK I was thinking about was then:
- a system design with a library of object code "atoms" and the corresponding design environment (including a mechanism that only allows to run such library on CW manufactured board)
- more or less the same thing that you can do with the Chameleon with this control panel protocol
- a main DSP board that provide DSP, I/O and USB link + the control panel link
Then, this would allow other small synth company to design their synths integrating CW technology and concentrating on application software design rather than on hardware (this should allow VST plug-in software company to also provide their plug-in as hardware solution).
And one of the simplest solution could then be to provide the ASB board as a blackbox in the philosophy of wave APA44M/APA32, TC powercore FW or even G2 modular engine rack...
Would this be just a dream ???
A dream ? I'd rather call it slightly beyond reality - you do not seem to know how f**ked up this (type of) industry is.On 2006-06-30 14:27, FRA59-HELP wrote:
...The ASB SDK I was thinking about was then:
- a system design with a library of object code "atoms" and the corresponding design environment (including a mechanism that only allows to run such library on CW manufactured board)...
Everyone 'steals' everywhere if it's supposed to bring an advantage (at least they try to be as informed about how things are run by competitors as they can be).
Your ideas speak for positive vibrations and good intentions, but the facts are several hundred person-years of developement time that have been put into SFP.
Even with tons of money one could never re-design SFP because the required number of engineers simply isn't available.
Which makes (any) access to this treasure quite a temptation ...
If SDK would output executable code for DSPs, the market would (literally) be flooded with single board computers running one (or more) Sharc(s) and a microcontroller (statement intentionally oversimplyfied)
Who's CWA then ?
Would anybody ask their permission to cludge together a sequence of DSP instructions ?
What for ?
It's almost impossible to legally proof the technical content of such an 'inspired product' - let alone the financial risk if one of the not so small guys is involved, or the time it takes
CWA's protection works because it's not documented and (probably) executed in different machine languages. Any additional detail makes it a magnitude easier to break - you can rely on that.
A couple of years ago it took me just a moment of pure chance and counting one and one together to understand how CWA's demo timeout worked.
Don't get me wrong. It's not about WHAT I've done, but HOW I was able to - just one single bit of information leaked through:
Strangely a 1-hour-demo was still running the next day, but after some time, when loading another synth into the project, the expected dialog appeared. 'Could this be... ?'
It was - the timeout check was only performed in a certain situation
Everyone knows that SFP modules are encrypted. So there must be a corresponding de-cryption process somewhere.
Between here and there. Information simply narrows searches.
These 2 processes are the key to the system in the true sense of the word.
I'm convinced you cannot even document the operation of the PCI card without touching this 'problem'.
cheers, Tom
For that reason, I was not expecting any executable code output but library function with a hardware mechanism that allow this code to be run only on CWA produced hardware. My idea was that CWA could provide something like a motherboard for other companies which let them run devices mades with CWA functions "atoms".If SDK would output executable code for DSPs, the market would (literally) be flooded with single board computers running one (or more) Sharc(s) and a microcontroller (statement intentionally oversimplyfied)
From what I guess, most of these atoms could be just seen as library functions with input and output variables (for audio flow and MIDI flow for control parameter). My idea was more or less about something like the Modular but with the possibility to built up an associated specific front panel on which one could re-affect controls
to enhance ease of use of the device...
So how does scope SDK is possible ?
Everyone knows that SFP modules are encrypted. So there must be a corresponding de-cryption process somewhere.
Between here and there. Information simply narrows searches.
These 2 processes are the key to the system in the true sense of the word.
I'm convinced you cannot even document the operation of the PCI card without touching this 'problem'.
cheers, Tom
I thought it was also possible for developpers to design their own atoms ...
well, it seems that the name 'SDK' points in the wrong direction
it IS a software developement kit regarding the result, say build a synth device.
but it IS NOT on a different level of code generation, like a VSTI toolkit used in conjunction with a C-compiler (for example).
The latter method is used with at least 95% of whatever SDKs, so the name (naturally) implies it for the CWA toolkit.
in fact I also once assumed that at some stage of the developement process there is access to the object code that executes on the Sharcs.
One of the applications I had in mind in was developing and testing stuff in the Scope environment that later would be executed on an embedded system, but not necessarily related to music.
During that time Scope DP was still on sale and I would have spent the extra 5k Euro for the software with a smile - given it included that functionality
But that is NOT the case, and it is NOT possible to develope a set of routines in native Sharc programming that gets added to the 'atoms' of the existing library.
There is an EXTERNAL tool for 'encoding' that stuff, and it WAS available for licensing to commercial developers in the early stages of DP - prices and conditions on request (back then), assume anything from 10k Euro upward.
With access to that tool you can open up the complete SFP/SDK environment because you could literally 'watch' what kind of scrambling is applied and (of course) what the interface specs are.
There's even some (not unreasonable) probability that you could remove the scrambling layer completely from the system.
That's why they won't allow access to it outside of CWA under no circumstances.
It is really more than '...we don't want anyone to peek at how we did the Minimoog filter...'
All that is pretty standard stuff for anyone in (commercial) IT business, so I'm really not telling any secrets here.
Those interested in (and capable to) tamper with the protection already know it and a bit more...
I'm writing it for those who ask themselves '...what the heck is this company doing about their programming docs... ?'
Thre's a hidden 'danger' implied that goes well beyond the greed to be 'the only one' to supply
SDK is simply an application like an extended SFP with a more detailed level of control and stuff that would otherwise be in the way if you 'perform' synths and FX.
Even if it doesn't work flawlessly and has some strange behaviours it's outstanding in it's capabilities as a developement platform.
cheers, Tom
it IS a software developement kit regarding the result, say build a synth device.
but it IS NOT on a different level of code generation, like a VSTI toolkit used in conjunction with a C-compiler (for example).
The latter method is used with at least 95% of whatever SDKs, so the name (naturally) implies it for the CWA toolkit.
in fact I also once assumed that at some stage of the developement process there is access to the object code that executes on the Sharcs.
One of the applications I had in mind in was developing and testing stuff in the Scope environment that later would be executed on an embedded system, but not necessarily related to music.
During that time Scope DP was still on sale and I would have spent the extra 5k Euro for the software with a smile - given it included that functionality
But that is NOT the case, and it is NOT possible to develope a set of routines in native Sharc programming that gets added to the 'atoms' of the existing library.
There is an EXTERNAL tool for 'encoding' that stuff, and it WAS available for licensing to commercial developers in the early stages of DP - prices and conditions on request (back then), assume anything from 10k Euro upward.
With access to that tool you can open up the complete SFP/SDK environment because you could literally 'watch' what kind of scrambling is applied and (of course) what the interface specs are.
There's even some (not unreasonable) probability that you could remove the scrambling layer completely from the system.
That's why they won't allow access to it outside of CWA under no circumstances.
It is really more than '...we don't want anyone to peek at how we did the Minimoog filter...'
All that is pretty standard stuff for anyone in (commercial) IT business, so I'm really not telling any secrets here.
Those interested in (and capable to) tamper with the protection already know it and a bit more...
I'm writing it for those who ask themselves '...what the heck is this company doing about their programming docs... ?'
Thre's a hidden 'danger' implied that goes well beyond the greed to be 'the only one' to supply
SDK is simply an application like an extended SFP with a more detailed level of control and stuff that would otherwise be in the way if you 'perform' synths and FX.
Even if it doesn't work flawlessly and has some strange behaviours it's outstanding in it's capabilities as a developement platform.
cheers, Tom
I'd rather have an SDK for the Noah than anything else on the planet. Unfortunately, it looks as if that may never happen.
I'll tell you something though.... If Creamware did another 'run' of Noah's that came with an SDK & gave that SDK freely to current Noah users, they most certainly WOULD NOT have a failed product on their hands
I'll tell you something though.... If Creamware did another 'run' of Noah's that came with an SDK & gave that SDK freely to current Noah users, they most certainly WOULD NOT have a failed product on their hands
So if I understand you correctly, the "SDK" could be seen as something like a mix between a Modular II/III with a kind of GUI looking like the Scope Routing Windows.SDK is simply an application like an extended SFP with a more detailed level of control and stuff that would otherwise be in the way if you 'perform' synths and FX.
Even if it doesn't work flawlessly and has some strange behaviours it's outstanding in it's capabilities as a developement platform.
cheers, Tom
There you can build up device by selecting atoms from SDK library and make connections betweens them with a process similar to modular and/or Scope routing windows.
Next you build up your own plugin GUI by designing and orgnaising tiff-files.
Then you generate the device.
I guess this is not as simple as this but is this : there is probably many more to do to rise a new device but did I get the general idea ?
<font size=-1>[ This Message was edited by: FRA59-HELP on 2006-07-01 14:56 ]</font>
