Music sounds conflicted.

[PuzZLeR]

Greetings,

 

Personally, I don't think background music during gameplay is necessary for my latest project, since I prefer it quiet with just the sound effects to be heard more fully. (Music can make it sound cheesy if not careful.)

 

However, just for kicks, I did some experimentation.

 

The music plays great on static screens, but during gameplay it sounds gargled. What's strange about this is that it's not always gargled, just when a certain sprite/MOB moves. It's like there's some conflict of some sort.

 

I have tried to mess around with ORG, PLAY SIMPLE, etc, yet still the gargle persists.

 

Does this sound familiar to some? Any quick and dirty solution I can try?

[artrag]

Just an idea, maybe it is silly, but do you have at least a Wait instruction in your main loop?

[+DZ-Jay]

 

Does this sound familiar to some? Any quick and dirty solution I can try?

 

Not really a solution, but something quick-and-dirty for you to try: post some code so that people can try to help.

 

UPDATE: Some things to consider: the STIC is mapped to locations $0000 - $0032 and the PSG is mapped to locations $01F0 - $01FF, so if you are doing any manual manipulations to the address in variables, and happen to get an overflow, it is conceivable that a purported write to a MOB register ends up in the PSG instead -- especially if using 8-bit variables.

 

Another thought is that, if you are storing a pointer in an 8-bit variable, it will get truncated to it's lower byte, which may coincide with a PSG address.

 

-dZ.

Edited August 10, 2018 by DZ-Jay

[vroby]

call (gosub ) this routine at the end of sound

 

sound_reset: PROCEDURE

SOUND 0,1,0

SOUND 1,1,0

SOUND 2,1,0

SOUND 4,,$38

RETURN

END

[+DZ-Jay]

 

Greetings,

 

Personally, I don't think background music during gameplay is necessary for my latest project, since I prefer it quiet with just the sound effects to be heard more fully. (Music can make it sound cheesy if not careful.)

 

However, just for kicks, I did some experimentation.

 

The music plays great on static screens, but during gameplay it sounds gargled. What's strange about this is that it's not always gargled, just when a certain sprite/MOB moves. It's like there's some conflict of some sort.

 

I have tried to mess around with ORG, PLAY SIMPLE, etc, yet still the gargle persists.

 

Does this sound familiar to some? Any quick and dirty solution I can try?

 

From your description, it sounds like it could be a sound effect causing some problem. If you have music playing, make sure that your sound effects are constrained to the third channel (SOUND 2), so that they don't conflict with the music player. Also, make sure you use PLAY SIMPLE (to only play music in the first two channels). If you use PLAY FULL, it may conflict with your sound effects.

 

-dZ.

Edited August 9, 2018 by DZ-Jay

[intvnut]

UPDATE: Some things to consider: the STIC is mapped to locations $0000 - $0032 and the PSG is mapped to locations $00F0 - $00FF, so if you are doing any manual manipulations to the address in variables, and happen to get an overflow, it is conceivable that a purported write to a MOB register ends up in the PSG instead -- especially if using 8-bit variables.

 

Minor correction here: The PSG is mapped at $1F0 - $1FF in the main unit. The ECS PSG is at $00F0 - $00FF.

[+DZ-Jay]

 

Minor correction here: The PSG is mapped at $1F0 - $1FF in the main unit. The ECS PSG is at $00F0 - $00FF.

You are right, of course. That was a typo.

[Kiwi]

See if you have a wait in your game loop to keep the game running at 60 fps, and not uncapped fps.

Gameloop:
<Game logic stuff>
wait
goto Gameloop

So sprite and other stuff can be push into the register during that time.

[+DZ-Jay]

See if you have a wait in your game loop to keep the game running at 60 fps, and not uncapped fps.

 

Gameloop:

<Game logic stuff>

wait

goto Gameloop

 

So sprite and other stuff can be push into the register during that time.

 

Is the SOUND statement buffered as well? The PSG does not have restrictions on access.

 

-dZ.

[PuzZLeR]

Hey thanks for your replies - very much appreciated. I've read every one of them, but I wanted to do a bit more experimentation before a proper reply to the responses.

 

The problem is solved. For now.

 

For academic reasons:

 

 

call (gosub ) this routine at the end of sound

 

sound_reset: PROCEDURE

SOUND 0,1,0

SOUND 1,1,0

SOUND 2,1,0

SOUND 4,,$38

RETURN

END

 

 

Very ironic. Yes,sound_reset is important, and I did indeed have such a procedure, but it was what was causing the problem. I was calling the sound_reset after a certain action with the sprites with an IF, which was causing the conflict, or relieving the conflict when the IF did not apply. Changing it to the following solved the problem:

sound_reset:    PROCEDURE
    SOUND 2,1,0   'or SOUND 2,,0 was also fine
    SOUND 4,,$38
    RETURN
END

Apparently, even deactivating the first and second channels (SOUND 0 and SOUND 1 respectively) somehow activates them in a different way. Now I just stay away from them entirely (when playing music) and delete them from the procedure.

 

At any rate, I'm still glad I started this thread. I still have a few comments and questions which may generate some valuable discussion.

 

SOUND 4 seems to work. I do indeed work with PLAY SIMPLE (but use PLAY SIMPLE NO DRUMS to be safe). Hopefully I don't have a problem down the road with this channel.

 

SOUND 3 now sucks with background music. It "works" but doesn't do the same thing with music on.

 

From your description, it sounds like it could be a sound effect causing some problem. If you have music playing, make sure that your sound effects are constrained to the third channel (SOUND 2), so that they don't conflict with the music player. Also, make sure you use PLAY SIMPLE (to only play music in the first two channels). If you use PLAY FULL, it may conflict with your sound effects.

 

True indeed. And it makes sense that the first two channels were causing the problem (even if I was only deactivating them).

 

I ask the Forum, how about the role SOUND 3 and SOUND 4 play in this context? Any feedback on this?

 

...if you are doing any manual manipulations to the address in variables, and happen to get an overflow, it is conceivable that a purported write to a MOB register ends up in the PSG instead -- especially if using 8-bit variables.

 

Another thought is that, if you are storing a pointer in an 8-bit variable, it will get truncated to it's lower byte, which may coincide with a PSG address.

 

 

 

The PSG is mapped at $1F0 - $1FF in the main unit. The ECS PSG is at $00F0 - $00FF.

 

I did indeed play around with ORG and tried to isolate sound and music in different ROM segments so they don't conflict. I had no success. I was wondering, is there a proper way to do this?

 

Just an idea, maybe it is silly, but do you have at least a Wait instruction in your main loop?

 

Kiwi said: (For some reason the Forum was not letting me quote you properly, so I do this manually. )

 

See if you have a wait in your game loop to keep the game running at 60 fps, and not uncapped fps.

Gameloop:
<Game logic stuff>
wait
goto Gameloop

So sprite and other stuff can be push into the register during that time.

 

Ha ha. I've accomplised that bumble in the past, and it has created sound/music problems before, so worth pointing out.

Edited August 13, 2018 by PuzZLeR

[+nanochess]

SOUND 3 isn't affected by the music player. It should have the same effect when used with SOUND 2.

 

Just make sure the volume parameter of SOUND 2 is 48 to enable the usage of SOUND 3.

 

Your settings for SOUND 4 are right.

[PuzZLeR]

Thanks Nanochess. It's helped already.

 

I just may decide to include game play music in my project after all since now I can hear the sound effects better. (However, working on reducing the "cheesy" factor. )

[+atari2600land]

I don't know if this is your problem, but I just thought this: Do not have the PLAY MUSIC in your loop. It needs to be called just once.

[PuzZLeR]

I don't know if this is your problem, but I just thought this: Do not have the PLAY MUSIC in your loop. It needs to be called just once.

 

It wasn't my problem, but you bring up an interesting point. Changing the music upon game level, screen, mode, etc, is easy. Changing the music during, say during an in-level action such as a power up received, etc, is an adventure.