home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / music / patchlib / patchsrc / convert.doc < prev    next >
Text File  |  1985-11-19  |  5KB  |  90 lines
  1. Conversion for both the DX and CZ series have a few things in common.  The
  2. preprocessor variable TOTAL_SIZE should be changed to the total size (in
  3. bytes) of a single voice in the synth.  The preprocessor variable VOICE_SIZE
  4. should be changed to the number of voice parameters that the program will be
  5. setting when generating new voices (which will correspond to the number of
  6. parameters given in the RANDOM_FILE parameter file).
  7.  
  8. Voices are always sent to and read from the voice edit area of the synth.
  9.  
  10. You will have to set up a new RANDOM_FILE with appropiate parameter contents.
  11. I hope you know the function of all the voice parameters because it would take
  12. another 10 pages to explain all of them in detail -- check your owner's manual.
  13. For the DX100 you can examine how I set them against the listing in the back
  14. of the owner's manual (sorry, I'm not going to type it in!).  The CZ parameters
  15. can be checked against the listing in CZ101.DOC .
  16.  
  17. The remaining comments have to deal principally with random voice generation
  18. and are best dealt with separately for each series.
  19.  
  20. DX series Conversion
  21. --------------------
  22. Voice generation is extremely simple.  Essentially, each data byte in the
  23. voice corresponds to a voice parameter in the synth.  So, to generate a voice,
  24. we go through each data byte, generate a random parameter as dictated by the
  25. RANDOM_FILE parameter file, stuff it into the data byte, and continue.  When
  26. all the data bytes are filled we are done.  All this is done in the make_voice()
  27. routine.  This is a slight over-simplification, however.  The scheme described 
  28. is adhered to only for the first VOICE_SIZE data bytes.  The remaining bytes 
  29. are either voice name bytes (into which we put "RANDOM") or parameters which 
  30. have no effect on the DX100 (into which we put 0).  In addition, certain of 
  31. the VOICE_SIZE bytes are modified as described in the make_voice() routine to
  32. produce more pleasing effects in ways that are difficult to deal with in the
  33. RANDOM_FILE parameters.
  34.  
  35. Note that whenever a voice name is obtained from the user for a new voice,
  36. it is also copied into the appropiate data bytes in the voice (overwriting
  37. "RANDOM" or whatever).
  38.  
  39. CZ series Conversion
  40. --------------------
  41. As stated previously, the program should already work for the CZ-1000 and 5000.
  42. However, the 5000 (unlike the 1000) is not 100% identical in system exclusive
  43. features.  The important thing is that the tone data format *is* 100% identical.
  44. However, there are certain other data that can be sent for the 5000 as well as
  45. tone data (namely GLIDE NOTE, GLIDE TIME, MODULATION DEPTH, VOLUME LEVEL, and
  46. GLIDE ON/OFF).  Not having a CZ-5000 I don't know if it is important to set any
  47. of these, but it would seem that since these are not an intrinsic part of the
  48. tone data their setting(s) should be left to the user.  Not to mention that 
  49. there is no way to *read* them back from the 5000.
  50.  
  51. If you are going to attempt conversion for some other CZ (e.g., CZ-1), good 
  52. luck!  Well really, it is not impossible, just a lot harder than for a DX.  
  53. First, check the differences in system exclusive implementation.  If you are 
  54. lucky, (like with the CZ-1000) the tone data format will be identical.  If
  55. there are no other things to be sent with a tone, then no conversion is needed.
  56. If you are not so lucky, and there are differences in the system exclusive
  57. implementation, keep a few things in mind:
  58.  
  59.     1) Casio sends their data bytes with the nibbles reversed.  Notice
  60.         that at the end of my make_voice() routine, all the just
  61.         generated data bytes get reversed.
  62.  
  63.     2) If the data byte values to be sent don't seem to have any simple
  64.         relation to the parameter value (like VIBRATO DELAY TIME on
  65.         the CZ-101) you can use CONVERT.PRG to convert an ASCII hex
  66.         file you've created in an editor to binary (and back again
  67.         if you've made an error and want to examine a binary file).
  68.  
  69.     3) If a name can be stored with a voice, look at the parts of the DX
  70.         code that deal with that (usually short sections surrounded
  71.         by #ifdef DX100, #endif dealing with 'v_name' in between).
  72.  
  73.     4) Handshaking is done by handshake().
  74.  
  75.     5) If the system exclusive implementation is *similar* (say just more
  76.         ADSR steps for example) you may be able to get away with not
  77.         re-writing the make_voice() routine from scratch, perhaps just
  78.         by extending the range of a loop variable.
  79.  
  80.     6) Keep in mind when looking at make_voice() that many data values are
  81.         being put in a single byte or, worse, split across bytes. Don't
  82.         yell at me.  Also, those incredible messy functions you see
  83.         are because for some reason Casio doesn't believe that if a
  84.         parameter value is 35 you should send 35, instead you send 86 
  85.         (or whatever).  
  86.         
  87. If you are willing to settle for just a voice librarian but not generator, the 
  88. conversion should be trivial and you can probably forget all my little helpful 
  89. suggestions above.
  90.