Topic: Mewtone (WIP)

https://drive.google.com/open?id=0B-KEe … XFDQzVmVm8

Been working on this on and off this week, it's basically a Tritone-like 1-bit engine. 4 channels of the same type, identical (albeit more pronounced) drums, similar data format

Was considering the idea of maybe having something finished by Sunday for Utz's compo but at this point it is probably safe to say that it's not happening. As such, it's more of an illustration for this post, i.e. the fact that the 8T alignment rule doesn't always seem to hold even if the loop is a multiple of that (two iterations of 160T each in this case). The 'contention vibrato' I think is evident esp. on high notes

There's a few more problems with it, like e.g. how the 'quiet' drum noise setting became just too quiet now, I'll probably revisit that part later. I'm not good when it comes to PC programming so can't say anything about converters and whatnot. Perhaps I'll figure something out eventually

I had another engine that I wanted to show, with 2channels of - for the lack of a better word - 'realtime' saw waves but it is even less finished atm, particularly the data processing routines became bloated as fvck despite the fact that it was originally intended as a rather simple engine feature-wise

Re: Mewtone (WIP)

Hmm, sounds pretty good to my ears wink I especially like that drums and tones are very well balanced, volume wise.

And yes, the "code" part of the compo will indeed most likely not happen due to lack of entries. So I think I'll just release my own entries one by one over the course of the coming week.

I'm curious about your "realtime saw wave" engine, too, sounds like a very interesting concept.

Re: Mewtone (WIP)

the sound is very smooth and nice for me too. Can't wait to get access to this new engine! wink

Re: Mewtone (WIP)

Sounds good smile

Re: Mewtone (WIP)

Cheers guys. For now I continue to tweak/debug the routine when I have the time. Some gritty details-

It turned out that the sound got somewhat worse with the newer 'optimized' sound loop used in the test .SNA. In particular, there's a kind of annoying tingling-buzz noise, or something, in SpecEmu, qualitatively reminiscent of Sample Tracker. Reverting to an older version of the loop (2 x 5T slower) seems to help reduce that to an extent. OTOH I'm not perceiving much difference between the two with other emulators like Fuse or Spectaculator. Is it SpecEmu acting up (which I doubt tbh) or the szzt is real? Could it be caused by asynchronous channel updates in the newer loop? I'm not really sure what to make out of it. In case anyone's curious, [new (noisy)] [old (better)]

There's something else I don't quite understand the implications of. This engine has the channel counters updated twice less often than Tritone does (frequency values are 12bit in both cases, although not in the test .SNA version), but it attempts to 'make up' for it by having the corresponding frequencies multiplied by 2 before they are used, so in the end you get about the same note. Hopefully. I have a feeling that something inevitably gets lost in the process - some sort of granularity maybe - I can't quite pinpoint what it is. As a matter of fact I'm using the 12bit Tritone format with just minor modifications, finding it rather convenient. Hope it doesn't prove detrimental / hit me back in some way much later like it tends to happen with these things

I've found that the more correct way of doing the 'Tritone comparison' in the sound loop is LD 'A,DUTY: CP H', i.e. backwards. The way it is originally I guess you could say the duty cycle is actually increased, starting from 50%, together with the value, despite the fact that it is perceived as 'thinner' sound. Normally this isn't a problem, if not for one thing. A muted channel outputs a '0' at all times, whereas what is perceived as '0's of the playing channel is actually represented by '1's in the output. This in turn leads to a kind of interference/noise of its own wherever the two overlap. It's barely noticeable in Tritone but here it (used to be) more evident, for whatever reason

Re: Mewtone (WIP)

Ah, the mysteries of the Speccy beeper. I really don't have a clue what's going on here, maybe introspec can shed some more light.

Regarding the duty comparison, actually the other way around (ld a,h, cp duty) is equally correct. Why? Because if H=0, then H-duty will result in carry. Which means the channel will output 1 when muted.

Re: Mewtone (WIP)

Hmm, yes, I was neither right nor wrong with that part. To clarify, the problem comes from the fact that: 'a muted channel always outputs a 0', i.e. that H isn't actually zeroed at rest notes, only the duty values/frequencies (less special-case code). Doing the comparison backwards sets this specific situation straight with no additional code. Apart from that, both versions are legit and interchangeable

Re: Mewtone (WIP)

What I meant was that it doesn't matter if you define silence as 0 or 1, because as far as I understand the beeper has a heavy DC offset, ie. it doesn't output 0V in either 0 or 1 state. So neither 0 or 1 will produce true silence in the actual meaning of the word.