The Waldorf rackAttack is supported by two adaptations, rackAttack and rackAttack Backup. It is not possible to put all their functions in a single adaptation due to limitations in what an adaptation can do. Most of the time you'll work just with rackAttack.
Both adaptations use Universal Inquiry to scan for a rackAttack. If you have problems scanning, install both adaptations manually, then increase Timeout, Send Pause and Play Delay in the parameter box and save the adaptation. Re-Scan to see if that helped; if not, you should spend some quality time with the MIDI setup of SD and some loopback cables to thoroughly test the MIDI communication. As long as there are any errors with the communication, you will have occasional trouble and possibly corrupt data, so you should really see to fix that.
If you have an SD version before 3.0.5b, universal inquiry only works if there are less than 256 files in the Diver folder. You may have to move adaptations and helpfiles that you don't use into a backup folder.
If you are using the 3.1Beta2 version on Mac OSX, there are several bugs that you need to work around or simply live with. In particular the checksum for an outgoing message is never sent by this version of SD. Dumps with a wrong or missing checksum may be silently ignored by the receiving synthesizer. If that happens and the synthesizer in question is a Waldorf, you can edit all the bank drivers in the adaptation as follows: replace the message byte that reads «CHK» with the decimal value «127» (or hexadecimal «7F»). This value is always accepted as a valid checksum regardless of the actual content of the message.
The rackAttack adaptation is for editing the various data types in the machine. It is however very complicated to keep all data for one program together, especially when making libraries. This adaptation works almost exclusively with the edit buffers of the rackAttack. The only exception are Global Data and Programs.
Requesting data for a Program prompts the rackAttack to dump that program, load the program into edit buffers and then dump all edit buffers. Since SD does not know that the edit buffers belong to the program, it will overwrite all unsaved edits in these buffers - please be careful.
Transmitting a Program will store whatever data is in the edit buffers of the rackAttack (not the edit buffers in SD) into that memory location. SD may indeed have a very different notion of what should be in the edit buffers, so it is important that you send all changes made at the unit itself to SD or request it from within SD. I recommend to never mix editing on the rackAttack and from with SD.
If you want to move a Program, request it, clear the location you want to move it to and then drag the Program Edit Buffer to the new location.
The editors do not recognize parameter changes made via the rackAttack due to a bug with checksum handling for incoming messages in SD. If you mix editing in SD and on the rackAttack (again, I don't recommend that), make sure to request the changed data manually from within SD before resuming the edit. Each editor has a request button to facilitate just that.
The rackAttack Backup adaptation is for archival of complete programs and making libraries out of them. It does not have any editors, you can use rackAttack for editing instead.
Version numbering scheme: Vx.yzRr, where «x.yz» is the earliest OS release that supports all the features used by the adaptation and «r» is the release number for the adaptation itself. Unless «x» changes, the adaptation normally works with an earlier OS as well, only that certain functions that are in the adaptation may not implemented on the synth.