Search options (Page 12 of 41)

song_editor.h:979

if(key>=SDLK_KP_0&&key<=SDLK_KP_9)

That looks like a bug to me, because SDLK_KP_0 = 0x40000062 and SDLK_KP_9 = 0x40000061.

Holy cow, that's fantastic news. Congrats Hikaru on pulling this off. Can't imagine how much of a hassle it must've been to work out the timings.
Now what we really need is the source code and documentation of the song format...

Fantastic, just what I need! I briefly looked at LPC before, but was like "meh, too much maths". But in recent months I've been working on my math skills so I might be able to tackle this now.

For if we'd want to go full PCM instead of PWM (3-bit should be possible and give quite decent speech quality), I recently read that dictionary based audio compression apparently works well for low res audio, and was used quite a bit in old Amiga demos. So, chop up the audio into blocks of, say, 8 samples, create a dictionary of those, (optionally) massage dictionary a bit to eliminate similar samples, replace audio stream with pointers to dictionary. Simple enough to decode imo.

Regarding microsamples, there is one issue with fixing the length to 256 samples. You essentially end up with 3 different use cases:
- vowels: arbitrary length, must be looped
- k, t, p etc: one-shot samples with fixed length
- s, th, kh: noise, arbitrary length.
The main thing here is the noise ones: If you use a 256 b looped sample for it, you cannot control pitch, because it won't sound like noise for anything but the lowest stepping speed.
So to me it seems like the best approach is to detect the "type" of sound beforehand, and just synthesize the noisy ones, and perhaps the plosives as well. That's how I ended up with "hey, if we can synthesize the vowels as well, then we don't actually need samples".

Oh, I like the sound of that. Will be a few days before I get around to trying it out, but I'm already drooling over the description, hehe. Percussion is still a problem area in beeper imo, so great to see advances in that field.

Ha, neat. Good timing, too: Recently a new developer started contributing. He fixed the play icon (didn't even remember there was one lol) and, to my utter amazement, managed to squeeze some more bytes from the compressed font.

You need to qualifiy the path where tilp2 is installed, then. You can use the Tab key to auto-expand names. So, if your tilp installation is in C:\My Programs\tilp\, you do something like

My<Tab>\ti<Tab>\tilp ti84+ ...<Enter>

I think you have the very old version of TiLP from http://lpg.ticalc.org/prj_tilp/. (Unfortunately they haven't updated the site in like, a decade.)
Might be better to get a more recent one from https://github.com/debrouxl/tilp_and_gfm/releases. first uninstall the old version and the Gtk runtime. Second, you will probably need to install the required version 2.24 of Gtk manually. You can get the installer here. After installing the new TiLP, you may or may not need to run Zadig again, as described in https://github.com/debrouxl/tilp_and_gf … DME.win32.

Good writeup, introspec. I'll add that in addition to the pin pulse method, the Squeeker method also allows for some deviations in timing, and both of these methods still work (albeit with noticable degration of sound quality and of course frequency range) at fairly low update rates, as demonstrated by nanobeep.

So as I was just about to fall asleep last night, it occurred to me that it's possible to implement a low-pass filter with variable cut-off, without using multiplication.

Assuming an engine that supports multiple volume levels per channel, the idea is as follows:

current_volume = 0
max_volume_delta = x

loop {
  new_volume = n  // use whatever standard method here
  if abs(current_volume - new_volume) > max_volume_delta {
    if new_volume > current_volume {
      new_volume = current_volume + max_volume_delta
    } else {
      new_volume = current_volume - max_volume_delta
    }
  }
  ... // output sound 
}

This could potentially be used to add filter envelope emulation to existing synthesis algorithms such as Phaser. The question though is how to efficiently implement that big fat nested conditional.

It's fairly easy for a saw wave generator, because we can assume that when (abs(current_volume - new_volume) > max_volume_delta) is true, then (new_volume < current_volume) is also true for a real-world implementation (in other words, max_volume_delta is never exceeded on the rising edge of the saw). So that's what the attached example demonstrates.

Old version of 1tracker maybe?

Qchan is pin pulse so in theory it should work. However, it may be too quiet to be properly audible, or maybe the pulses will be too short to actually switch the piezo. Could also be that the volume envelopes don't quite work as intended because some piezos have a pretty strong overshoot. Nevertheless, it's worth a try methinks. Same goes for the Octode family (except Octode PWM and Octode2k16, those are pulse interleaving), Stocker, Huby, and BuzzKick.

Engines using the pulse interleaving technique (Savage, Tritone, many others) most likely will not work on piezos. Pulse interleaving relies on inertia of the speaker cone, which is practically absent on piezos. So only engines using OR mixing (Squeeker, Squeeker Plus, PhaseSqueek, Squat) and maybe pin pulse engines will work.

That said, VZ also has tape out, right? I'd focus on using that for sound instead of the piezo.