SpritesMind.Net

*cough*

^ not entirely sure why people keep ignoring this.. And with a SGDK implementation on the way (almost finished), this should be almost perfect.

I've been experimenting with setting different YM timer values to make it faster. And it works pretty well, but PCM timing must be a bit more smoothed out that way. other than that it's running well

Oerg866 wrote:^ not entirely sure why people keep ignoring this.. And with a SGDK implementation on the way (almost finished), this should be almost perfect.

An SGDK version??? Looking forward to it!

Have a native tracker or something... XM sucks

Joking aside, Echo is good stuff

I think MIDI import should be a feature in any sound/music library. Thanks mostly to other peoples help (including Shiru) I've been able to play TFM music tracks but importing music has been a dead end.

I'm pretty sure my future is in using SGDK so I hope Echo does make it there.

Oh, and, isn't it Stefs birthday?

slobu wrote:I think MIDI import should be a feature in any sound/music library. Thanks mostly to other peoples help (including Shiru) I've been able to play TFM music tracks but importing music has been a dead end.

I'm pretty sure my future is in using SGDK so I hope Echo does make it there.

Oh, and, isn't it Stefs birthday?

You can use mod plug tracker to convert a midi to a mod file then you can import it vgm maker or tft maker and echo accepts xm files which can also be converted from midi to xm using mod plug tracker.
Also Shiru mentioned that if we wanted to use a 256 byte buffer that it would cause drums to be behind a frame so why not just have the tracker or converter make the drums trigger a frame ahead so it would appear that the drums play correctly when comparing it to the original file.

I never got syncing issues... it is only matter of placing your commands anyway.

At 16000 Hz 256 bytes is 1/62 second - it is a TV frame of delay. It could be compensated by shifting drum trigger events. If music player update is not quantized to this value, it is one to two TV frames of delay. It can't be compensated, because the delay vary. Higher sample rates or shorter buffer reduces the delay, so compensation would be not needed.

Actually my system would shift note events to the next 256 samples, so only thing one would get is loss of music speed, out of syncness cannot happen.
Since the setup is YM timer based a fix is just making timer period longer and adjusting the song accordingly.

this reminds me a bit of an irc discussion i had w/valleybell regarding his smpsplay and mid2smps tools. if what oerg recommended doesn't pan out, maybe some smps-like driver?

If you vary the number of samples based on the beat, your music never goes out of sync with the samples. That's what I do on my MOD player.

djcouchycouch wrote:What kind of user tools would have to be created so that users can make content for this ultimate sound driver?

A wonderful lib for PCM data is SoX.
At some times I used it to convert any data to PCM data to raw data at the freq I want. I started a genres plugin but never finished it (like too many others things)
Bonus : it's multi OS

Oerg866>
Echo is great driver with good sdk and documentation
It also have good support of SFX and it would be a very nice addition to SGDK if you permit it

But technically i think it is very similar to what we already have : 5FM + 1PCM@10 Khz + 4PSG.
I think having more PCM channels and / or variable rate would be a nice addition.

slobu>Hehe yeah it was, and as every year the music festival in the city celebrated my birthday

About the format used for the driver, maybe VGM is not a good solution as too intensive on Z80 to parse, i think the format should be optimized to limit Z80 parse operation time.
This way we could use about 70% of CPU time for PCM mixing and playing and about 30% for the rest (it should be more than enough i guess for both FM and PSG operation if we limit to simple register writes command).

Not being very knowledgeable about sound drivers for Genesis, what kind of performance impact does it have on the main 68000 CPU? Not having decided what to do about sound and music yet for Goplanes, I'd like to have some general idea about how it'll affect performance.

You will spend a great deal of time waiting behind YM. Z80 is already too fast for YM, and 68K is even faster. One could parse music stuff on 68K and then forward all YM writes to Z80 which will do them.
EA stuff does it from what I know

If you use a good sound driver it could work almost 100% on Z80 and have very minor impact on 68000 (only for send commands to Z80).