Question About Music

[kid0017]

I've been tinkering with the music engine found here: http://alienbill.com/2600/basic/music/

 

I was wondering why when playing in Stella you get that the first note has been shortened a bit. Once the song loops at least once the first note has the correct length. Is there a way to fix this?

[+Random Terrain]

It does the same thing when I preview a tune or sound effect with the Music and Sound Editor that comes with Visual batari Basic. It must take a second or two for Stella to warm up or something.

[+stephena]

 

 

It does the same thing when I preview a tune or sound effect with the Music and Sound Editor that comes with Visual batari Basic. It must take a second or two for Stella to warm up or something.

 

I can't say for sure, but this is probably truer than you realize. Stella runs in a quick loop when it first starts up, autodetecting certain things (type of ROM, number of scanlines per frame, etc). As well, the number of scanlines (and the associated

timing of the frame display) is recalculated every 8 frames or so. This leads to very accurate timing, but of course can cause slight disruptions at first. I didn't realize anyone would notice. You must have much better ears than me

 

EDIT: Try turning on the scanline counter (Alt-l) and reload the ROM (Control-r). I'll bet you see the frame timing jump very quickly at the beginning, and then level off. I'd almost bet this is the cause of the 'stutter' you're hearing.

[kid0017]

I think I'll call it quits for today...it's been interesting. Always wanted to learn some Atari programming. I'm hoping this turns into an exciting hobby for me. Here's my "game" LOL.

default.bas.bin

[+thegoldenband]

EDIT: Try turning on the scanline counter (Alt-l) and reload the ROM (Control-r). I'll bet you see the frame timing jump very quickly at the beginning, and then level off. I'd almost bet this is the cause of the 'stutter' you're hearing.

 

I tried this with the attached ROM (just a black screen with music), but didn't see any scanline change. However, every time I reloaded the ROM, it did stutter/elongate the first note, as Stella usually does when first starting or when background processes start "getting busy".

 

Is there any mode that will force accurate audio timing no matter what? Maybe even one that partially or fully disables video if necessary? That'd be useful for those of us writing TIA music, since sometimes I'm trying to diagnose timing errors and it's very difficult to be sure whether I'm hearing a data error, or a playback glitch/stutter.

 

marioesque-17.bas.bin

[+stephena]

EDIT: Try turning on the scanline counter (Alt-l) and reload the ROM (Control-r). I'll bet you see the frame timing jump very quickly at the beginning, and then level off. I'd almost bet this is the cause of the 'stutter' you're hearing.

 

I tried this with the attached ROM (just a black screen with music), but didn't see any scanline change. However, every time I reloaded the ROM, it did stutter/elongate the first note, as Stella usually does when first starting or when background processes start "getting busy".

 

Is there any mode that will force accurate audio timing no matter what? Maybe even one that partially or fully disables video if necessary? That'd be useful for those of us writing TIA music, since sometimes I'm trying to diagnose timing errors and it's very difficult to be sure whether I'm hearing a data error, or a playback glitch/stutter.

 

marioesque-17.bas.bin

 

If you look very closely, the scanline count does change when you do a reload. It happens so fast that I can't tell what the count is, but I can see that it's not 262. I think that's what causes the stutter.

 

As for how to fix it, unfortunately Stella doesn't currently have a 'sync to audio' mode. And since I think I'm tone-deaf, I don't know how I can improve things in this area. I suppose you could try starting the ROM without running the autodetect loop. Currently, that means to specify the bankswitch type and TV format directly. So, type 'stella -bs 4k -format ntsc marioesque-17.bas.bin', and it will skip the autodetect stuff completely.

 

To be honest, I don't notice any difference on my system. It could be the speed of the computer I'm using, the OS (Linux), or the fact that sound just isn't my forte.

 

EDIT: It might also have something to do with stopping and restarting the sound system each time a ROM is loaded. Or maybe the sound buffers aren't being flushed in some cases, and you're getting/hearing garbage data. I really can't diagnose it until/unless I can duplicate it. Maybe someone can make some sound files that illustrate the problem? Preferably in an uncompressed format such as wav or flac??

[+thegoldenband]

It could just be my underpowered configuration (OS X 10.4 on a PowerBook G4/1.67 GHz), but I definitely notice that audio playback in Stella will stutter and skip if there's anything substantive happening in the background. In fact, every time I change between apps -- say, from the Finder to Firefox -- I can induce an audio "hang" of 3-5 frames or more.

 

Since I capture my TIA tunes using Audio Hijack Pro, those little delays can become very noticeable. Stella needs to be in front and, ideally, in full screen mode to have any chance of avoiding "hung" frames.

 

Is there any other way of capturing TIA audio output? If not, then a "sync to audio" mode would be super-welcome in the farflung future. I'd also love to know someday why the "phaser" demo attached to this post, which sounds pretty great on Stella, falls down on real hardware.

 

phaser06.bin

[+stephena]

It could just be my underpowered configuration (OS X 10.4 on a PowerBook G4/1.67 GHz), but I definitely notice that audio playback in Stella will stutter and skip if there's anything substantive happening in the background. In fact, every time I change between apps -- say, from the Finder to Firefox -- I can induce an audio "hang" of 3-5 frames or more.

 

Since I capture my TIA tunes using Audio Hijack Pro, those little delays can become very noticeable. Stella needs to be in front and, ideally, in full screen mode to have any chance of avoiding "hung" frames.

 

Is there any other way of capturing TIA audio output? If not, then a "sync to audio" mode would be super-welcome in the farflung future. I'd also love to know someday why the "phaser" demo attached to this post, which sounds pretty great on Stella, falls down on real hardware.

 

phaser06.bin

 

Speed of the computer no doubt has some effect. But if this is the sole cause of the problem, fixing it will be more problematic (since it means the entire code needs to be sped up somehow, and that isn't always easy to do).

 

Generally speaking, there are three things in Stella that take most of the CPU time: emulating the TIA, outputting video (OpenGL in your case), and outputting sound. Obviously we can't disable TIA emulation or sound output, as that's exactly what your use case is. However, it's possible (in a future release) to add a configuration option to completely disable video output. The TIA will still generate the data; it just won't be sent to the window. This can save a great deal of time on slower systems.

 

Also, on OSX, Stella automatically uses OpenGL rendering and turns on video sync to monitor refresh rate. While I don't suggest disabling OpenGL mode, you can try turning off 'vsync'. Vsync is for tear-free video, which is probably useless if you're concentrating on audio.

 

Finally, the problem with the phaser demo is in the TIA sound emulation itself. Obviously it needs to be improved. But it isn't related to the speed of the computer at all, just to the emulation of the TIA. This needs to be fixed at some point.

[+thegoldenband]

Thanks for the detailed reply. Interestingly, my CPU isn't getting anywhere close to pegged when I (for example) switch back and forth between Firefox and other apps -- generally it's not going above 70-80% usage (via Activity Monitor).

 

Subjectively, it seems like the delay is caused by screen redrawing of elements. I managed to cause a massive, six- or seven-second hang just now when I opened up fifty empty documents in TextEdit and then tried to change back to Stella -- I thought my computer had crashed! I'll do some more testing and see if I find anything interesting.

[+stephena]

Thanks for the detailed reply. Interestingly, my CPU isn't getting anywhere close to pegged when I (for example) switch back and forth between Firefox and other apps -- generally it's not going above 70-80% usage (via Activity Monitor).

 

Subjectively, it seems like the delay is caused by screen redrawing of elements. I managed to cause a massive, six- or seven-second hang just now when I opened up fifty empty documents in TextEdit and then tried to change back to Stella -- I thought my computer had crashed! I'll do some more testing and see if I find anything interesting.

 

One other thing to try is the 'Timing' option in Video Settings. Normally it's set to 'Sleep', which is considerate of the system and tries to use as little CPU time as possible. You can try switching to 'Busy-wait', which (as the name implies) waits between frames by burning CPU time. Obviously this isn't a good idea on a battery-powered system, but it can sometimes bypass these timing issues. I believe z26 and MESS by default use busy-wait timing.

[+thegoldenband]

I haven't empirically confirmed this, but changing over to busy-wait timing seemed to result in skips, rather than hangs. The overall timing of the music was more nearly retained, but notes would be omitted and/or the TIA seemed to skip ahead to compensate for individual timing losses. So if the music should be

 

"A,A...B,B...C,C...D,D..."

 

With sleep timing I might get:

 

"A,A...BBBBBBBBBB,B...C,C...DDDDD,D..."

 

And with busy-wait it was more like:

 

"A,A..._,B...C,CCC.D,D..."

 

If that makes any sense? I also tried playing with the audio fragment size, but while it seemed to change the rhythm of the hangs/skips, it didn't show any signs of eliminating them.

 

I also tried window-switching with just Stella, Activity Monitor, and TextEdit open, and nothing else. With 100+ blank windows in TextEdit I would get substantial hangs in Stella, with no sign of CPU pegging in Activity Monitor. I'm not sure what that tells us, but I hope it's helpful in some way!

[kid0017]

Spend a few (loving) hours coding one of my old compositions, "The Franciscan Painter". I imagine a starry night sky. I'm going to experiment with the title screen kernel and try to make some form of art out of it.

default.bas.bin

[kid0017]

It occurred to me last night that there may be some improvements to be done on the Music and Sound Editor. It's an awesome utility. I need to know a bit more about the theory of the tones...I guess I'll have to dig around some - perhaps someone here can point me in the right direction. I noticed that a few of the notes are not available for different distortion channels. What if instead of trying to fit the tones into the true tuning, we instead focus on relative tuning among the notes. I imagine a program where you input the notes of your song and what octaves the song should go through. You have that full range. Then the program determines the best numbers to use that give the most accurate tuning WITHIN ITSELF. Relative to the other notes in the song, not to the actual tuning. This, I think, would be great to do and I'd be willing to do it. Is this even something to work at or do you feel it doesn't really make sense as a question? Thanks guys, I'm new and probably seem really annoying, but I really want to take music on the Atari to the next level.

[+thegoldenband]

I'm almost positive that Cybergoth Thomas Jentzsch posted a link to a webpage with a CGI script that does exactly what you mentioned, but I can't find it right now. I'll keep looking...

 

EDIT: Aha, found it! It's called webTune2600, which explains why I couldn't find it searching on "Atari", "TIA", "AUDCx" and so on. It doesn't look at first like it handles transposition, but actually it does, as this discussion clarifies. (The UI is slightly misleading.)

[kid0017]

Ok thanks I was using this at first before I got Visual bB. The first "gamme soft" composition is complete. Here is "The Franciscan Painter". I added another piece to fill the unused channel, and I think it came out quite well. Feel free to use this piece, or snippets from it, as you wish. Just give credit to "gamme soft". Thanks, friends. More "gamme soft" music to come in the future!!

Franciscan_Painter.bas.bin

[+Random Terrain]

It occurred to me last night that there may be some improvements to be done on the Music and Sound Editor. It's an awesome utility. I need to know a bit more about the theory of the tones...I guess I'll have to dig around some - perhaps someone here can point me in the right direction. I noticed that a few of the notes are not available for different distortion channels. What if instead of trying to fit the tones into the true tuning, we instead focus on relative tuning among the notes. I imagine a program where you input the notes of your song and what octaves the song should go through. You have that full range. Then the program determines the best numbers to use that give the most accurate tuning WITHIN ITSELF. Relative to the other notes in the song, not to the actual tuning. This, I think, would be great to do and I'd be willing to do it. Is this even something to work at or do you feel it doesn't really make sense as a question? Thanks guys, I'm new and probably seem really annoying, but I really want to take music on the Atari to the next level.

 

Just in case you didn't see it, the Music and Sound Editor has an Expert Mode tab which displays a grid of all Atari 2600 sounds, so you're not limited to the keyboards that only have sounds that are closest to real notes.

[SeaGtGruff]

I'd also love to know someday why the "phaser" demo attached to this post, which sounds pretty great on Stella, falls down on real hardware.

 

phaser06.bin

I haven't tried it on real hardware yet-- or in an emulator, for that matter!-- but I did disassemble it with DIS6502. I've only just started to look at the disassembly, so I can't tell you for sure what's wrong, and you haven't explained what you mean when you say it "falls down on real hardware." *But* one thing I see is that VBLANK is being turned *off* just before VSYNC, when it should be turned *on* at that point. VBLANK should be *off* only during the times when you want to draw to the screen, and turned *on* for the entire duration of the vertical blank period-- which includes the so-called "overscan" lines, the vertical sync lines, and the so-called "vblank" lines. If you turn VBLANK *off* just before the vertical sync, it will nearly always cause problems with the vertical sync and result in screen roll. The only possible exception is if you've got all graphical objects "turned off" (pixels of 0) or all colors set to black-- but it looks like the background color is being set, which would mess up vertical sync.

[SeaGtGruff]

I'm almost positive that Cybergoth Thomas Jentzsch posted a link to a webpage with a CGI script that does exactly what you mentioned, but I can't find it right now. I'll keep looking...

 

EDIT: Aha, found it! It's called webTune2600, which explains why I couldn't find it searching on "Atari", "TIA", "AUDCx" and so on. It doesn't look at first like it handles transposition, but actually it does, as this discussion clarifies. (The UI is slightly misleading.)

This looks like a cool utility-- thanks for digging up the link!

[+stephena]

I'd also love to know someday why the "phaser" demo attached to this post, which sounds pretty great on Stella, falls down on real hardware.

 

phaser06.bin

I haven't tried it on real hardware yet-- or in an emulator, for that matter!-- but I did disassemble it with DIS6502. I've only just started to look at the disassembly, so I can't tell you for sure what's wrong, and you haven't explained what you mean when you say it "falls down on real hardware." *But* one thing I see is that VBLANK is being turned *off* just before VSYNC, when it should be turned *on* at that point. VBLANK should be *off* only during the times when you want to draw to the screen, and turned *on* for the entire duration of the vertical blank period-- which includes the so-called "overscan" lines, the vertical sync lines, and the so-called "vblank" lines. If you turn VBLANK *off* just before the vertical sync, it will nearly always cause problems with the vertical sync and result in screen roll. The only possible exception is if you've got all graphical objects "turned off" (pixels of 0) or all colors set to black-- but it looks like the background color is being set, which would mess up vertical sync.

 

I can confirm (on real hardware) that the image displayed is different from any emulator I've tested with. So there's definitely more than audio issues here. Maybe if the screen roll/VSYNC/VBLANK issues are properly emulated in Stella, it will fix the sound issues too ??

[+thegoldenband]

I haven't tried it on real hardware yet-- or in an emulator, for that matter!-- but I did disassemble it with DIS6502. I've only just started to look at the disassembly, so I can't tell you for sure what's wrong, and you haven't explained what you mean when you say it "falls down on real hardware."

 

Hey, thanks for checking this out! I think I made an oblique reference to the issue in one of your sound threads a while back, and I'm grateful for your expertise. Anyway, the source code is here, but the video display is just a version of code from one of Andrew Davie's tutorials, and I may well have butchered the VSYNC/VBLANK timing in the process of meddling with it. It's just there as a placeholder, basically, for my audio experiment.

 

The "falls down on real hardware" issue is that the "phaser" sound effect -- which sounds so good (IMHO) in Stella (I don't know about other emulators, though) and is consistent and repeatable -- ends up a mess when I try it on real hardware via the Harmony cart: the sound is totally different and essentially unsuccessful. It's been a couple years since I've worked on it, so I don't remember all the details, but basically the idea was that I could get a phasing effect between two TIA channels tuned to the same pitch by briefly bumping AUDF1 to a different value for a few scanlines.

[SeaGtGruff]

I can confirm (on real hardware) that the image displayed is different from any emulator I've tested with. So there's definitely more than audio issues here. Maybe if the screen roll/VSYNC/VBLANK issues are properly emulated in Stella, it will fix the sound issues too ??

I don't know what the sound issues are, but I'm inclined to doubt that emulating screen roll would affect the sound, as screen roll is a video problem and the audio should neither affect, nor be affected by, the video. The TIA outputs its two audio clocks (A-phi-1 and A-phi-2) twice each on every scanline, including scanlines where VSYNC is turned on, so any sounds that are being played will continue being generated even during the VSYNC.

 

I'm inclined to suspect that any audio differences between real hardware and an emulator are due to differences in the ways the audio is being generated. On a real Atari 2600 the TIA is generating waveforms through a combination of how the audio clocks are being modified by the frequency divider, then how the audio control register is telling the 5-bit LFSR and the 4-bit LFSR to produce the final waveform, with the audio volume registers determining the strength of each "on" bit in the waveform. But the signal from the AU0 pin (and/or the AU1 pin) then gets fed into the RF modulator circuitry, which apparently affects the final shape of the waveform. For example, the AU0 pin might be outputting an audio signal made up of rectangular pulse waves, but when I recorded the output of the RF modulator to DVD and looked at the waves on my computer, the waveforms were definitely *not* rectangular pulses-- they look curved, more like sine waves (but not pure sine waves), or like curved sawtooth waves (the final shape is apparently affected by how many 1s or 0s are being output, as well as how many 1s or 0s were previously being output before a change occurred).

 

I don't know how Stella's audio is programmed, but I imagine it's based on an idealized attempt to emulate the TIA's waveforms. There are a number of areas where this probably needs to be improved if possible:

 

(1) The audio clocks occur at specific moments during each scanline, and they don't follow a symmetrical pattern. The audio 1 (A-phi-1) clocks are less important to the resulting waveform than the audio 2 (A-phi-2) clocks, because the audio 1 clocks are mainly used (in conjunction with the audio 2 clocks) to drive the frequency divider. But the audio 2 clocks occur at intervals of 112 color clocks and 116 color clocks, whereas I imagine the TIA audio emulation is assuming a perfect 114-114 separation. The difference is probably negligible, so it's probably more crucial to try to get the audio 2 clocks to coincide with the general moment on each scanline when they occur. The issue here is a question of how the exact timing of making changes to the AUDF0/1 and AUDC0/1 registers will interact with the audio clocks-- that is, on a real Atari 2600 the changes might occur just before the audio 2 clock is generated, whereas in an emulator the changes might occur *afterward*, if you see what I mean.

 

(2) The primary frequency division is accomplished by feeding the audio 1 and audio 2 clocks through the frequency divider circuitry, which then outputs the tone 1 and tone 2 clocks (T-phi-1 and T-phi-2). Basically, the tone 1 and tone 2 clocks are the same as the audio 1 and audio 2 clocks, except some of the audio 1 and audio 2 clocks get skipped due to the division-- that is, division by 2 (AUDF0=1) will let every other audio 1 and audio 2 clock through, division by 3 will let every third clock through, and so on. The main problem with this step is that changes to the AUDF0/1 registers do not necessarily result in immediate changes to the tone 1 and tone 2 clocks, because the frequency divider may need to finish its current process before the new AUDF0/1 value can begin to have an effect-- and that could potentially take the equivalent of several scanlines. If the emulation is changing the frequency immediately after the AUDF0/1 register has been written to, then it won't be accurate.

 

(3) Likewise, the waveforms on a real Atari 2600 don't change as soon as the AUDC0/1 registers are written to, because the current contents of the 5-bit LFSR and 4-bit LFSR need to keep shifting before their new input values can go through each "bit" of the polynomials and emerge from their last "bit." So if the emulator is making immediate changes to the waveforms as soon as AUDC0/1 is written to, it won't be accurate.

 

(4) Finally, if the emulator isn't able to duplicate the results of feeding the AU0/1 signals through the RF modulator, then the sounds may sound different than they do on a real Atari 2600. I don't know how the RF modulator works-- I haven't tried to decipher that portion of the schematics yet-- but it does seem like it might be possible to emulate the results to some extent, because there must be some sort of logic to how the RF modulator is affecting the final audio output.

 

I've been working on understanding the TIA's audio generation, as well as other portions of the schematics. I'd started making a spreadsheet to simulate the TIA-- using IF() functions to duplicate the effects of the inverters, NOR gates, AND gates, NAND gates, flip-flops, etc.-- but what I'd like to do is create a program that does the same thing, with entry fields for the different registers. This will probably be a long and drawn-out project, and I'm currently preoccupied with family matters and work-related matters, so I can't say when I'll be able to work on this particular pet project. But I'll certainly pass along any insights, and post anything I manage to put together, in the hopes it will help with improving TIA emulation.

[SeaGtGruff]

It's been a couple years since I've worked on it, so I don't remember all the details, but basically the idea was that I could get a phasing effect between two TIA channels tuned to the same pitch by briefly bumping AUDF1 to a different value for a few scanlines.

This sounds like it's a problem with how changes to AUDF1 are being handled by the emulator. As I said in my other post, the audio frequency divider may need to finish up its current process before the new AUDF0/1 value can begin to have an effect, and this can take several scanlines on the real hardware.

[+thegoldenband]

This sounds like it's a problem with how changes to AUDF1 are being handled by the emulator. As I said in my other post, the audio frequency divider may need to finish up its current process before the new AUDF0/1 value can begin to have an effect, and this can take several scanlines on the real hardware.

 

It sounds like one way to test this would be to create a version of my program that would adjust the number of scanlines between changes to AUDF1 (using joystick input or something similar), with a numerical onscreen display indicating the adjustment. That way one might find the "sweet spot" on real hardware that allows the intended effect to be duplicated, unless the effect depends on non-reproducible timing of changes to AUDF1 (vs. the emulator's inadvertent consistency?), non-reproducible hardware startup conditions, or is otherwise made impossible by non-linear TIA behavior.

 

The fact that I was able to hugely change the number of scanlines in my demo, with little effect on the aural results (in the emulator) until I reached 2-3 scanlines between changes, is suggestive. Of what, mind you, I'm unsure.

[kid0017]

The latest gamme soft composition is out: "Klax". Klax was originally written in 2002, named after the classic arcade game. Finally, Klax (the song) is available for the Atari 2600! Enjoy.

klax.bas.bin