I've seen enough songs with more than 16 voices. Besides, if you have 18FM + 24PCM channels you only need more voices! So I'd really go for 64 voices (or maybe 48).

As a coder you should never design a tracker purely based on your own experiences!

That's what happened to so many trackers.. including MB ..! It depends on the level of complexity of the actual composer.. and many ppl who coded trackers in the 90's were surrounded by less-complex composers. Not that I mind less-complex composers, but at least they shouldn't be the testers/designers/initiators for a tracker, because for sure the tracker will be limited only to their needs then
A typical example of 90's MSX music was: FM-pac: 1 channel for the bass, 3 for violins (or whatever creates a chord) 1 channel for a lead, and 1 channel for a counter-melody. This perfectly fits into Pro-Tracker for example, and if you listen to the titlescreen-music of Pro-Tracker then you'll notice the things I described above
And MB also has a typical 'based-on-a-moonsoft-composer'-limit, as I've been told by RS himself .. that is .. we shouldn't call it a 'limit' .. but "why would anyone want to use more than 12 voices for a song.. guess 16 is enough then?"

In the PC-scene there's something comparible.. many trackers that showed-up since the classic trackers (ft2,st3,it2) were based on trance/dance music and thus are absolutely limited in their featureset. Less-complex composers have their BS arguements: "hey as long as it has a heavy distortion filter I'm happy", or "whoaa.. a 303-filter", or worse: "don't mind the features, but oooh look at that cool skin..!" .. *f$ck it* .. those ppl shouldn't ever design anything meant for a generic public
Now, this PC-stuff is *while being the truth* not exactly relevant for the Moonsound development.. I'm just pointing out that only your 'own' experience shouldn't be the key to the design of a tracker.

So, to lighten up a bit .. ( ) .. for *very* advanced tunes, mixing up wave and FM.. the 32 number could be a bit too small.. Think of this: many variations of the same instruments (each a bit different) add a *lot* to the livelyness of the sound. FM and Wave ... so if I'd be able to select a lot of instruments for just 1 part, then I'd get a lot more quality in return. Try to listen to saxophone music for example. No single note is the same, in terms of sound-color, but esp. in terms of articulation. You can do this articulation using several instruments each with a different envelope/LFO. And that's just an example!

The main feature that should complement all this is a global channel-volume, or otherwise an instrument-change command that doesn't initialise the default volume of that instrument.. but I prefer the channel-volume. For the simple reason that in MB/MBwave/MBFM you can't really do all this livelyness-instrument-changes on echo-channels as each instrument-change causes those instruments to be as loud as the lead/direct channel.

$0.02

For once, I agree with wolf

how a memorable day

why would anyone want to use more than 50 voices for a song.. guess 64 is enough then?

Wolf, you do realize ofcourse that now you're going to have to make a song on RealFun with 64 voices

no problem


S: Why not simply the max ? If ppl ask you questions then, you can always say that it's the technical limit.. if you do less, then ppl ask the same questions .. what're you gonna say then? "yeahwell .. dunno '64' sounds nice and such, and I don't need more anyway" ?

of course he could also implement 256 voices, or 65536 voices

I wonder why wolf_ didn't complain about the 2 events per step per channel limit yet Note+Volume+Instr+Command would be nice too have too. Of coz, this will use a lot of memory but ppl could either upgrade ram, use less channels, or use less patterns

Usually 2 events per step is enough .. figure this, for years we're working with 1-event-per-step apps .. ofcourse .. a custom amount of events per step would be even better .. but I wouldn't really mind using max 2 That is, if it's easy to implement more events per step then do so.. and leave it to the user to decide how many events will be used. But I think I wouldn't use more than 2 .. and for some simple channels I wouldn't need more than 1 actually ..

The advantage of local settings (volume/instrument/note/detune/pan on 1 step) compared to global settings (not all of the above events on 1 step) is that you don't need to do a settings-scan. That settings-scan in MB really bugs me.. in the first 8 patterns it's not worth mentioning the time it consumes, but if you're working somewhere at position 100 then you're really f*cked

... and that's where a MSX Turbo R comes in

I've got no personal experiences with MBWAVE (for the simple reason I don't own an OPL4), but I think MB1.4 is fast enough with the settings scan.

Quote:

Usually 2 events per step is enough .. figure this, for years we're working with 1-event-per-step apps .. ofcourse .. a custom amount of events per step would be even better ..

Doesn't Meridian already support a variable (not custom) amount of events?

I don't agree on the 2 events per step thing, btw... I mean, one event per step has some logic to it, but 2 (or more) events is just wasting RAM.

What you need is a variable amount of events per step. That also means 0 events for most of the steps, wow, that's saving a lot of RAM!

Quote:

The advantage of local settings (volume/instrument/note/detune/pan on 1 step) compared to global settings (not all of the above events on 1 step) is that you don't need to do a settings-scan.

Storing all of those settings each step will really eat RAM beyond comprehension ^^;

Quote:

That settings-scan in MB really bugs me.. in the first 8 patterns it's not worth mentioning the time it consumes, but if you're working somewhere at position 100 then you're really f*cked

With some better programming you wouldn't have to wait at all!
It's just one of the things that make MB not scale well...

Quote:

I've got no personal experiences with MBWAVE (for the simple reason I don't own an OPL4), but I think MB1.4 is fast enough with the settings scan.

Due to the increased number of channels the MBWAVE settings scan is about 2.5 times slower.

Quote:

Storing all of those settings each step will really eat RAM beyond comprehension ^^;

prolly yeah .. however.. if:

Quote:

With some better programming you wouldn't have to wait at all!

..won't happen, then we still have to wait, the classic way. Having all events on each step is ofcourse only in edit-mode in the tracker.. and yes, you can asume to need some RAM then .. the song should be saved in user-mode where it automatically scans the songs for 'changes' and creates a new song out of it which looks like the conventional songs.. sortof RLE for those per-step events ..

Quote:

Doesn't Meridian already support a variable (not custom) amount of events?

Don't think so.

Quote:

I don't agree on the 2 events per step thing, btw... I mean, one event per step has some logic to it, but 2 (or more) events is just wasting RAM.

Having 512KB or more RAM in your MSX and not using it, that's wasting RAM. I won't say here how big a song can get in the new Realfun

Quote:

What you need is a variable amount of events per step. That also means 0 events for most of the steps, wow, that's saving a lot of RAM!

But that will slow down the editor... Ofcourse it's possible, it's not even that difficult or something...

Quote:

Quote: That settings-scan in MB really bugs me.. in the first 8 patterns it's not worth mentioning the time it consumes, but if you're working somewhere at position 100 then you're really f*cked With some better programming you wouldn't have to wait at all! It's just one of the things that make MB not scale well...

Realfun scans while you're editing, and remembers old scan results. (But the trail version doesn't, iirc )

Quote:

But that will slow down the editor... Ofcourse it's possible, it's not even that difficult or something...

Indeed, it's not difficult, but maybe it's a lot of work?
And yes, it will slow down the editor, but it doesn't have to slow down so much that you will notice it! We're talking just a few extra milliseconds here.

Quote:

Realfun scans while you're editing, and remembers old scan results. (But the trail version doesn't, iirc )

Nice!