PlanetZ forums - scopeusers.com

I thought it would be a good idea if we all got together and made such a document to help each other --- the old-timers could certainly help here. Not sure how Creamware will react to this (as it is disclosing info on the SDK which breaks the NDA?). I thought of a list like in the Reaktor 4 manual and we could make a .pdf. If CWA don't like it perhaps I put it together and Creamware offer it for download for registered SDK users only - thus keeping it secret?

http://www.planetz.com/forums/viewtopic ... forum=11&8

http://www.planetz.com/forums/viewtopic ... forum=11&0

Already tried that , nobody want's to share his obtained knowledge. Certainly not the guru's over here. My guess is that we noobs are on our own on this subject.

greatings,
Casper

No point in releasing the SDK if the documentation is shit and no-one wants to give out information on the modules. Trial and error approach is pretty hopeless IMHO

If you have the SDK, you have signed the SDK Non Disclosure Agreement. It is strongly suggested that you read and understand such an agreement before signing it, since it is a legally binding document, even if both parties are in different countries.

Section N1 *specifically says* that you will refrain from disclosing *any portion* of CW's proprietary information to anyone, INCLUDING people who are under similar restriction as you (i.e. people who have signed the same NDA as you did,) unless you have prior written consent from Creamware.

Now, I Am Not A Lawyer, but failure to follow these guidelines can probably lead to all sorts of situations like getting your SDK licence revoked, rest of your card(s) licence revoked, aliens landing in your soup, etc. I haven't seen the DP licence, but I'm pretty sure it's similar, and given how expensive DP was, I doubt any of the commercial third-party developers want to lose their licence. So that's partly why no one manifests themeselves. This is a public forum accessible by pretty much everyone who has access to Internet, so probably near a billion people, which probably includes a few that work for CW's competitors. Thus you might understand why Creamware wouldn't want all sorts of specific details about their technology, which, BTW, is at least 10 years in the making, posted everywhere and archived in half a dozen web-crawling caches/engines and so on.

If you can catch a guru in a more private non-public place, you might get a bit more success at getting some information, but again this depends on what kind of information you are after. You have to understand tho that not everyone is up to giving out information without getting anything in return, especially if said information was painstakingly acquired over several years.

Not only that, but you get the SDK *for free*. Seriously, go shop around a bit and see how much anything even remotely similar costs.

Quick example, Mathworks's MATLAB + Simulink, for commercial use, would cost you 1900$ + 2800$ (4700$, USD), and you have no idea how shi**y Simulink is! And that's just for a basic setup. This doesn't let you compile anything, PC or DSP-wise. Getting the Signal Processing Toolbox + Blockset would cost you another 800$ + 1000$. Want to compile and run your design on a TI C2000 or C6000 DSP? Get RealTime Workshop + RTW Embedded Coder + Embedded Target for TI C2000 or C6000 for just 7500$ + 5000$ + 4000$.

Check if for youself, mathworks.com, there's an online store.

Also look at Analog Devices's (maker of the SHARC DSP that sits on your cards) new Visual Audio product:

http://www.analog.com/en/prod/0%2C2877% ... %2C00.html

Pretty neat, but 2000$ price tag. In quantities of 1000 =P. And it DOESN'T include VisualDSP, which would probably cost you around 3000$ more.

You get a full blown but slightly undocumented DSP developement platform, customized for audio, for an established product, runnable on any number of DSP you can fit/afford (up to 45 actually, should be plenty =P) with the possibility to re-distribute your device

>> FOR FREE <<

How you can even think of complaining about any aspect of the SDK is kind of beyond me =P.

So here's a few quick tips to help you figure out the bulk of it by yourself:

1) There's a little Help window that's pretty useful to figure out if Modules run off the PC (dll) or DSP, along with info on their input and output pads, i.e sync/async, unipolar or bipolar, etc. Some modules have more information about them, like how they work and what they do. You can also look at the .NFO files in SDKnfo and SDKScript to get more information about some modules.

2) You can figure out alot by yourself by doing some plain and simple experimenting and see what happens. Don't know what a module does? Hook it up to controls, feed it stuff, and see what comes out. This way you can easily figure out the behavior of any module under all possible values.

3) Get a good book (or ebook, if you are cheap/broke =P) on digital electronics design, this will help alot in understanding all the basic modules and how to use them to create just about any kind of circuit/behavior. It will (well, should =P) also cover techniques to minimize circuits (which is great to get the lowest DSP usage without compromising quality) and give you plenty of ideas as to what is possible, and how to do it.

4) Check out Neutron's devices, this should provide a great basis to understand basic circuits, how to hook up stuff, and a good place to start experimenting.

Once you have something going, and need some help with something specific, like hooking up the interface, preset handling, etc., then you will probably have more luck in getting answers from the gurus and other SDK users.
End of rant, now back to your regular whining, I mean programming =P.

On 2005-02-03 17:27, strav100 wrote:
Trial and error approach is pretty hopeless IMHO

=P

Works great for me =P. Got me a nice engineering degree in fact =P.

It'll still be pretty time-consuming tho, there's no escaping that.

........ ' Trial and terror, haha '

creamware isn't giving away any information that isn't already available.

you got a good piece of free software. the nda is just a tool to threaten you with if you behave poorly with it. put porn on the plugs or affect their sales by immitating one of their plugs in the shop.

every one talks. there aren't too many proprietary secrets to be spilled unless former creamware employees do the spilling.

j9k

j9k

Yeah. It's internal software for internal use and it's not made for the masses - maybe it will be kind of fun to try and work out what the hell is going on - likw some mad enigmatic puzzle..........

I think we first ought to ask CreamWare if it's OK to put together a module manual IF they're willing to compile it into a package that only SDK/DP users can read. I don't see why they wouldn't agree to that. There are several things that I don't have a clue what they do. Also, tips for operations such as creating surface "pages" and making surface items and other things. More tutorials would be nice. I'd be willing to help if we could all pitch into the project.

Shall we contact Frank?

Shayne

Yes it is a good idea.

We need to know more info, such as on what some the modules do.

Such a project should not only enrich the Scope SDK's, but the users of our released devices.

I think there is a significant difference about telling someone what algorithm is inside a module , or how to connect the module itself! And beside that, you can't even see the algorithm if your a SDK user!
So no inside is given in the algorithems thus implies that it's save to talk about input-and output-connections of a certain module(that only contains and controls the algo).

For example , if i asked you: How do i connect the fft-module? , then i'm not asking how fft works. I would only want to know the type of value(int,float etc), domain of the value , and important other modules that are related to this module)

Think about this please and tell me again if you think the NDA will forbid this.

greating,

Casper

For example , if i asked you: How do i connect the fft-module? , then i'm not asking how fft works. I would only want to know the type of value(int,float etc), domain of the value , and important other modules that are related to this module)

Like I mentioned, the little Help window will give you most of that information already (input/output type, unipolar/bipolar, sync/async, if it runs on dsp or pc, etc.)

Also, I would definitely tell you to start with something simpler than that FFT-module, which looks pretty complicated, and doesn't even have the IFFT-module to convert back to time-domain (unless there's someway to do that with the FFT-module,) so it's only useful for analysis. Moreover, it runs off the PC, not DSP, so there's not much advantage to using that in Scope. If you are interested in FFT, you would be much better off with a DX or VST SDK and code your own native plugin, that way you'll have much more flexibility, much more accessible memory, and your PCI bus won't be clogged. Also, FFT being fairly related to convolution, a basic usable FFT routine will definitely introduce at least 512-ish samples of delay on your signal (and you won't have very good freq resolution on that FFT, trying to convert it back to time domain probably won't sound very good,) and just like convolution, a Scope card might not have enough memory to do that kind of processing (unless you do nothing but that.) Which is why I'd suggest going native if that's something you really want to do. If you absolutely must/want to control something Scope based with a FFT, I suggest the really radical (well, ok, not that radical =P) idea of using audio signals as control signals, plus some MIDI for the less resolution-critical stuff.

Now, if you were to explain what you want to do exactly with an FFT module within Scope, then it would be much easier for the more advanced users to suggest alternative way to get similar results.

On 2005-02-06 15:21, symbiote wrote:

Like I mentioned, the little Help window will give you most of that information already (input/output type, unipolar/bipolar, sync/async, if it runs on dsp or pc, etc.)

Also, I would definitely tell you to start with something simpler than that FFT-module, which looks pretty complicated, and doesn't even have the IFFT-module to convert back to time-domain (unless there's someway to do that with the FFT-module,) so it's only useful for analysis. Moreover, it runs off the PC, not DSP, so there's not much advantage to using that in Scope. If you are interested in FFT, you would be much better off with a DX or VST SDK and code your own native plugin, that way you'll have much more flexibility, much more accessible memory, and your PCI bus won't be clogged. Also, FFT being fairly related to convolution, a basic usable FFT routine will definitely introduce at least 512-ish samples of delay on your signal (and you won't have very good freq resolution on that FFT, trying to convert it back to time domain probably won't sound very good,) and just like convolution, a Scope card might not have enough memory to do that kind of processing (unless you do nothing but that.) Which is why I'd suggest going native if that's something you really want to do. If you absolutely must/want to control something Scope based with a FFT, I suggest the really radical (well, ok, not that radical =P) idea of using audio signals as control signals, plus some MIDI for the less resolution-critical stuff.

Now, if you were to explain what you want to do exactly with an FFT module within Scope, then it would be much easier for the more advanced users to suggest alternative way to get similar results.

The problem with the Help window is it does not have Word Wrap. So part of the information is out of sight.

Aries

True, but that only affects the written description, not the module type (PC or DSP) nor the pads' type/polarity. Like I said, the SDKnfo and SDKScript contain all the .nfo files displayed by the Help window, in case there's something interesting in the description that gets no-word-wrap-eaten.

On 2005-02-07 19:49, symbiote wrote:
True, but that only affects the written description, not the module type (PC or DSP) nor the pads' type/polarity. Like I said, the SDKnfo and SDKScript contain all the .nfo files displayed by the Help window, in case there's something interesting in the description that gets no-word-wrap-eaten.

I like all new SDK's have version 4 (pre-release) and I think the bits of the manual we do have is from version 3.
Example the SDK does not have two project windows and I think we cannot generate our own nfo's, as right clicking on a new module does not give, edit nfo or edit nfo script.Also I don't think we have a FFT module.

Which version of the SDK do you have symbiote?.

Aries



<font size=-1>[ This Message was edited by: Aries on 2005-02-08 10:10 ]</font>

Same one as you have, the free SDK with the non-commercial licence. And yeah, you are right, the manual isn't totally up to date. I've poked fun at it several times, but managed to figure a few things out.

I just mentioned the .NFO files since people wanted to create some manual for all modules, and it's a good place to start. Even if you can't edit the .NFO files within the SDK, you can with a standard text-file editor without problems.

Personally, I don't really need a manual for modules, I don't find something named "async or" to be terribly confusing =P. I'm sure I could learn a thing or two from such a manual, but I don't find it a necessity. As far as I can see, there are alot of for-internal-use DSP modules that aren't really meant to be used, trying to document every single DSP modules in the list would probably end up eating alot more time than just figuring out the useful ones by oneself. I tend to just hook up some knobs and range text to a module and figure it out, and it's easy to create a bit of a generic "test bed" with lots of range text and knobs loaded, to make investigation easier.

I'm not home right now, so I can't check about the FFT module, I think it's in the big DSP modules list tho. OTOH there's no oscilloscope, which is too bad, but not too much of a problem since you can just use a native one by forwarding audio to a Wave Dest. Also, there's a free visual FFT thingy for Scope, which's name escapes me right now. It's really DSP-hungry, but pretty usable for development if you have a Scope Pro board (which should be the case if you have the SDK =P.)