- The [loop] command is now [LOOP], for consistency since all commands are uppercase in MDAL.
- // comments should now work everywhere.
- Block comments (/* ... */) are now available.

A special note about the new NOISE command - the current implementation is a bit awkward. Basically, when you enable NOISE, you must also set PSCA1=0 and PSCA2=0. Likewise, when disabling noise, you should set PSCA1/2 to a value of your choice. You might as well ignore the noise command and just set PSCA1=$cb and PSCA2=2. The problem exists because I didn't forsee this particular use case where an internal masking command (SET_IF) should overwrite an existing value rather than ORing to it. I'll need to implement another config flag to avoid this mess but this might take a while.

Changes:
+ Ch1/2 post-scalers are now pre-scalers
- Old (slow) Ch1 duty mod removed
+ New Ch1 duty mod, can be heard in the intro (using osc sync method - runs a bit too fast for my taste, so it's not terribly useful in any case)
+ Ch1 noise support
+ Ch2 duty mod w/ custom sweep speed, can be heard in the interlude (using Shiru's implementation, but with a variable counter increase every 256 loops instead of constant increase every loop)

Since you were wondering, I'll try to give a better explanation of what the effect settings do.

The basic thing you have to understand is that the first two channels each use two semi-independant oscillators. Semi-independant because they share the same frequency divider ("A" resp. "B"). The output of the two oscillators is combined using the MIXA resp. MIXB method. This works the same way as in Shiru's Phaser engines (namely Phaser2/3, Phaser1 has only XOR mixing).

Before the mixing, a pre-scaler is applied to the first oscillator (PSCA1/PSCB1). This prescaler will shift output from the first osc up or down by one octave. After mixing, a post-scaler is applied to the combined output (PSCA2/PSCB2), which again shifts one octave up or down. This feature will probably be removed in favour of a second pre-scaler in the next version, because it's not really necessary (I was originally afraid that tone range would be insufficient, but that seems to be not the case).

On channel 1, there's also the duty modulator (DMOD), which should theoretically do what the "Duty Sweep" effect in HT2 ch2 does. However, the implementation is so slow that the effect is barely noticable - I'll probably replace it with something better in the next version as well.

Last but not least, there's the phase offset (PHA/PHB). The value you enter here is used to initialize the second oscillator before the sound loop (the first osc is always initialized to 0). If you don't use the pre-scaler and set MIXx=xor, this will essentially act as a duty setting (4xx/5xx/6xx in HT2). Setting PHx to $1000 will give a 50:50 square wave, $800 would give 25:75. There's no point in using values >$1000 unless you have PSCx2 set to "down" - in this case, $2000 will give 50:50 duty. Likewise, if PSCx2 is set to "up", $800 will be the max.

Channel 3 on the other hand has only one oscillator. PSCC is a post-scaler. Here, post-scaling makes sense because it has an effect on slide speed.

Hope that makes sense

For the comments, I can't use // in front of a pattern list (in the "sequence" part), I got this:

ERROR: Pattern "//    ptn1" is not defined.

I'm glad you've already considered using multiple patterns, it's not in a hurry but it'd help for song design. I think the mdal format would be more complete this way

I'll have to think about that. It would require some rather big changes to the compiler atm.

Single line comment is //
I'll put block comments on the to-do list.

You can totally do that, mdalc doesn't care about formatting except for line breaks.

I definately plan to implement this, as there are some beeper engines that actually require data in this format (zx16, for example). However, it'll be a while before I get around to this. First, I want to finish preliminary documentation, clean up the code, and implement tables.

With $ prefix, it's a hex number so PHA=$800 == PHA=2048

Ah yes, of course. Well spotted

First,
I think the parser could be less strict, for example you can't write:

A=a3, C=d2,

the last comma prevents to compile the song.
As long as there is no data except space, tab or line break, it could consider the comma doesn't exist.

I'd like to see a comment mark (for example to comment a part so it won't play during the rendering)

I like the idea of columns for entering notes. I has an interesting effect, you don't have to enter the value of some notes, like that:

A=g3, B=d2
    A=d3
    A=a3
    A=f3
    A=e3
    A=g3
    
    A=f3, B=c1
    A=d3
    A=e3

here we have for B the d2 note which will last 6 steps, then c1 will last 3 steps. Yeah, basically it's the same as in trackers
I guess also it's easier to parse the notes.

It has some drawbacks however: It's less easy to copy and paste a track (for example channel 2). Some text editors support vertical selection though. When a channel is on a line, you can duplicate it more easily.
I think in addition to the current behaviour, it might worth adding, if possible, independent patterns, it means a pattern could contain only one voice, then you would mix the patterns together for different variations. The current behaviour is like on milkytracker, beepola or vortex tracker, I was thinking to something like on sidwizard or goattracker.

It means something like that would be legit:

     ptn1a, ptn1b, ptn1c

:ptn1a
A=f3, MIXA=and, MIXB=and, PHA=0, PSCA1=none, PSCC=none, SLIDESPD=0, DMOD=off, SPD=8
    A=d3,
    A=a3,
    A=d3
    A=f3, 
    A=e3, 
    
    A=f3,

:ptn1b
     B=d2,
    .
        .
        .
        .
    
     B=f2,


:ptn1c
     C=d2
     C=a2
    C=d2
    C=a2 
     C=d2
     C=a2
    
    C=c2

instead of:

    ptn1


:ptn1
    A=f3, B=d2, C=d2, MIXA=and, MIXB=and, PHA=0, PSCA1=none, PSCC=none, SLIDESPD=0, DMOD=off, SPD=8
    A=d3, C=a2
    A=a3, C=d2
    A=d3, C=a2 
    A=f3, C=d2
    A=e3, C=a2
    
    A=f3, B=f2, C=c2

It might look more verbose, but it could help to design very repetive parts. But maybe it'd be too complicated to parse.

(edit) thanks for the brackets addition, I'll have a look at it. Also for the value, what is correct, PHA=$800 or PHA=800, or is it the same?

I don't understand all the pattern commands effects, but I'll have a try.
In the betaphase.txt it's written
MIXB            Set mixing mode channel 1

I guess it's:
MIXB            Set mixing mode channel 2

In other news, structuring with brackets in patterns is now possible. Just don't skip any of the commas, like I wrote above.
Also I believe I know where that glitch is coming from. Slides in BetaPhase don't stop when they reach the limit. So since the speed is falling back to $10 at the beginning of ptn1, the slide wraps to $ffxx and that's what's causing the glitch. Can't do much about that

I see you're looking for making some global constants, it will be a great thing.

I'll post more about this soon.

ah yes, German notation... I was wondering.
Is it possible to use flat as well?

Yes. It's a matter of adjusting the equates.h file, MDAL itself doesn't care what you feed it (for now, at least).

Any special characters are likely to cause trouble with assemblers, unfortunately. For pasmo, ^ would be interpreted as XOR, and _xxx is a local label. For this reason, MDAL doesn't accept special chars in strings atm (it shouldn't, at least, not sure if I actually implemented that check already). On the long run, I could possibly work out a standardized pitch notation in MDAL, but for the time being it's not really feasible.

Good idea, and it should be fairly simple to add. Perhaps I'll do
A=a1, (MIXA=xor, PHA=$800, PSCA1=down), C=c4, (PSCC=down, SLIDESPD=$30, SPD=6)
though, then I can just simply strip out the brackets when parsing (and usage of the brackets would be optional).

Probably a bug in the compiler. I'll have a look in the coming days. In theory, all values should fall back to their defaults at the beginning of a pattern ($10 for speed in this case). Btw I pushed a new commit a couple of hours ago where I changed some things related to this mechanism, do you have that already? (Simple check: if /config/BetaPhase.cfg has an INIT_DEFAULTS command in the CFG_PATTERNS block, you've got the latest version.

Just saying, in abc flat is _ before the note, ^ is for sharp and = for natural (but not applicable in mdal). So ^f2 would be f2 sharp and _g2 would be g2 flat.

I think you made something great with MDAL. It's perfectly suitable for this kind of music. The only criticism I could say is I find it less readable to get all the info on the same level for example:

A=a1, MIXA=xor, PHA=$800, PSCA1=down, C=c4, PSCC=down, SLIDESPD=$30, SPD=6

It might be more readable like this, with options between parenthesis:

A=a1 (MIXA=xor, PHA=$800, PSCA1=down), C=c4 (PSCC=down, SLIDESPD=$30, SPD=6)

(but maybe it's just me)

(edit)

I have a newer question. I have a simple example like this:

CONFIG=BetaPhase

:SEQUENCE
    
    ptn0
    [loop]
    ptn1
    
    

:ptn0
    A=e1, MIXA=xor, PHA=$400, PSCA1=none, PSCC=down, SLIDESPD=$30, SPD=12
    A=e2
    A=e1
    A=e2
    
:ptn1
    A=e1, MIXA=xor, PHA=$800, PSCA1=down, C=a3, PSCC=down, SLIDESPD=$30, SPD=12
    A=e2, C=rest, SLIDESPD=0
    A=e1, C=e2
    A=e1, B=f2
    A=e1, C=fis2
        A=e1, C=g2
        A=e1, C=gis2
    A=e2, C=b2

is the speed persistent across the patterns? For ptn1 if I remove SPD=12 then I get a little glitch (high pitch tone). If I set SPD=10 (default?), it's even different.
ok I understand, SPD=16 is default (and I get the sound glitch as well)
SPD=16 is 0x10

The "-is" suffix is indeed for sharps, forgot to mention that as well. (German notation, hehe) Using an actual # char would break pasmo, so we'll have to live with "-is" I guess. Originally I had "h" instead of "b" as well

Anyway, thanks for the cheers

Btw fancy website for MDAL: https://utz82.github.io/MDAL
Not much content in the wiki yet, will be filling that in in the coming days.