On 07 Dec 94 04:30:33 +0000, Johnathan Taylor said: > On (02 Dec 94) [EMAIL PROTECTED] wrote... > > It depends on what the sample is. I was referring to samples that have > > already been compressed and stored as 2 4-bit samples per byte.
> Hmm. sounds like a weird way to store a sample! Are you saying that the Sun > sampler is only 4bits and its input is pre-compressed analoguely? Nononono... SAM samples are stored like that. Sun samples are stored with one sample per byte with a strange compression scheme which means that each byte approximates a 12-bit sample. Of course, they can be pre-processed into SAM samples, which are easier to play. The QLtheme file which I advertised recently was a Sun sample pre-processed into a SAM sample. I had to do this because the Sun sample is over 512K long. However, my Sun ".au" player plays un-pre-processed Sun samples. > Oh that's how! Thanks:-) Assuming that this works on both generators would > setting the amplitude regs simultainiously to different values produce an > average DC potential not corrisponding to any of the normal 16 levels ie > reg2=33h & reg5=44h output a value between 3 & 4? If so then it should be > possible to simulate more resolution! Though of course the software overheads > rise quite a bit using that method. In theory you could approximate up to 6 bits like this (I did 5, using the left and right channels of one sound generator). > Ingenious use of the line-interupt to time the sample-output event, that's > one > way out of the contended ram timing loops:-) I can't think of any others (except maybe using the MIDI interrupt). > An idea just came to mind that it > may be possible to run such a player as a line-interupt service routine! That > way you could have the sample play in the background! Assuming it can be done > quick enough;-) You will have noticed that I went to some trouble to page RAM into section A. That's because the ROM interrupt routine takes so long that there isn't enough time left to play the sample. Even if that could be solved, the player would still take over 80% of the CPU time. > > [about WAV] > Yes, the header info tells the player useful things like the sample rate, > sample width, mono or stereo, number of samples in the file and on what > system > it was created... So does any other format (e.g. .au)... > As good a reason as any! Would you like the WAV format info just in case you > get into that R2R DAC and start thinking about writing a universal sample > player?;-) Go on then. :-) > ... My modem's made by Kellogs...it plugs into the cereal port... :-) :-) imc
