Quote:

Quote: Those are your words, not mine... You mean there are other limits that make Realfun useless?

Don't be so childish man... I never said anything about Realfun being useless.
It doesn't even exist, so it can neither be useful nor useless

I said the limits you created yourself are useless. Limits that you can't get around of (like the 8 sprite/line limit) are the only limits you should limit yourself to.

Quote:

(sorry man, I'm being a bit harsh at the moment.. gheh)

Hi Ro!

Quote:

Don't be so childish man... I never said anything about Realfun being useless. It doesn't even exist, so it can neither be useful nor useless

You said something like 'the trail version is unusable' om #msxdev

Quote:

I said the limits you created yourself are useless. Limits that you can't get around of (like the 8 sprite/line limit) are the only limits you should limit yourself to.

I think the limits are realistic. Let's just wait until it is finished, because this gets us nowhere. I am not changing the design, I looked at a lot of options, and the current design looks 'good enough' to me

Ey, something else, for instance: wot about a promo version? Thus far, I've only heard of capabilities, possible capabilities and the uselessness of Realfun, but I'd really like to actually see the darn thing . Not that I'm a composer or such, but you know, just curious

uh .. there was a probeerversie .. some while ago .. is it somewhere to DL ?

Uhm, yes, there exists a so-called 'probeerversie'. It looks different but you'll get the idea. The new version will work the same as much as possible. I will upload it to www.xl2s.tk.
I thought everyone interested would have it by now

16 channels... yikes, that's even less than moonblaster. But for those 16 one can at least use both wave and fm-channels right? (um, sorry if it came up earlier in one of the 6 pages of this thread, I didn't read them all -_-;.

Anyways, thinking speed-wise, I really really wouldn't bother about the speed. Z80 can keep up, sure thing. Don't look at Oracle too much, it was obviously coded for R800 and it was coded like an R800 program. If you optimize a little here and there, don't do extremely difficult calculation stuff...

Things like variable number of events per step ('cell'?), it's easy, just check for events until you run into the terminator. And if because of that you can't index very well anymore here and there, start using a lookup table instead. If editing a pattern runs into speed issues (tho I really can't imagine that, seeing that you are dealing with a, from a computer's perspective, infinitely slow user response), why not 'render' that pattern into an 'editing-buffer' of some kind, and convert it back if you go to another pattern? And for the sake of speed don't 'render' the pattern until the user actually starts editing it.

If you just do some stuff like that, the Z80 can really handle everything.

Quote:

Even empty events take some time, to see they're empty and to skip them...

No they do NOT take 'some time'. They take about zero time on the scope of all the rest.

Quote:

But Realfun only has 16 or 32 channels because of the memory it takes, speed isn't the problem indeed.

Then don't put your data in memory too straightforward (meaning x bytes for every step in every channel in every pattern). Use some kind of MML-ish storage format, and reserve a fixed number of bytes for each pattern and dynamically allocate more when it is needed because too much stuff is happening. Just like speed, memory can imho not really be an issue.

As for the '16 fits on my screen' thing... right, I have to agree with Ro that that's a pretty lame argument . But anyways, it can't hurt to work with that as a base for now, of course, as long as you're not fixed on the idea and are thinking about changing that when everything else is in working order and pretty much done for the time being. In other words, start expanding the capabilities beyond the original design after you reached the first stable release (or uh, something). OTOH, the better the first release, the more people are going to be impressed, of course .

Anyway, like many of the programmers here I too have my very distinct outlines of a music program I would like to create... It seems music programs are somehow a popular subject for programmers... ^_^ Mine is going to be pretty much limitless, yet compact and fast. Based on MML, but presented to the user in a tracker format. Not that I will actually ever start working on it, of course ;p.


~Grauw

Quote:

16 channels... yikes, that's even less than moonblaster.

You can choose between 16 or 32 channels.

Quote:

Things like variable number of events per step ('cell'?), it's easy, just check for events until you run into the terminator...

Just using the memory and storing data the 'dumb' way is easier, and faster. I am not going to make something very complicated when the easy (lazy?) solution works just as well. Sure, 256 channels, very impressive. But who needs them? It reduces instrument changes, but that's it. Sure, 65536 tracks, impressive. But really, who needs that?

Quote:

Quote: Even empty events take some time, to see they're empty and to skip them... No they do NOT take 'some time'. They take about zero time on the scope of all the rest.

True. But optimizing the whole thing and skipping about 200 empty steps... All things help.

Quote:

Quote: But Realfun only has 16 or 32 channels because of the memory it takes, speed isn't the problem indeed. Then don't put your data in memory too straightforward (meaning x bytes for every step in every channel in every pattern)..... Just like speed, memory can imho not really be an issue.

I like easy solutions. I thought of MML-ish solutions, and it's not really worth the hassle. IMHO ofcourse. I have 1MB RAM in my MSX, and I am going to use it.

Quote:

As for the '16 fits on my screen' thing... right, I have to agree with Ro that that's a pretty lame argument .

Well, it isn't an argument, just a statement. I don't like scrolling in trackers, but Realfun will scroll. I don't need 64 voices, but Realfun will have 64 voices per song. Realfun will not have a 16 steps per track limit.

Quote:

But anyways, it can't hurt to work with that as a base for now, of course, as long as you're not fixed on the idea and are thinking about changing that when everything else is in working order and pretty much done for the time being...

I could always implement my original rf2 ideas somewhere in the future.

Quote:

Anyway, like many of the programmers here I too have my very distinct outlines of a music program I would like to create...

Yes, it's not that difficult to come up with some very impressive specs and limits-that-aren't, but the program has to be implemented also.
I don't think 128 tracks of 32 channels with 16 steps is that limited for a 256KB MSX. When I hear a lot of complaint from users, and see (or hear, ofcourse) that there are limits reached that shouldn't be there, that's the time to do something about it. Not when someone says: Hey, 2 bytes is a word, uhm, 65536 tracks should be possible. MSX isn't 32 bits guys. Or: 16 steps per track is stupid. So what? Who cares about tracks anyway? It's just a long list of steps (no-one here really likes position tables, right?)

FastTracker2 (Hi wolf_!) hadn't the limitation of 16 steps/pattern either. I suggest you take a look at that program! It's really great , furtermore, look at the way of adding effects to a step, a note, a volume change, a detuning action, etc...

You can't be serious about 'linking' *me* to ft2

Well, you named it along with ST3, IIRC... Dunno where exactly... Could be in this thread

Hey, did I say I linked you with FT2? *I* find it a great program, personally... Don't you?

Sjoerd: you're great. I downloaded your program (gotta see it still, though), but I really admire the way how you put it online. A zipped diskimage and zipped files
[hint]That's what MRC could do, too[/hint]



I'll let you know what I think of the trial version A.S.A.P.

Uhh... It doesn't boot quite well in NLMSX :|

I read the readthis.txt file, but when I ran 'RF.COM', it simply said 'no opl4 found', while I have a Moonsound enabled!

/me cries...

bug! either in RF or NLMSX, who knows.. At least it works on blueMSX...

Quote:

You said something like 'the trail version is unusable' om #msxdev

So? Didn't you learn the difference between 'unusable' and 'useless'?
unusable = has a use, but can't actually be used (well enough)
useless = has no use