home *** CD-ROM | disk | FTP | other *** search
/ rtsi.com / 2014.01.www.rtsi.com.tar / www.rtsi.com / OS9 / MM1 / SOUNDUTILS / mm1_tracker.lzh / TRACKER4.6 / Amiga / Docs / amiga.future next >
Text File  |  1994-11-24  |  2KB  |  53 lines
  1. The shape of things to come
  2.  
  3. I don't think tracker will ever be finished...
  4. Every time I think I'm done with it, some new ideas come.
  5.  
  6. Anyhow, the previous version was entirely line-oriented.
  7. This version now has a real graphical user interface,
  8. but, to keep with some of Dave Haynie's ideas, it's not
  9. quite real time yet... Yes, there are some times when
  10. tracker's user interface doesn't answer.
  11. Since I use a very simple model for handling interaction,
  12. I hope there is no nasty deadlock left, but I haven't tested
  13. it thoroughly enough...
  14.  
  15. So the future is to add callback hooks everywhere to handle
  16. the user requests with more responsiveness.
  17. The future is also to add more controls to the user interface.
  18. After all, I've got an incredible amount of data and switchs
  19. about a module that I don't use at the time:
  20. global volume,
  21. volume on a per-instrument basis,
  22. volume on a track per track basis,
  23. non-linear volume scaling,
  24. on-the-fly transposition,
  25. switching instruments on/off...
  26.  
  27. I also hope some other persons will endeavour to port it to other platforms
  28. like the Macintosh or the NeXt-OS... if I have time, I'll build a simple GUI
  29. for X-Windows myself (and a friend is already in the middle of an OS/2 port).
  30.  
  31. One other thing is that Fast Forward and Rewind (<< and >>)
  32. don't work quite as well as they should. When I got around to
  33. implementing my `virtual player' idea, they will work much better,
  34. and you won't differentiate tracker from a full CD player anymore !
  35. Except for much better control on the sound quality...
  36.  
  37. Some other thing is (of course) other types of sample. I need a whole
  38. new type of audio handler for it, since 16 bit samples are not out of the
  39. question (rescaling, querying, and so on...). That will be a major project,
  40. I'm afraid.
  41. Why of course ? Well, MED modules need other type of samples, and I definitely
  42. would like to add channel-splicing :-):-):-).
  43.  
  44. Some interesting experiments in the same vein would be to allow very big samples
  45. and load them on the fly when needed... Nothing is impossible there. Indeed, the
  46. buffered two-tasks model already implements most of the effort (just need to add
  47. a cache algorithm and a good loader... Maybe as another independent process):
  48. basically, it's exactly the same as our post-synchronized scroller window !
  49.  
  50. Well, well, well. Enough rambling... 
  51.  
  52.  
  53.