home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / audio / 3908 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.3 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!news.u.washington.edu!news.uoregon.edu!fp1-music-10.uoregon.edu!user
  2. From:  (Greg May)
  3. Newsgroups: comp.sys.amiga.audio
  4. Subject: Re: A new breed of mods... how about it?
  5. Message-ID: <1ds6i6INNq1g@pith.uoregon.edu>
  6. Date: 11 Nov 92 23:55:50 GMT
  7. Article-I.D.: pith.1ds6i6INNq1g
  8. References: <1dhsq8INNtkk@ub.d.umn.edu> <1992Nov8.043319.19771@ringer.cs.utsa.edu> <1992Nov9.045731.920@athena.cs.uga.edu> <1992Nov9.061439.27849@sol.UVic.CA>
  9. Followup-To: comp.sys.amiga.audio
  10. Distribution: world
  11. Organization: University of Oregon Network Services
  12. Lines: 42
  13. NNTP-Posting-Host: fp1-music-10.uoregon.edu
  14.  
  15. In article <1992Nov9.061439.27849@sol.UVic.CA>, aramsey@ugly.UVic.CA (Aaron
  16.  Ramsey) wrote:
  17. > 
  18. > 
  19. > Seriously though... I really think that this could be written easily
  20. > into the programs around right now. And I really think that it would
  21. > make for a whole new incredible generation of mods. I suppose that
  22. > this wouldn't be much good for you demo writers, with a need for
  23. > short good music, but for those of us writing the music for the
  24. > music's sake... it'd be unreal. I can already hear it... ahhhh...  8-)
  25. > 
  26. > So... What does everbody think about this? Do I get flamed for being
  27. > a visionary?  =)  Give me some feedback. If nobody is interested in
  28. > this, I guess I'll have to give it a go myself... Anybody have 
  29. > source to PT? 8-D 
  30. > 
  31. > -Aaron Ramsey     amramsey@sirius.UVIC.ca
  32. >  Victoria, BC Canada
  33.  
  34. I think it would be an awsome Idea but, I would have to agree that editing
  35. would
  36. be a pain.  It would be possible to gear everything tword floppy bassed
  37. virtual samples.  Each sample could simply have an access time tag
  38. associated with it.  A 100K sample, for instance, might need 20 seconds to
  39. load.
  40.  
  41. For non floppy based or optimized situations, the tracker could time each
  42. sample access time.
  43.  
  44. The tracker would basically have to keep a time based memory management
  45. array.
  46. When ever the user wanted to load in a big sample, some others would
  47. naturally have to go away.  The tracker would simply have to do some
  48. looking ahead to make sure none of what was being gotten rid of is going to
  49. be needed in the near future.
  50.  
  51. I think it is possible and would be an excellent option.
  52.  
  53.  
  54.  
  55. Greg May
  56. gmay@oregon.uoregon.edu
  57.