As there's no way to change the bit-depth and sample-rate of the hardware itself, what would be the simplest way to do each of these tasks in software using the Axoloti Patcher?
I mean by looking at them as completely individual patches; one patch for reducing bit-depth and one for reducing sample-rate, to say, exactly half, what would each patch look like in their simplest form?
It depends, do you want to work in 8 bit or just to bitcrush?
In the latter case there are several objects that can do the job: math/quantize or sptnk/fx/bitcrusher, that cancel out the least significant bits.
If you want instead to work with real 8 bits you could use math/>> (bitshift right), the value you want to set in the box is 27-N, where N is the bit depth you want to achieve. At the end of your signal path you'll have to add math/<< (bitshift left) with the same number you set before, otherwise you'll hear nothing in the output.
However most objects are made to work with the full 32bit range, also there's no cpu benefit in using 8-bit, so it's better to use math/quantize.
As for the sample rate, you can use the sample and hold object provided in the library. There's a cheap one and a bandlimited one (that sounds strange, right?).
If you want to hear aliasing in your signal chain you can just put it after a sound source (like an oscillator) with no filtering.
If you instead want to downsample, you'll need some brickwall filter before the sample and hold (i suppose someone has already made such a filter. If you don't find it, you could simply use a number (like 2-4) filters in series.
And yes, i agree it would be quite cool to have some 8bit objects in the library.
Cheers mate, lol, you can imagine I did a facepalm as soon as you mentioned sample and hold 
Brilliiant, and yup, I'm wanting to be able to work in 8-bit so that all the processing that goes on in the patch is done in 8-bit rather than Axoloti's default 32-bit. Can't test it right now, but I'm pretty sure I understand what you told me, at least reasonably well anyway.
Right, so if I lower the sample rate of a sinewave by sample and hold and do the bitshift thing, I'll hear an 8-bit sinewave. If I then put that 8-bit sinewave through a low pass filter, I'll hear what an 8-bit sinewave sounds like through a 32-bit filter. So that's my next question; how do I make the filter do it's processing in the same reduced 8-bit fashion? I can't sample and hold a filter, or can I? You mentioned putting a bitshift at the end of the signal path, and that does sound like it's what I'm getting at, but wouldn't that just take the final audio and reduce the bit-depth?
So what I'm getting at is how would I make something like a filter do it's processing in 8-bit rather than 32-bit?
I want to put the 8-bit sinewave through the filter and to ensure that the processing it's doing over that 8-bit sinewave is also done with 8-bit precision. For example, if I could use sample and hold on a filter, would putting it before the filter or after the filter be doing it right or worng, or wouldn't it effect the way it gets processed at all?
Same with envelopes, they're obviously going to be done using 32-bit precision by default so I'd need to change that so that they behave the same as 8-bit envelope processing would.
And here's a thought; what about putting one before and after the filter?
And if it provided sound would it technically be doing what I'm wanting it to do?
I'm not completely sure about it, but it should be possible to use a regular 32bit 1-pole filter to process a signal that was previously bitshifted down to 8 bits, I think you'll have some problems with the 2-pole filters though, as they involve a division (and dividing something with small numbers usually causes big problems in the numerical world of microcontrollers).
If I were you I'd try to stuff a quantize object after each block and compare it with the bitshifted counterpart. I have a gut feeling that the first one adds a shitload of noise to the output (and I'd choose it for that exact reason), but maybe working with 2-pole filters in a low headroom environment will take you to the digital glitch Valhalla. Who knows?
I've actually never noticed the quantize object, nevemind used it, at least I don't recall ever seeing it but it does sound like it's what I need - so we'll see. You just gave me a lot of ammo to play with, so as soon as I put the Axo computer back together I'm going to turn-on my 8-bit fanboy mode and absorb myself with these 8-bit-making objects for a good while!
Some considerations (and some experiments)
You can calculate the increment "i" of a phasor in order to produce an "f" frequency saw wave, if you work at "fs" sampling frequency with a "b" bit depth with this formula: i = 2^b * f/fs
Of course the result is truncated to an integer.
So, if you work at 8bit depth, 48000 Hz sampling frequency, the lowest tone you can produce (if you add 1 at each increment) is f = 1 * 48000 / 256 = 187.5 Hz (which is between F#3 and G3)
Every other tone is a multiple of that. It sucks.
Using a 16bit phasor brings the smallest frequency down to 0.73 Hz (way below human earing), while the 32bit axoloti format takes that number to a dazzling 0.000011176 Hz
My point is: a true 8bit phasor is impractical to use. You can step it up to 16bit and could hardly tell the difference with 32bit, so unless you want to use intermediate bit depths (inefficient!) it's much better to stick with the 32bit axoloti format.
So, at least for oscillators, it's fair to bitcrush factory ones, you won't tell the difference.
As for filters: i tried making a custom 8bit - 4bit filter based on 1pole objects. It surely had a particular character to it, however it would only work at high frequencies and output dc at low frequencies. This could be due to truncation errors, however it's exactly what you'd get if you worked with a bitshifted regular filter, so again there's no point in making custom objects.
Hi @Sputnki
In many digital synthesizers, the audio rate signals were high resolution (16 bit or so) but the control signals were quantified (so that, for example, the pre calculated filter coefficients fit in a table).
Here is a k signal quantifier : Objects tiar/kfunc/quant
it allows to mimic zipper noise
About the audio rate aliasing / sub sampling, here is an "anti aliased" aliaser.
I mean that it is antialiased vs 24kHz and it simulates aliasing vs a lower frequency (a simpler S&H would alias against the desired frequency and agains 24kHz) :
Object: tiar/dist/SyncAlias
Yes, but what about videogame consoles?
Without going back to the times of computer buzzers used to make sounds, how was sound generated?
Now that i think about it, i feel "we" young generations (and i'm speaking for people who are in their 20s) tend to accomunate under the 8-bit category a variety of different sounds, generally associated with retro games, but in fact different platforms used different chips (the commodore c64 used the sid chip, the nintendo game boy and the nes had their own sound systems, ms-dos allowed to use external sound cards: https://youtu.be/BMmFcs-_4x4?t=3m48s )
I used to play with a A Y 3 8912 chip connected to a Sinclair ZX Spectrum back in the 80s...
As far as i remember it used frequency division (like early electronic organs) and the volume "envelopes" where something like 16 levels, it was capable of 3 voice polyphony.
So quantifying control signals for amplitude and pitch can help to replicate these aspects.
A trick to simulate "polyphony" on systems having a single 1 bit output (i.e. two levels) was to use very fast arpeggios of squarish waveforms. These are symptomatic of early console games.
Still haven't been able to play with this due to other things getting in the way, but regards the Commodore 64's SID, there's an interesting article about that on wikipedia which is definitely worth a read. People often wonder why it's so hard to get a computer to sound like a genuine SID. The 8-bit digital guys are often confused as to why it would be a problem to 100% perfectly emulate it.
The reason is because it's acutally an analogue chip, and it's imperfections in the design of the chip that makes it much harder to emulate than just modeling it's 8-bit aspect 
So if the chip is analogue, why does it sound 8-bit?
The answer to that is in this thread, the only reason a SID sounds 8-bit (I'm guessing) is because it's being controlled in an 8-bit environment. A SID chip therefore gives 8-bit fanboys the best of both worlds, 8-bit control of an analogue audio path.
Axoman Industries - Decoding the Myth!