Commander X16

 

This is the third version of this routine, thus far. It's currently written as a stanalone thing, but soon I'll start integrating it into zsound and hopefully be able to have 1 track of PCM available for ZSM music playback. I'm still not quite sure how I want to integrate that yet, but at least the non-blocking streaming routine works, and seems to not burn too much CPU, given the task at hand....

 

The big question to me seems how you pass the audio data. Do you support a limited amount of samples that can be reused all the time like in mod files, or do you want to stick to the streaming paradigm even for PCM?

In theory, you should be able to pass it a pointer to any arbitrary location, specify the data format and size and say "go" - at least that's what the core loop does.

Honestly, I'm trying to figure out what sort of "features" to add on top of that. The core of the routine is basically a spooler that blits from some location into the FIFO at the specified speed. That's what I'm keeping in mind as I organize the variables and memory from the testbed that I'm working with now into a truly modular routine. All the core really needs is a pointer and byte count. All of that "set the DAC parameters" stuff is only really done in the shell routines like "play sound ID 2" which just set up the pointer and counter, and load the PCM parameters into VERA_audio_ctrl and VERA_audio_rate.

I think the lowest-level API call should probably be stuff like "set_location"  "set_pcm_params" and "start_pcm / stop_pcm" I plan to offer a few higher-level front end routines that can reference a table of digi clip parameters which hold the data pointers, pcm params, sizes, etc, and you just tell it "play digi clip 4" and it handles calling the set_pcm_params type stuff for you, but those low-level routines should be exposed in the API.

Right now, it's pretty much an all-in-one program and I'm going to split it into a program and a library module. Once that works, I'll insert the library module into zsound and see about how to start integrating them with each other.

@kliepatschYou've definitely got me thinking about what sort of functionality beyond simple triggering of digi clips I might like/want/need to include to make the library more useful. I think it might make the most sense to just implement triggering one-shot clips for now and extend a little later. The ability to do clever things like splice clips together, do pitch sweeps during playback, loop a sub-section of the audio for X number of times, etc are all things I want to do, but I think it's most important to get the basics up and running first so as not to give myself some lofty goal that prevents me from ever getting enough done to share this thing. Scope creep is real, ESPECIALLY with me.

I like the approach of setting a pointer and say "go". I'd also think that doing some simple control of playback speed would be possible. But I'd be careful with that as that is moving away from lightweight (in terms of CPU) player more into synthesizer territory.

Volume control is definitely out-of-scope, I think, since that requires too much CPU power.

Honestly, I think the PCM functionality should just provide play a sample at given sample rate, address and length (perhaps an option to loop the sound).

That way, PCM will be useful for drum sounds and sound-effects without consuming too much CPU. But I doubt it would be sensible to use it for melodic instruments, given the YM and PSG.