726

(65 replies, posted in Sinclair)

Huh? Who asked that where? Everybody knows that ZX Spectrum CPU is a TMS1000 big_smile

727

(21 replies, posted in Sinclair)

Maybe one patch with "coder" tempos (0x100, 0x200, 0x300 etc) could be useful, too?

728

(14 replies, posted in Sinclair)

So, what's the magic technique behind it? How are you interlacing the music with the graphics?

729

(14 replies, posted in Sinclair)

Well, in any case I do like it a lot. Congrats.

730

(21 replies, posted in Sinclair)

Was it this one, by any chance? Or was that for Savage?

In any case, retrieving the note table should be trivial. 25 bytes into the player there's a pointer to the music data, the note table is sitting directly before that address and is 54 bytes long.

Edit: Beepola 1.08.01, at offset 0x3a72c0 wink

731

(135 replies, posted in Sinclair)

Oh, I better hurry up with turning this into a proper engine then, eh? wink

732

(65 replies, posted in Sinclair)

Hehe, seems you managed to post precisely at the moment when I moved my post to the "next gen engine ideas" thread yikes

733

(14 replies, posted in Sinclair)

Hehe yeah I saw sq was on the payroll big_smile But the overall idea/design was your idea, wasn't it?

734

(21 replies, posted in Sinclair)

I'd suggest putting some 1 and 2 tick speeds in there as well. Some people are crazy for high speed Tritone abuse, and they're still sticking to the old XM converter precisely because those high speeds are inaccessible in Beepola.

Btw, would it be possible to apply your alternate SpecialFX note table as a patch, too? In combination with the Tritone speed patch it might make for a nice "FrankT's Modded Beepola" release...

735

(14 replies, posted in Sinclair)

woooooooooooooooo! Super nice. Reminds me of some skrju prods (which I adore very much).

736

(135 replies, posted in Sinclair)

Discovered a new trick while working on Houstontracker. Consider the usual pulse interleaving with variable duty cycle:

   add hl,de
   ld a,b          ;b = duty
   cp h
   sbc a,a
   out (#fe),a

   ;blabla same for 2nd channel

Now, as you know, we can add a "SID-style" duty cycle sweep by incrementing the duty when the add counter (HL) overflows.

   add hl,de
   ld a,b          ;b = duty
   adc a,0
   ld b,a
   cp h
   sbc a,a
   out (#fe),a

So far, so good. Now for the new stuff, we'll add an extra parameter that will be XORed against the duty setting on every sound loop iteration.

   add hl,de
   ld a,b          ;b = duty
   adc a,0
   xor c           ;c = additional XOR parameter
   ld b,a
   cp h
   sbc a,a
   out (#fe),a

This will produce some very interesting timbres! A primitive form of square wave FM, if you will. The result tends to have some aliasing noise (because the harmonics will cross the Nyquist limit if I understood this correctly), but I suppose it could be filtered out with the low-pass filter algorithm I was talking about earlier.

Now I actually went another step beyond this. Since I'm using a split timer update as usual, I have time to add an offset to the XOR paramter (C) every 256 sound loop iterations. Now this is a double sided sword - it will act nicely as a third FM OP, but only if the value is 1/256th of the base frequency used. When it is not, then the results will vary from "interesting" to "ouch my ears".

The attached .tap demonstrates both techniques. The first pattern starts with a simple duty cycle sweep and the additional XORing disabled, followed by XOR parameters of 8, $10, $20, $40, and $80. The second pattern starts again with regular duty cycle sweep and XOR 0. Following this, the XOR parameter is raised by 1/256th of the base frequncy once per 256 sound loop iterations, and following this the XOR parameter is raised by a fixed value (8 in this case) every 256th iteration. This is then repeated but with the initial XOR set to $80.

Don't ponder too much about the code in the .tap, there is some additional leftover stuff from an earlier experiment.
Anyway, I'm busy with HT at the moment, so if someone wants to pick up this trick in the meantime, be my guest wink

EDIT: Realized I posted this in the wrong thread, moved for clarity.

737

(21 replies, posted in Sinclair)

Well, I guess you could use just about anything you wanted to.
In the original XM converter, the speed value is calculated as follows:

speed=(int)(2500.0f*(float)tempo*(3500000.0f/1000.0f/153.0f)/(float)bpm)+256;

where "tempo" is the number of ticks per row if I understand correctly. So, eg. for 120 bpm @ 8 ticks you'd get a value of 4069.

Heh, that's fine with me if we get a lot of OctodeXL tracks wink

Ok, so Savage newcore is out and all Octode mods are in. I'm fine with that. I'd also throw out LSengine - while not super popular, MB and me have been using it quite a bit in the past. ZX-3, I doubt anyone would use it considering the interface. (I have used it once, it's awful). There'd be an argument for allowing ZX-7, considering it's just been added to 1tracker. On the other hand, Jan once told me that sales figures were into the 4-digit numbers, so even though nobody uses it today, it can hardly be called an unpopular engine. So I would still vote to disallow the entire ZX- family.

739

(65 replies, posted in Sinclair)

Good news, with Tufty's help I've finally sorted out my converter's issues with XMs created with OpenMPT. It should even work with OpenMPT's non-standard format hacks (no compatibility export required).

All converters at https://github.com/utz82/ZX-Spectrum-1-Bit-Routines have been updated. Just grab the master.zip if you want to update your local engine collection in one go. You'll get some extra crap you probably don't need, but deleting those still beats downloading all the packages seperately, I think.

740

(65 replies, posted in Sinclair)

Hmm, seems the bugs in the quattropic converter have finally vanished.

In the meantime, I've updated the nanobeep engine. The player has now been reduced to 77 bytes, and "light" (73B) and "ultra" (56B) versions have been added. "Light" has somewhat reduced sound quality, but otherwise still the full feature set. "Ultra", on the other hand, is cutting some corners, ie. no border masking, no click drum, and no looping. Also, there was a bug in the converter which has been fixed.

Uh, well, yeah, I think I promised to do a HT2 compilation for the HT2.10 release already yikes I'll put this on the to-do list for HT2.20, which I hope to be releasing some time this fall.

Regarding the bug, I faintly remember something about this. Think I may have fixed the issue in the latest beta builds, so grab that from github to be sure.

@Shiru: Well, Follin's engine is virtually unusable, and I've used ZX-10 excessively (and everybody else hates it). But, I see your point and agree. tBeepr and Beep Tracker would also fall under the "age limit", so yep, best use an "excluding" list.

@Tufty: Hehe, that'd be a pretty damn long list by now wink Think it's indeed best to do a list with disallowed engines, and for the rest direct users to http://randomflux.info/1bit/viewtopic.php?id=25. (I have to check if that one's actually up to date though).

@garvalf: There once was a -rather successful- Beeper BotB battle. But it was a one-time thing, quite sure I'd have a hard time convincing puke7 to host another one any time soon considering how packed the battle schedule is nowadays. Anyway BotB does a good job of drawing attention to 1-bit music either way, seeing how zxbeep is now one of the most popular formats on there aside from the "big ones" (nsf*, s3xmodit, wild).

Ok, I'll try to make a start on "the" list then.
The following engines would be disallowed:

- FuzzClick (Special FX/Orfeus)
- Huby
- Music Studio
- Octode (should that include the XL, 2k15 and PWM variants?)
- Qchan
- Phaser1
- ROMbeep
- Savage (should include newcore imo)
- Tritone
- Wham! The Music Box

Any others I forgot? What about ZX-7, -10, and -16? ZX-7 has been used quite a bit in the old days. For the rest we had the Tribute compilation, so those engines have had their spotlight already. I think we might also want to give a "recommended" list, which should include Phaser 2/3, fluidcore, and perhaps quattropic.

Edit: Squeeker and BT'man need more love, too, imo.

743

(2 replies, posted in Sinclair)

Yay, garvalf music topic ftw! Nice cover, mate wink

That's a very reasonable idea. However, for the time being my motivation to organize another compo is near 0. Perhaps we could collaborate with the Spanish folks from Culturachip, though. Like, handle the submissions through them, but use our more transparent approach to voting. I mean the main idea of the last forum compo was to attract more people to the forum, and it clearly flopped (not just) in that respect. And I don't think that would change with a different ruleset.

Regarding allowed engines, I think the easiest would be to draw the line at Phaser2, eg. all engines released prior to that would be prohibited. The only drawback would be that this would exclude Stocker. (I've got a -somewhat conceptual- Stocker project in the works, though wink) What do you think?

So the honour of submitting the first HT2 track to BotB goes to garvalf! *applause*
A very nice tune, congrats! And thanks for promoting wink

Seems I won't be submitting to Decadent Decade after all. I wanted to do a bunch of Channel F covers, but I just can't find the time to do them.

746

(135 replies, posted in Sinclair)

Cheers wink Hehe, maybe not to my creativity, but unfortunately there are quite some limits to my maths skills, which is providing some major stumbling blocks lately. Trying to read some stuff on DSP at the moment, mostly not understanding the slightest bit about the mathematical theory of it. Wish I could just go into recluse and just study that stuff for a few years.

747

(135 replies, posted in Sinclair)

Thanks mate!

Seems I omitted part of the formula for the low-pass. It should be

y[i] = y[i-1] + a(x[i] - y[i-1])

In any case it's a lovely algorithm, because with the multi-core digi synthesis I'm using lately it can be implemented without using any extra registers.

748

(135 replies, posted in Sinclair)

Cheers guys! Yes, I'm pretty sure there's more that can be done with the beeper. I'm just kind of running out of (feasible) ideas again.

Right now I'm doing some tests with dynamic duty cycles, but that seems to be surprisingly unuseful. I mean you can do some nice chords with it (Earth Shaker style), but other than that implementing an extra counter for the duty cycle seems to have little advantage over just incrementing the duty setting once per sound loop, like I do in Houstontracker. The extra registers needed for full duty cycle control can be put to better use elsewhere imo.

One thing I'm still pondering about is the Jan Deak's buffer based method. I mean it's blazingly fast, but what uses could it have besides generating a truckload of pin pulse channels?

Also, Shiru, did you get any further with your Fuzz Click/Music Box hybrid?

749

(7 replies, posted in Other Platforms)

Ah, didn't know April Fools revolves around fishes in France. Where does that tradition come from?

750

(135 replies, posted in Sinclair)

A new breakthrough! Just implemented a low-pass filter. Check out the attached .tap - first pattern is without the filter, second with low-pass enabled.

The low-pass is implemented with this simple algo:

y[i] = a(x[i] - y[i-1])

where y is the actual output volume level, x is the unfiltered output, and a is a (time-related) constant, in this case 0.25. Using a = 0.125 gives better results, but I'd need to implement more volume levels to use it.

I tried implementing a high-pass, too, but so far no luck on that, because the algo for that can produce negative values (unlike the low-pass one where the result will always be >=0). The high-pass algo I have is

y[i] = a(y[i-1] + x[i] - x[i-1]) 

Any idea how to modify it so it'll always produce positive results? I could probably invert the output but that'd be too slow I think.

EDIT: Nevermind, got it. The current implementation is ugly as hell, but hey, it works wink