651

(21 replies, posted in Sinclair)

I'm afraid an ABC/MML converter would be very difficult to pull off. A note/sequence importer from XM or perhaps MIDI would be easier.

Shiru, yes, good point. I still want to add some configurability right from the start though, because I want to improve my C++ skills a bit, too.

In any case, it'll take a while before I have anything to show, as I'm planning on taking a break from coding next week.

652

(20 replies, posted in Sinclair)

You're right, envelopes take precedence over channel volume, not the other way around. Sorry 'bout that...

For the rest, it sounds like some good ol' bugs... I'll look into it, perhaps tomorrow if I can find some time.

653

(20 replies, posted in Sinclair)

Cheers wink Channel volume overrides the envelope. Multi-point envelopes are taken into account, though there's a chance they aren't parsed correctly, so check the asm in case something sounds fishy.

654

(21 replies, posted in Sinclair)

Thanks mate wink

Any more thoughts on the language thing? I've already worked out a rough draft for the implementation. Think I'll do the parser in C++ after all (since I can't really be bothered to learn yet another language atm, and I don't feel like using Perl either). The parser will be customizable via config files, which will allow for creating extra commands and so on. Well, we'll see how that goes, I really have zero experience in writing such a thing.

655

(20 replies, posted in Sinclair)

Whoa, dafuq did that happen? Yeah, the xmkit version from zbmod is not compatible with xm2squeekerplus. At the moment xmkit is still a rather dysfunctional mess, and a prime example of a bad programmer interface. I though "Oh, I'll quickly make a library so I don't have to rewrite the whole XM conversion code every time" but I greatly underestimated the amount of work involved, and lack of experience didn't help either.

Anyway, I've added the required files to the repo. Thanks for reporting!

656

(21 replies, posted in Sinclair)

After studying the ABC standard a bit, I'm actually leaning more towards defining a new standard. ABC is very strongly focused on score notation while offering very little in terms of timbre control. It does actually provide most of what we need (there are tools for creating user-defined commands, macros, etc), but ultimately using those would cause quite a mess. Besides, it seems inconvenient for parsing. Furthermore, I kind of prefer having a traditional pattern structure, rather than long strings of commands.

In any case, using calls/macros is a good idea.
At the moment, I'm thinking something along these lines

:order               // "order" would be a reserved keyword.
^intro               // names could be freely chosen
(loop)
^1                    // or short-handed by supplying only a number which will be expanded depending on context, ie. this will look for "pattern1"
...
// end directive is optional, as each block end can be determined by following :

:intro
A=a1  B=r  C=c3  D=e3  CFG=^1,^2,^3  FX=none        //note length fixed, ABCD=operator/channel, number after note name denotes octave
.                                                                                      //no changes in this row
A=a2  DUTY_A=#20
.
A=a1  B=a1-#1                                              // # denotes usage of immediate (hex) value instead of string literal
A=#800 FX=^1

:cfg1
GMIX=OR        // so alternative notation for phaser would be: GMIX=#b0

:cfg2
PHASE_AB=#1000
PHASE_CD=#0
DUTY_A=#40
DUTY_B=#40
DUTY_C=#20
MIX_AB=OR
MIX_CD=XOR

:cfg3
DUTY_D=#20
SID_A=OFF
SID_B=OFF
ES_A=OFF
ES_B=#1

:cfg4
GMIX=XOR

:fx1
A=C2
.
(loop)
A=c3 CFG=^4
.
A=c4 CFG=^1
.

Admittedly, it's still quite a mess, and nothing more than a rough draft.

Regarding independant patterns per channel vs multi-channel patterns: There are certain benefits to having independant patterns per channel, but I think that with Phase Squeek, it would make things super messy, both for editing and for parsing.

657

(21 replies, posted in Sinclair)

Cheers guys wink

I quite like the idea of using a human-readable text interface. And yes, from the looks of it I would definately prefer ABC over MML. Have not looked much into either of them though tbh. In any case I think it's best to use an existing standard rather than creating our own.

The main question is if and how certain aspects like timbre settings (in case of Phase Squeek, that would be duty, phase, coupling modes, SID enable/disable, Earth Shaker setting, noise enable/disable, noise pitch) and the whole FX table business. I think we'll be making heavy use of the I: syntax ("Instruction"). But I really have to look more into the ABC standard to see how it could be done. Ultimately it should be done in a way that is not only usable for Phase Squeek, but also for other "un-trackerable" engines. So let's take some time to brainstorm about this - suggestions are very welcome!

Btw perhaps a thing worth noting, unlike with Tritone FX, the FX table syntax in Phase Squeek is almost exactly the same as the pattern syntax, with only two minor derivations.

658

(13 replies, posted in Sinclair)

Working on speccy stuff? Blasphemy! big_smile

The problem is, drums > 5 can't be entered in Beepola iirc. I'd think that's a hard limit encoded with the engine somewhere, since with other engines Beepola quite happily accepts higher numbers. So, basically it just might be a question of finding that number and changing it. But yeah, chances to find it in the binary are probably not exactly great.

659

(21 replies, posted in Sinclair)

I said I'm not turning this into a full engi... ah, damnit!
Lo and behold: Phase Squeek, aka TOUPEE, the Totally Overpowered, Utterly Pointless Extreme Engine

Phase Squeek is ZX Spectrum beeper music routine with a rather complex synth
core based on an unholy fusion of Shiru's Phaser method with zilogat0r's Sqeeker
method.

The engine can be configured in different ways. In it's standard configuration,
it sports two channels, each using two operators coupled together. However, the
operators can also be decoupled and act as independant channels (so up to four-
voice polyphony is possible). Or you can couple both standard channels together
to form a single, all powerful voice.

While operators are coupled, the following settings can be customized on each
channel:

- frequency (independant dividers for each operator)
- duty cycles (independantly for both ops)
- operator phase 
- coupling method (XOR|OR|AND - OR effectively decouples the operators)

Additionally, channel 1 supports the following settings:

- SID-style duty cycle modulation (independantly for both ops)
- Earth Shaker style duty cycle modulation (independantly for both ops)

Channel 2 instead offers a noise mode for operator 1.

All settings can be updated not only between notes, but also on a per-tick basis
via effect tables.

Last but not least, two interrupting click drums are also available.

source code
download (no XM converter included)
UPDATE: demo tune on soundcloud

Some notes on the demo track (also Included in the download package):

- The intro and first part demonstrates the 4-channel mode, in which the engine basically acts as a Squeeker Plus clone.
- In the second part, operators 1 and 2 are linked to create the phasing bass, while channel 3 and 4 make some use of the fx table feature.
- In the first half of the third part, various different configurations for the two-op mode on ch1 are demonstrated, including the SID and Earth Shaker effects. The other channels are silent save for some occasional noise (this time without using tables, hence it sounds more rough)
- In the second half of the third part, the single channel mode is demonstrated with 3 and 4 operators in use, and various different configurations of phase, detune, coupling mode and so on.

660

(135 replies, posted in Sinclair)

So I was curious whether it's possible to combine Shiru's Phaser technique with zilogat0r's Squeeker method. Turns out it works surprisingly well!
The downside is of course that the sound is somewhat less clean than with proper pulse interleaving. But there are various benefits to having only one OUT in the loop. It's not only faster, but also there's no need to keep the cycle count down because there's no need to render multiple volume levels.

I'm not motivated to turn this into a proper engine at the moment, since it would be impossible make an XM converter for it anyway. But if anyone wants to play around with this, please do!


EDIT: Added the good ol' adc a,n SID and Earth Shaker effects on channel 1. Because, why not. This brings the total of configurable parameters for the first channel up to 10:

- frequency OP1
- frequency OP2
- duty OP1
- duty OP2
- SID on/off OP1
- SID on/off OP2
- ES duty modulation OP1
- ES duty modulation OP2
- Phase
- Mixing method (xor | or | and)

All nicely aligned to 224 t-states big_smile

The next step could be to add some modulators which would update the parameters once per 256 loops or so. Or maybe digi rendering with lo-pass... ehhh... I've got a strange feeling this is getting outta hand... yikes

661

(13 replies, posted in Sinclair)

introspec, I meant because Follin player is Beeper + AY drums, and yours will be AY + Beeper drums wink

abrimaal, nice work, and thank you for sharing the sources (and welcome to the new 1-bit forum, btw). Indeed, it is always a problem to find a way to edit music for new drivers. That's why I'm now trying to create a C++ library for extracting data from XM files. Ideally, this would allow for very quick creation of XM converters, but at the moment it is still too inconsisten and instable to be used productively.

In case of doombass, perhaps FrankT could help unlock the extra drums? He's done quite a bit of patching in the Beepola code, so he might have an idea where the relevant parameter for the limit of drums is hidden. Frank, where are you man?

EDIT: Couldn't resist trying to implement the Buzzer effect. Voilà.

662

(13 replies, posted in Sinclair)

Cheers guys wink Yes, Abrimaal's work actually renewed my interest in doing this.

introspec, so basically like a reverse Tim Follin player? big_smile

663

(13 replies, posted in Sinclair)

Crossing another item off my to-do list, which has been on there for an awful long time.

This is just a little experiment to demonstrate that it can be done. I have no intentions of developing this into a full sound driver at the moment, mainly because I'm totally sick of writing these XM converters.

The beeper part is basically a simplified version of Squeeker with 3 channels and variable duty cylces. The AY part is very basic, just tones and software-generated envelopes. Noise is certainly possible, I was just too lazy to implement it. Perhaps buzzer could be done as well, after all it's just copying the values from the envelope register to a volume register, right? Anyway, check out the source code for inspiration, if you like.

664

(20 replies, posted in Sinclair)

Thanks mate, glad you like it!

665

(17 replies, posted in Sinclair)

For me, even having to fiddle with FM or SID is already too much. I love the sounds these things make, but every time I try to compose something on these I get lost in the endless realms of sound design hmm

666

(20 replies, posted in Sinclair)

No fancy samples and sh*t this time - just finally finishing off a project that has been on my to-do list for the longest time: A remake of zilogat0r's Squeeker engine! Various cool features added, quoting the readme:

- 4 tone channels, mixed PFM/PWM synthesis
- 2 interrupting click drums
- per-tick duty cycle envelopes
- channels 1 and 2 can play fixed-pitch noise instead of square waves
- channel 4 can use a fast pitch slide for drum simulation
- mixing at approx. 9511 Hz.

I did make an XM converter for this one, but it is very rough code (as is the whole engine, it's got character, to say the least) and needless to say, it does a rather poor job of simulating the sound. Awaiting your bug reports, in any case.

download (XM converter included)
source
demo tune

667

(17 replies, posted in Sinclair)

I'm considering putting together a seperate sample pack at some point. Though at the moment I really can't be bothered. Those endless searches through vast sample libraries is what turned me away from making (PC-based) sampled music many years ago big_smile

668

(17 replies, posted in Sinclair)

Haha, words can't describe what a massive pain in the a*** this was.
I didn't follow your suggestion of including some samples/instruments after all, because hopefully it should just work with any random sample out there now. Even random MOD imports should theoretically be reasonably safe now.

Yeah, the mobile view uses a different css, haven't touched that at all.
Does the main menu work on mobile for all of you? Because it sure is broken when I set a small viewport in Firefox.

670

(17 replies, posted in Sinclair)

Updated the xm2zbmod converter. Fixing the relative sample offset bug was one of the hardest things I've done in recent times, certainly more difficult than the zbmod engine itself.

The new converter brings some changes, namely:

- 16-bit samples are now supported.
- Relative sample offsets other than F-6 (+29) are correctly handled now, as long as they're positive (ie C-4 or higher).
- The note range is no longer fixed. It's still 4 octaves, but the lower and upper limits will vary slightly (at most +/- 1 octave). You can run xm2zbmod with the new option "-r" to see what the actual range for each used sample is.
- You can now supply the option "-i <filename>" to convert a module that isn't named "music.xm".

I doubt the converter will be free of bugs yet, but I'd say it's at least ready for some beta testing.
Download is at https://github.com/utz82/ZX-Spectrum-1- … p?raw=true as usual.

My girlfriend pixelled another background thingy. I think this one looks even better, and unlike the previous one, it doesn't flicker (at least not as much) when scrolling.

With this background, I should probably make some tweaks to the header proportions and such. Will see about that later. Also, still want to get rid of all those shades of blue, but there's a truckload of settings for that and I haven't come up with a good, consistent new scheme yet.

Generally speaking, I don't want to go too Spectrum-y with the layout. I know we mostly talk about Spectrum here, but I'm very much in favour of broadening the scope a bit, ifyouknowwaddamean.

Alright, fixed the floating links. Not the most elegant solution but I've had enough fiddeling for today.
Ok then, I'll keep the background for now, and we can decide later if we stick with it for good or not.

Ok, some more tweaking done. Not sure about the tiled background, it flickers like hell on my browser. Also I still need to sort out various bits and bobs here and there, like setting background for those "floating" links. Anyway, what do you guys think so far (especially about the background)?

I also still don't understand why the mobile view is broken. The code for responsive design in the css is there, but it doesn't seem to be triggered properly. Perhaps the error is in the PHP code, which means chances of me finding it are low.

So I've finally managed to implement this header image. Thanks again to PROTODOME for the awesome design!

Hope it works ok for everyone, It was quite a hassle to fiddle this into the layout. I'm not entirely happy with it yet. For one, I would like to bring back the sub-heading text ("complex music from simple devices"), preferably without adding it to the image itself. Also, for the future I think styling the forum a bit more appropriately would indeed be nice. Not sure if a tiled b/w background wouldn't be too busy, but I'm gonna try some things once I  find the motivation to fight with the forum css again.

Yes, the guy surely has talent. And indeed I find the sound of the zeta engine to be quite pleasing as well, and contrary to what he's said, it doesn't sound bad at all on contended machines.