Search options (Page 31 of 41)

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

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...

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

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

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

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.

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.

@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 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.

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 ) What do you think?

Cheers 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.

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?

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