RealFun

Pagina 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12

Van Grauw

Ascended (10605)

afbeelding van Grauw

08-08-2004, 17:27

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 Smile. But that's stating the obvious I guess.

~Grauw

Van sjoerd

Hero (602)

afbeelding van sjoerd

08-08-2004, 17:44

I like limits Smile

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)
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.
Max. nr of channels? 256 would make sense, but any other limit...256 makes sense? 16 makes more sense to me Smile The only use of more channels is having to use less instrument changes.
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.
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.
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.
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.
And as long as it uses some kind of 'compressed' format for its standalone replayer . But that's stating the obvious I guess.Yes.

Van ro

Scribe (4715)

afbeelding van ro

08-08-2004, 18:10

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.

Van wolf_

Ambassador_ (9972)

afbeelding van wolf_

08-08-2004, 18:32

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 Smile ) .

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 Smile

Van sjoerd

Hero (602)

afbeelding van sjoerd

08-08-2004, 19:16

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.

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

08-08-2004, 19:19

I agree with Grauw here...

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!

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 Smile
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).

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!!!

Van sjoerd

Hero (602)

afbeelding van sjoerd

08-08-2004, 19:51

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?
That qualifies as a bad design in my eyes Smile
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.
Variable event sizes really are no problem, if your design is good.Sure.
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.
Limits suck!!!But the limits will always rule!

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

08-08-2004, 20:39

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.

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.

Limits suck!!!But the limits will always rule!No, you have to know how to get around them, that's all.

Van sjoerd

Hero (602)

afbeelding van sjoerd

08-08-2004, 21:05

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 Smile You just can't expect 65536 tracks with 128KB RAM.
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. :D 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.
No, you have to know how to get around them, that's all.I ignore limits like they do not exist ;)

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

08-08-2004, 21:13

Your design does not scale well, the numbers prove it.
You just have to scale the memory requirements with it Smile 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!

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 Smile
Why would you need two versions of the same tracker?! That's not very efficient, is it...

I ignore limits like they do not exist Wink
No you don't, you create useless limits yourself and then say they are caused by technical issues.

Pagina 7/12
1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12