It's more work than just storing the steps the ram-wasting-way, that's for sure I don't think you'll notice a difference while editing individual steps, but block functions will be a lot slower.

I don't see why one would want to create a tracker with limits... Stuff like two events/step? why limit it at all? Max. nr of channels? 256 would make sense, but any other limit... Nr of patterns? 65536 max sounds pretty much unlimited. There is of course usually always a limit unless you want to encode your values in some awkward format instead of just bytes/words, but really, just put it beyond any imaginable boundary and no-one will ever run into them.

I don't see how speed can be an issue. And as far as memory is concerned... So what if songs with loads of channels and tracks won't fit in the editor's memory (as long as it works with less). And as long as it uses some kind of 'compressed' format for its standalone replayer . But that's stating the obvious I guess.


~Grauw

I like limits

Quote:

I don't see why one would want to create a tracker with limits...

A MSX computer has it's limits. (memory and speed, but mainly memory)

Quote:

Stuff like two events/step? why limit it at all?

Because of it's design. Realfun just uses channels x steps x event per step bytes to store the data.

Quote:

Max. nr of channels? 256 would make sense, but any other limit...

256 makes sense? 16 makes more sense to me The only use of more channels is having to use less instrument changes.

Quote:

Nr of patterns? 65536 max sounds pretty much unlimited.

Yes, 65536 sounds pretty unlimited. But I really don't think anyone will reach the maximum songlength in Realfun.

Quote:

There is of course usually always a limit unless you want to encode your values in some awkward format instead of just bytes/words, but really, just put it beyond any imaginable boundary and no-one will ever run into them.

I am happy as long I don't run into them.

Quote:

I don't see how speed can be an issue.

I like fast editors. Channels and tracks don't matter, but variable event sizes do.

Quote:

And as far as memory is concerned... So what if songs with loads of channels and tracks won't fit in the editor's memory (as long as it works with less).

Indeed, I couldn't care less.

Quote:

And as long as it uses some kind of 'compressed' format for its standalone replayer . But that's stating the obvious I guess.

Yes.

wel, grauw, speed is an issue on calculations. think BYTES v.s. WORDS for one.
memory swapping, pointer buffers and yadayada. you have to set a limit.
however not as wicked as MB did for instance...
why not:
- variable tracks (aka channel) 0-31 (32 is pretty much the limit for your cpu to still have it running smooth on any int.)
- variable measures (aka steps aka pattern length) 0-255 (so a 7/8 measured song would be a bit simpler to write out). Each pattern should be variable in length
- 256 positions might be enough, considering longer pattern lengths
- 32 instruments would do I think (might be ANY: psg, fm, wave, scc whatever)

etc.

I keep reading stuff like the max amount of channels in regard to cpu time ..


afaik, only events take cpu time.. once a channel is playing, it keeps on playing by itself. So, even on a humble 3.5mhz msx2, 18+24 would be no problem if the composer can force himself not to use too many events on a row. So, if you have 20 channels playing something.. (looped instruments) then they won't take up cpu time .. (unless I'm badly informed ofcourse ) .

So, rather than speaking about the number of simultanious channels, rather speak of the number of simultanious events.


and Ro: 32 instruments won't do for big/complex/advanced/detailed songs

Even empty events take some time, to see they're empty and to skip them... But Realfun only has 16 or 32 channels because of the memory it takes, speed isn't the problem indeed.

I agree with Grauw here...

Quote:

A MSX computer has it's limits. (memory and speed, but mainly memory)

4MB is quite a high limit, and that's just ONE mapper, you could use more!

Quote:

Because of it's design. Realfun just uses channels x steps x event per step bytes to store the data.

That qualifies as a bad design in my eyes
It's good enough for 9 channel stuff, but as you reach the capabilities of Moonsound, such a design just not scales well (in speed and in memory).

Quote:

I like fast editors. Channels and tracks don't matter, but variable event sizes do.

Variable event sizes really are no problem, if your design is good.

I don't like the limits that a fixed number of steps has either. I hate having to temporarily increase the tempo, and there's always a problem of finding the right tempo...
And that brings us to the limits of fixed tempo's, it really sucks...

Good thing MBWAVE supports the base frequency by using the Moonsound interrupt generator, but other chips should also have more flexible tempo settings. It's possible, and not hard too...

Limits suck!!!

Quote:

4MB is quite a high limit, and that's just ONE mapper, you could use more!

Yes, but how many MSX computers are there out there with much memory?

Quote:

That qualifies as a bad design in my eyes It's good enough for 9 channel stuff, but as you reach the capabilities of Moonsound, such a design just not scales well (in speed and in memory).

It qualifies as good enough design in my eyes. And what capabilities of the MoonSound?
It is possible to scale this design to 256 channels and 65536 tracks or whatever, very easily. Even variable event sizes aren't a real problem, you just need some memory.

Quote:

Variable event sizes really are no problem, if your design is good.

Sure.

Quote:

I don't like the limits that a fixed number of steps has either.

I like 16 steps per track, because the whole track fits on one screen.

Quote:

Limits suck!!!

But the limits will always rule!

Quote:

Quote: 4MB is quite a high limit, and that's just ONE mapper, you could use more! Yes, but how many MSX computers are there out there with much memory? *snip* It is possible to scale this design to 256 channels and 65536 tracks or whatever, very easily. Even variable event sizes aren't a real problem, you just need some memory.

256 channels x 65536 tracks x 2 bytes per step x 16 = 512 MegaByte.
Didn't you just doubt how many MSX computers had 4MB, let alone more than that!
Your design does not scale well, the numbers prove it.

Quote:

Quote: I don't like the limits that a fixed number of steps has either. I like 16 steps per track, because the whole track fits on one screen.

I can fit much more on my Gfx9000... And using a smaller font helps too.

Quote:

Quote: Limits suck!!! But the limits will always rule!

No, you have to know how to get around them, that's all.

Quote:

256 channels x 65536 tracks x 2 bytes per step x 16 = 512 MegaByte. Didn't you just doubt how many MSX computers had 4MB, let alone more than that! Your design does not scale well, the numbers prove it.

You just have to scale the memory requirements with it You just can't expect 65536 tracks with 128KB RAM.

Quote:

I can fit much more on my Gfx9000... And using a smaller font helps too.

I thought of using the GFX9000, but I went like: hey, 16 steps is enough, why two versions of the same tracker, who cares about GFX9000 anyway (Oh, wait, I do. Please all go to www.xl2s.tk to get the new wallpaper of our gfx9000 game! To be finished around 2017, but we may release the first chapter earlier, haha)
And smaller fonts on my msx screen? No thank you.

Quote:

No, you have to know how to get around them, that's all.

I ignore limits like they do not exist

Quote:

Quote: Your design does not scale well, the numbers prove it. You just have to scale the memory requirements with it You just can't expect 65536 tracks with 128KB RAM.

A well-scaling design doesn't NEED to scale the memory linearly. That's the whole point of 'scaling well'. Ignoring the numbers does not make your program better.
65536 tracks with 128kB RAM is indeed not to be expected, but 4MB should be enough for 65536 tracks!

Quote:

I thought of using the GFX9000, but I went like: hey, 16 steps is enough, why two versions of the same tracker, who cares about GFX9000 anyway

Why would you need two versions of the same tracker?! That's not very efficient, is it...

Quote:

I ignore limits like they do not exist

No you don't, you create useless limits yourself and then say they are caused by technical issues.

Quote:

A well-scaling design doesn't NEED to scale the memory linearly. That's the whole point of 'scaling well'. Ignoring the numbers does not make your program better.

It doesn't? Bummer.

Quote:

65536 tracks with 128kB RAM is indeed not to be expected, but 4MB should be enough for 65536 tracks!

640KB Should be enough for everybody.

Quote:

Why would you need two versions of the same tracker?! That's not very efficient, is it...

Exactly my thought So no GFX9000 support...

Quote:

No you don't, you create useless limits yourself and then say they are caused by technical issues.

Sure, a limit of 32 channels makes Realfun useless.

Quote:

Quote: Why would you need two versions of the same tracker?! That's not very efficient, is it... Exactly my thought So no GFX9000 support...

You know damn well that I meant it's easy to integrate in one single program.

Quote:

Sure, a limit of 32 channels makes Realfun useless.

Those are your words, not mine...

"I like 16 steps cuz it fits nicely on screen" might be the dumbest argument on this topic which one might come up with (no hard feeling Sjoerd )
I mean you wanna make a good solid tracker but can't deliver the goods just b'cuz it don't fit on screen? what thu f*** LMAO dude
(sorry man, I'm being a bit harsh at the moment.. gheh)

just scroll the darn screen. Check ORACLE and see how it's dun. period. (orc scroll both vertically as horizontally.. no biggy)
indeed shove them limits (well to a limit that is)
Again, this is not advertising but so many thing talked about here are already build in earlier named music editor. So it can be done and works okay. On the other hand it sucks up memory and cpu (yes it does)
so we have to compromise maybe dunno.

well, I had my 2c around for a few minutes, here u 'ave'm

Quote:

You know damn well that I meant it's easy to integrate in one single program.

I know. It's not that easy though, and it takes quite some memory. I just don't think it's worth the effort.

Quote:

Quote: Sure, a limit of 32 channels makes Realfun useless. Those are your words, not mine...

You mean there are other limits that make Realfun useless?