Quote:

I think it's more adventurous to live with the limits instead of extending the standard.

I agree on living with limits, however, you wouldn't be happy if your msx had 32k ram. 32k computer ram compares quite realisticly with 128k opl4 ram (since samples take more space than code, tables or gfx). With 128k, your opl4 will always sound like an intertoys casio from 1992, I prefer Microcabin on FM-Pac in that case. You definitly need that 640k sram fo cram your own samples in, and I'd wish I could use even more! However, considering the 720k disksize, 640k is a realistic limit.

Opl4 ROM samples don't have any reverb tales, and esp. with drums this is why it sounds cheap. Opl4 ROM samples are mostly 11khz, not exactly cool either. Opl4 samples are based on the GM set.. not very handy, since your ROM is crammed with sounds you'd never use but are taking space, which could be used to house better sounds.

Anyway, SRAM is the solution to all this! With 640k you really have a great soundcard for games etc.

And about the loading time, it's only once. Just give it a minute to load it all, meanwhile you can clean your room or make tea

Besides, you can run everything from compactflash or harddisk these days

I'd set the limits on 512KB though? Why? Because I have 512KB

Well, that's something I want to know before I ever start doing tunes..

The amount of ram on the curent pile of opl4 carts.. something for a poll I'd say

anyway.. 512k instead of 640k, that's 128k difference.. and that's huge

Wolf - I know, but in MSX terms both 512K and 640K are already quite huge, aren't they ?

Anyway... euhm we already have 2 other polls waiting in line so euhm.. be patient

I think the only limit is 2 MB as regards the SRAM
So the limit will not be set by a person but by the possibilities.
The makers of software decide if they want /find a way to make samples within a game or a number of very good songs that use the sample ram requested and according to Wolf this is 640.
But over all those years music programmers never used the opportunity to take a full profit of all the possiblities extra sample ram gives. And as today no one offered Sunrise the possiblity to sell or the possiblity to supply extra sample ram with a good game or songs.

Well, that there was no mass-support for big tunes was because ppl probably didn't do alot with their opl4 anyway. Now that new software is coming up, now that more veterans show new interest in msx and now that within a year or faster (I think) the emulators offer superb emulation (w/o flaws!), I think it's fair to expect new tunes..

Another reason was that HD's were still only for the elite back then. Now with ATA-IDE and ATA-CF those problems are no more. Using 512KB or even more for samples isn't a big a deal anymore as it used to be.

Quote:

well, actually, it would be a good idea to gather some info about the opl4 carts currently sold.. (sunrise ?) I figured that a typical sram expansion is 512kb, + the internal 128k is 640k.. but I dunno if there are other common situations...?

Well as Sunrise pointed out there more to it than just 'plugging in' the chip, it even requires some soldering, while some people don't even have a soldering iron! (ok that's rediculous, I think so too ;p). Anyways, the difference between 512k and 640k isn't as much as between 128k and 512k/640k, so I think you can do pretty amazing stuff with 512k already, and at least that also allows people to do an easy upgrade of their MoonSound.

Aside from that, 512k also means you're saving 128k of disk space, which is quite a lot, considering using 640k samples means you have only 80k left on every disk for music data, levels, graphics, game engine, etc . That's not much, very impractical unless you want to swap disks and wait a couple of minutes while loading the first level only to load the samples in memory... ^_^ Yah, ok ok I know, CF rules . But still...

Quote:

maybe a new poll? "how much ram does your opl4 have", or, "would you expand it to 640k if there was content for it?"

I think that as soon there is someone really starting to develop a game with such specs such a poll could easily be requested at msx.org and used to make some game design (or in particular: music design) choices.


~Grauw

I didn't intend to have a different 640k kit for each level of a game, but just one kit for the whole game. You load the kit from disk 1, and play the game on disk 2, without ever changing disks.

Yeah, when is the last time you played a single-disk game anyway?

As long as it's HD-installable I'll be satisfied ;p.

~Grauw

Quote:

I didn't intend to have a different 640k kit for each level of a game, but just one kit for the whole game. You load the kit from disk 1, and play the game on disk 2, without ever changing disks.

Why not create 4 wavekits @ 128kB and let your songs use one of 'm at one time?

I know this is a bit more restrictive and will increase overall loading time (unless you use a diskcache when the MSX has a nice amount of RAM), but then I can at least hear something too

Or create one big wavekit... let the software scan the song, determine which waves are needed and load them into SRAM on the fly (some smart "init-time-streaming" algo or whatever... you'll have to let Ro create his own wavekit format + converter in that case.)
If you add some instrument remapping code, you can even decrease loading times drastically (i.e.: you swap out instruments that are not needed anymore and replace them by the ones you do need).

(I dunno the Moonblaster for Wave internals very well, though... might be impossible after all.)

Well I've coded a 'sample scan' routine before (on mb1.44) for our kernel. It converts it into a variable samplekit file. That's a problem with MB anyway. The standard file lenght I mean.
(the routine also scanned for 'gaps' in the kit which were wasted space)

smart coding is the issue here, AND how about samples that are not well cut (the edges I mean) so much wasted space eh.

If I know Wolf well enough he'd make custom samples for every song (including chords etc) but hell, we've got HD, do we not? (well not every body)

Huh, I don't even have an opl4.. anymore. But I don't mind. I like chiptunes.

Quote:

Well I've coded a 'sample scan' routine before (on mb1.44) for our kernel. It converts it into a variable samplekit file. That's a problem with MB anyway. The standard file lenght I mean. (the routine also scanned for 'gaps' in the kit which were wasted space) smart coding is the issue here, AND how about samples that are not well cut (the edges I mean) so much wasted space eh.

Sounds like you're my man!

Cutting samples optimally is something I wouldn't do @ runtime, though. I'm sure Wolf is an excellent sample cutter (afaik he has been using samples for ages now). Only problem with composers (pur sang) is that they prefer high quality stuff while the programmer wants things to be small. These things never go together :/

But to give you an example: my latest GBA game used to have more than 1MB worth of samples in ROM, but due to ROM size-restrictions we had to cut back and compress stuff. Now the sound is still the same but only 650kB of samples are in the ROM. Some sound effects were downscaled to 11kHz... some instruments were too. The big saver was moving all loop points (i.e. making loops shorter). This didn't affect the music that much. Even the musician doesn't hear much difference (and that's usually the person who's very critical when it comes to listening to his own music).


We utilize 14 songs (8 chn XM in stereo) and 45 sound effects. All PCM based stuff.

I thought about custom loading seperate samples too. However, you can be asure that I need full 640k for all tunes. In this case I mean: One big 640k kit, and all tunes use it, so in essence, each tune is '640k big'.

There are no technical limits on using 640k, except the amount of SRAM a user has, so there's no need to skimp on that.

5 tunes sharing 1 640k kit is far more efficient AND greatly expands the possibilities compared to 5 tunes with their own 128k kit.

The difference between 640k or 128k for custom samples is like day and night. Or, to keep it more musically, it's the difference between cheap lofi-sounds and orchestral sounds. Thousends of reasons to get extra sram