Look! I got this great piec'a music, but I had to rewrite it cuz the score wouldn't fit one 1 size A4 paper.. and you know how I hate to swap around pages...

anyway... 'murning guyz.

Quote:

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

Oh, yes, you're right as always GuyveR800. Good for you.

Quote:

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

It also works on openMSX. And more important: it works on my real MSX. There are quite some bugs in RF, but to find them, use a real msx.
Anyway, thanks for trying.

Quote:

Oh, yes, you're right as always GuyveR800. Good for you.

It's not so good for me if I have to explain every word I use, just so you won't put other words in my mouth later!

BTW, was it your intention to ruin your own thread with sarcasm? Because IMO you succeeded in that, quite a feat!

guys....

Quote:

Quote: bug! either in RF or NLMSX, who knows.. At least it works on blueMSX... It also works on openMSX. And more important: it works on my real MSX. There are quite some bugs in RF, but to find them, use a real msx. Anyway, thanks for trying.

Uhh... I was curious about it, so I tried it in an emulator, cos I don't have a OPL4

You could try it in another emulator

Quote:

It's not so good for me if I have to explain every word I use, just so you won't put other words in my mouth later!

We are communicating in English here, and I am not that good at English (nor communicating ). Just don't try to outsmart me there. Just try a bit harder to see what I mean; I do the same for you.
Just saying my design sucks because of some limits that aren't going to be reached, or because in theory everything is possible has no use at all. Of course there are other designs possible, but are they better? It depends on more than just memory requirements, or some limitations, or who designed it.

Quote:

BTW, was it your intention to ruin your own thread with sarcasm? Because IMO you succeeded in that, quite a feat!

Wolf started this thread, who am I to take it over?

But what are we doing here? This gets us nowhere Not that I want to go anywhere with you, but...

I guess we all just want a tracker better than Moonblaster, well, I think Realfun will be at least a bit better.

If anyone would come up with some arguments (other than it should be possible) to support 256 channels, 65536 tracks, 256 instruments, unlimited events per step, 65536 steps per track and so on, I will be happy to listen to them.
But sometimes good enough is best.

Like you said:

Quote:

I guess we'll just have to wait for what you come up with, and see if that'll be sufficient.

Quote:

But sometimes good enough is best.

Sounds optimistic:

You can try the best you can
You can try the best you can
The best you can is good enough

Quote:

Just try a bit harder to see what I mean; I do the same for you.

Doing the same for me is accusing me of saying RF is useless?

Anyway, 'Unlimited' events per step is a necessity. (although in practice 4 to 10 will be fine, depending on the different number of events available)

When composing it's common to want to start a note and an instrument change at the same time. It's also common to want to start a note and a pitch bend at the same time.
Now what if you want to start a note, with a pitchbend and a new instrument? That's 3 events, and you really want them to happen at once, otherwise you'll need to work around the limit somehow, which is not nice for the composer..

Flexibility is key here. But hey, it's your program, you can do with it what you want.
If I were you I would listen to the requests of the people that will actually use your program, but it's not an obligation.

Quote:

Doing the same for me is accusing me of saying RF is useless?

unusable/useless, the result is the same: you can't use it.

Quote:

Anyway, 'Unlimited' events per step is a necessity. (although in practice 4 to 10 will be fine, depending on the different number of events available)

This is indeed a problem, but it's easy to work around it. That isn't the ideal solution, of course. But allowing more events per step will complicate the design very much.

Quote:

If I were you I would listen to the requests of the people that will actually use your program, but it's not an obligation.

I do listen to requests. Mainly from people actually using the old version, but also from this forum, and email: 16 -> 32 channels, 32 -> 64 voices, scrollable edit window. What more do you want? OK, unlimited events per step. Maybe in the next version...

b'coz variable step commands is indeed a bit of a hard thing to accomplish on coop with EDIT speed, visuality and more. How about a few "pre defined commands" where you can pre-set more than 1 command.

like C#4 p01

where p01 = preset 01 and:

preset 01 contains: Instrument, Volume, Tuning and Arpegio settings for example?

That'l make coding such system easier I think

hm.. dunno about that.. it's again the complex vs. non-complex issue .. I don't think I'd want to remember some 50+ macros

what about this:

each channel is made out of 2 channels (visually) a note channel and a 'modifier' channel .. the functionality of the option-channel can change .. or cycle if you wish. You can put everything there.. instru.changes, volume-changes, pitchbends etc. etc. So, visually and internally this option-channel can be limitless (up to a certain level) while it still doesn't mess-up the screen .. you can cycle through the option-channel by some key(s)..

it's the memory set up that will be tricky. (it's like inserting bytes.. unless you preserver a row which consumes more mem. see the dilemma?)

The presets aren't that bad (name them).. you also preset instrument data don't ya? (instead of inserting opl data in your channel)

Memory setup is easy enough... I honestly don't understand what's tricky about it.
The only thing you have to do is step off from the 'store whole patterns at once' design. And then implement some kind of malloc structure.