The last couple of days were <sound> days. Malban hates sound and audio, at least programming wise. There was a crackling noise (especially under windows) when emulation started/ended/paused/breakpointed etc. – quite bothersome!
It turned out it had to do with SourceLines implementation on different OS’ and being 8bit or 16bit data. Anyways after much testing Malban arrived at the conclusion to dump the old sound code and do it anew.
The new code is based on a free library called “TinySound” (Link: TinySound) – the library was a bit altered to allow streaming from emulation and supporting the generated sound from PSG, but it was a nice time saver to have something to reuse. Now we also have some sort of “mixer” which allows overall better sound control (hehe – and two vecxi can have sound at once!).
Since Malban already was doing sound stuff he chose to tackle “samples”. In a quick view – the resulting Vedi-panel:
If you ask me, Malban got a bit insane by adding half a sound editing application, but whatever, if he likes it that much.
What you see is a gui to handle samples, handle means:
- you are able to record samples on the fly (on Malbans Mac he just talks to it after pressing the “record button”)
- you can also load (wav) sample files
- you can “cut” selections of samples
- you can play samples
- you can “normalize” samples (no range compression though)
- you can convert given samples to vectrex format (8 bit signed, one channel pcm)
- you can set a desired sample rate
And if that is not enough you can also output the sample as source code and include it in your own programs, example code is as usual provided (and also generated). The output to vectrex looks than something like:
I won’t present you with a screenshot of Vide running a sound program, that would visually be quite boring!
While doing the sample stuff, Malban also corrected some PSG sound generation (well, not the generation, but the “delivery” of the sound to the audio system) and some of the dac->audio emulation. Astonishing where false emulation can still be encountered.
False emulation, funny point, Malban also encountered an error which was quite hard to track down, but the gist of the solution (or the error) was, that a “CLR” assembler directive not only “writes” to a memory address, but also “reads” the address first! Now – usually that might not be a problem, but in the sample program Malban did a
“clr via_shiftreg“. And that being a “read” not only triggered shifting, but it triggered shifting BEFOR clearing the shiftregister. Doing that at exactly the wrong place in your vectrex sources leaves you with some “dirt” on the screen! (Oh well, that is emulated now…)
Another emulation fault, … I mentioned earlier that there are different vectrex “generations”… doing samples Malban (re-) discovered, that the newest vectrex generation has considerably lower sample sound. When Malban gets time, he will tie a volume control to the generation emulation…
A couple of other bugs were also fixed,… and Malban still has some in his pipeline …