One Note

[emkay]

As I mentioned before. Resetting the timers is good to have a "common" start for a tune.

 

What's really missing for a fluent tune programming is the pitch correction and to make it in a shorter time than several VBI cycles.

 

 

This part of "Green Beret" I'm actually a little proud of, to have it working at this "level" even due to the limits of RMT.

If you listen to it, you realize some short breaks in some notes. That's where the corection happens.

If you'd want to have "arpeggios" in that same style, you'd not being able to hear a note, because it's allways "correcting" without playing a note then.

 

At least this one uses 2 operator ring modulated sounds, and, If you may recognize, the method never touches the other channels.

 

 

">

" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"> Edited September 27, 2014 by emkay

[emkay]

If you want to check it. Here's the XEX of the tune.

 

The 16 bit "Drums" were very experimental moreover, due to missing 16 Bit support ...

green beret.xex

[Xuel]

OK, I figured out how to do a smooth sweep of the duty cycle:

 

sweep.xex (github)

 

This works by slightly changing the period of one of the channels involved in the high-pass filter for just one pulse and then changing it back after the pulse ends. The pulse end is detected by polling IRQST so it burns a variable amount of CPU time depending on where the pulse is at the start of the frame, but it could be changed to use an actual interrupt handler which would use very little CPU time. STIMER is only used to establish the initial phase relationship, as emkay suggested.

[emkay]

Nice method. Probably a way to have 100% stable sounds.

 

The variation in producing the pulse with can be coded directly, without extra interrupts.

POKEY stores values for ca. 32 cycles. As the music-player has to do stuff, it could be done like this:

 

check value of the used channel

set the pitch one up

do something for about 32 cycles

set the pitch one down.

 

The resulting pulse width is the fixed dependency of the used CPU cycles and used wave length of the frequency the channel is playing.

 

What's also working is a "tick" with the highest tone, a channel can produce, and set the value back after the fixed amount of CPU cycles.

 

The most important point is to have the channels playing at always the same position. It's easy when using the VBI , just play the notes at the start of the VBI routines... RMT does this well, already.

[analmux]

... I'm reseting STIMER every 3 frames ...

Using my approach I don't do it that often.

 

... It seems like it really limits the musical potential if you can't sweep the duty cycle cleanly though ...

Did you already think about software computations, using correction tables? F.e. in the mean time the CPU can compute shadow AUDF numbers and write down expected values of the countdown timers, then subtracting pulse changes, obtaining a netto value.

 

Another thing: AUDF3 can also be an integer factor of AUDF1, so that phase changing can be more precisely controlled. Using other words, this is still not the limit.

[pirx]

For some time I've got some fokking krazy idea of trashing the tracker mechanisms whatsoever and create player working as a decompressor of packed stream of (register, value) pairs.

 

Think about this - 3 minutes long stream of 8 bytes per frame is circa 72KiB (PAL). Combine it with deflater or exomizer (or a new dedicated compressor) and you get it compressed to few KiBs with a player that takes the same amount of time each frame, in contrary to one sophisticated RMT player that can eat a huge part of a frame when hungry.

 

But the real gain is that the song itself could be just any combination of values pushed to POKEY.

 

The editor could start similarly to SoftSynth as a text based pseudo language defining each blocks of sound, starting from single POKEY wobbles to "instruments", tracks and songs. Output of the editor would be "compiled" stream of values to be pushed to POKEY each frame.

 

For composers who need to hear the sounds when composing the tracker-like editor might be prepared at a later stage.

 

So this project is sweet, because it neatly splits into few separate and interchangeable blocks:

1. per-frame POKEY value pusher ("player"), including decompression of raw POKEY data

2. SoftSynth-like compiler of POKEY sound building blocks into raw POKEY data stream

3. GUI editor of the building blocks (instruments, tracks, songs, etc.

 

Please bash (nomen omen) the idea [;

 

Best,

 

pirx

[Xuel]

For some time I've got some fokking krazy idea of trashing the tracker mechanisms whatsoever and create player working as a decompressor of packed stream of (register, value) pairs.

 

Definitely not a crazy idea. I've seen it mentioned a few times before, for example by Rybags here.

 

You might not even have to make a new editor. RMT can dump out a text version of the song that you could parse with some effort. Or you could run the song in a 6502 simulator and trap writes to the POKEY registers. I used that technique to verify multiply routines here.

[Tezz]

@ Pirx, I've been contemplating that for a while too with some excitement after previous discussions.

[Heaven/TQA]

I think the "dump tracker" was mention as well in the SID-player kind of context?

[Tezz]

I think the "dump tracker" was mention as well in the SID-player kind of context?

Yes, Jac suggested doing that It's something that I hope to get around to trying. Developing a soft synth tracker and decompressing Pokey register streams is an interesting prospect. I don't think the streams would compress to such a degree but it's definately worth investing some time into.

[analmux]

See: http://atariage.com/forums/topic/229825-one-note/?p=3076857

Here some other examples:

 

 

(1) Silence / A Trivial Example:

 

LDX #9
STX AUDF1
STX AUDF3
STX STIMER

AUDF1 Pulses:      |---------|---------|---------|---------|--------- ...
AUDF3 Pulses:      |---------|---------|---------|---------|--------- ...
Countdown Timer 1: 98765432109876543210987654321098765432109876543210 ...
Countdown Timer 3: 98765432109876543210987654321098765432109876543210 ...

Resulting Signal:  __________________________________________________
                   00000000000000000000000000000000000000000000000000 ...

(2) More Complex Pattern:

 

LDX #9
LDA #3
STX AUDF1
STA AUDF3
STA STIMER

AUDF1 Pulses:      |---------|---------|---------|---------|--------- ...
AUDF3 Pulses:      |---|---|---|---|---|---|---|---|---|---|---|---|- ...
Countdown Timer 1: 98765432109876543210987654321098765432109876543210 ...
Countdown Timer 3: 32103210321032103210321032103210321032103210321032 ...

                             __                  __
Resulting Signal:  __________  __________________  __________________

                   00000000001100000000000000000011000000000000000000 ...

(3) More Complex Pattern:

 

LDX #9
LDY #4
LDA #3
STX AUDF1
STY AUDF3
STA STIMER
STA AUDF3

AUDF1 Pulses:      |---------|---------|---------|---------|--------- ...
AUDF3 Pulses:      |----|---|---|---|---|---|---|---|---|---|---|---| ...
Countdown Timer 1: 98765432109876543210987654321098765432109876543210 ...
Countdown Timer 3: 43210321032103210321032103210321032103210321032103 ...

                             ___       _         ___       _
Resulting Signal:  __________   _______ _________   _______ _________
                   00000000001110000000100000000011100000001000000000 ... 

(4) More Complex Pattern:

 

LDX #1
LDA #4
STX AUDF1
STA AUDF3
STA STIMER

AUDF1 Pulses:      |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- ...
AUDF3 Pulses:      |----|----|----|----|----|----|- ...
Countdown Timer 1: 10101010101010101010101010101010 ...
Countdown Timer 3: 43210432104321043210432104321043 ...

                     __  __    __  __    __  __
Resulting Signal:  __  __  ____  __  ____  __  ____
                   00110011000011001100001100110000 ...

(5) More Complex Pattern:

 

LDX #9
LDA #7
STX AUDF1
STA AUDF3
STA STIMER

AUDF1 Pulses:      |---------|---------|---------|---------|---------|---------|--------- ...
AUDF3 Pulses:      |-------|-------|-------|-------|-------|-------|-------|-------|----- ...
Countdown Timer 1: 9876543210987654321098765432109876543210987654321098765432109876543210 ...
Countdown Timer 3: 7654321076543210765432107654321076543210765432107654321076543210765432 ...

                             ______    ____      __                  ______    ____
Resulting Signal:  __________      ____    ______  __________________      ____    ______
                   0000000000111111000011110000001100000000000000000011111100001111000000 ...

(6) Swap Settings of (5):

 

LDX #7
LDA #9
STX AUDF1
STA AUDF3
STA STIMER

AUDF1 Pulses:      |-------|-------|-------|-------|-------|-------|-------|-------|----- ...
AUDF3 Pulses:      |---------|---------|---------|---------|---------|---------|--------- ...
Countdown Timer 1: 7654321076543210765432107654321076543210765432107654321076543210765432 ...
Countdown Timer 3: 9876543210987654321098765432109876543210987654321098765432109876543210 ...


                           __      ____    ______  ________        __      ____    ______
Resulting Signal:  ________  ______    ____      __        ________  ______    ____
                   0000000011000000111100001111110011111111000000001100000011110000111111 ...

Note that (5) sounds like a major third if also the volume of AUDC3 is turned on! For example, see the graph of 'volume1' = 4 and 'volume3' = 2 below. In general, if (AUDF1 + 1)/(AUDF3 + 1) assumes the exact 5:4 ratio, then we get a major third of the 'pure intonation'. We only need the note restriction (AUDF1 + 1)/5 = "integer".

[emkay]

Interesting, that all those calculations got possible.

I wonder what the creator of POKEY thought, when building that thing.

The "8 bit" resolution would have worked good, if at least a 2 octaves modes had existed.

The poly counters, that don't do a "precise job".

What's really bad with POKEY, is the missing deep notes.

 

....

 

 

And finally the "High Pass Filters" that were no "High Pass Filters" . Just the fact that one voice is acting like a "Ring Modulator" that makes the resulting sound higher, if they are not at the same pitch, made them to name that "High Pass Filter" .

Looks like the creator of POKEY had NO idea about sound processing

Till the early 90s , it has been said, POKEY is not able to do 2 Operator sounds, because it's always sounding different.

Where have all the technical advanced users been?

 

In this thread we see a technical discussion about something that "isn't real"

 

 

To put the most out of POKEY we should forget some "decompression" of a data package and put it regulary to POKEY's registers. The best sound will come with irregular programming, except, you find a way to program all POKEY registers at a rate of approx. 50kHz.

Edited September 30, 2014 by emkay

[emkay]

In this testtune I did some adjustment on instruments in any patterns.

Again, very experimental, as I cannot find a fitting "bass sound" for the tune.

 

You may listen to the main melodic part . The lower sounds get more interesting at long played notes. The high notes were also doing some sweep sound but have been stabilized. If you might hear a "portamento" effect, be sure, there is none. It's all build on the wave shaping. Or lets say it in other words "OPL 2" sounds...

 

 

Someone interested to change the basses to a better fitting sound?

[emkay]

Here is how the tune is played inside RMT. Have a listen to the differences and why it isn't really funny to create those "OPL2" sounds, as the results in RMT weren't as original as needed, and it also causes to reduce the sounding possibilites to have a "most common" sounding in RMT and other emulations and the real thing.

Remember: All Ataris have the same "POKEY - CPU" dependency. So the problems were only in the emulations...

 

Edited October 3, 2014 by emkay