and violla, there you have it: overhead (slows down every pattern read action in editor (and there for replayer, or atleast at edit mode))

Having variable patternlength requires malloc, having variable steps requires lots more overhead. I'm just warning for CPU drain.
(oracle uses malloc per pattern and it's slowing down not only the editor but also the replayer) these are just some things to consider.
oh, did I mention you need a good memman for this? To malloc you have to, atleast, allocate buffers of some estimated length. You need a flexible memman for this... the dos thing is just for 16k segments right? so that's out. MemMan? dunno. F-kernel's min. bytes to allocate is 512. that's a nice start for buffering.. perhaps.

Everything is possible, but not everything will run as smooth as required.
but hey, I'd like to be prooved wrong!

Ro, to be honest, I think Oracle is a great example of how *not* to code a music editor .

Well, ok, that's just harsh, and I don't really mean that. But I said earlier that it was clearly coded on and for an R800, and that's pretty much the way I see it. For example, the malloc thing. You say it will be slow. I say nay. If you give each pattern 256 bytes of memory (say that's about 256 events/pattern - yes I know in reality it would be less but that's beside the point), only *once* would you need need to malloc an additional 256-byte block when the user edits a 257th event. As for the rest, the only recurring overhead would be having to check whether there is a 'followup segment' when displaying that pattern. And that's not a very big deal, if you ask me...

And writing a small malloc routine isn't hard either, especially not if you work with fixed-size units such as 256 bytes... You certainly don't need MemMan for that (it sucks anyway). Just keep track of the allocated blocks using a table at the start of each segment, or use a linked list approach for that.

Btw, if you would make a song of 65536 patterns and 256 bytes/pattern, it would fit exactly on a 4MB mapper ;p. Hmm maybe we would need 24-bit pattern numbers then ;p.

Anyways Sjoerd, think I see your point. It's not about feasibility (memory- or speedwise)... It's about code complexity. Adding stuff like MML and dynamic memory allocation is all very well possible, but it takes a lot more time to program. For MSX it's very easy to think like 'oh but if you do this-and-this MSX can do it, no sweat', but if you apply all those small ideas to an entire program in the end it adds up and makes the project a lot bigger.

Anyways, I'm just trying to give my opinions and feedback, so don't take it out on me please. Even if it's not all 100% correct, useful, or whatever. (And don't go all cranky when someone deems some alpha version not very useful yet.) I think this thread is a great way to get input from others about desired functionality (the composers) and ideas to realize certain functionality (the programmers), and discuss pros and cons of several aspects. With that, not everything will always be positive, nor will everyone always agree, but that's life and that's not what the thread is about.


~Grauw

complexity, shmomplexity!

(yeah, orc was written on r800, so? why always stay backy compaty eh. then we could throw away the rusty ol' gfx800 and opl4 for example.. not compatible. but ok.)

hmm, grauw have you ever coded or even looked into a memory manager kinda thingy?
it's overhead. period. like it or not.

It's not just a matter of preserving a few bytes as a buffer and occasionally look into the pointer buffer to check or whatever. esp.when doing variable step lenght...

well, shmomplexity rules
(there has to be a challenge in this.. else it would not be fun eh)

Thing is: There is no other tracker then Oracle that supports variable patternlength and a max of 265 of them. Why is that? why are all other trackers static pat len and we're all yelling to have them anyway? maybe shmomplexity? could be, dunno. Again, this is not to say " hey, I'm GOD cuz I coded that allmighty music editor".. but I trust ya'll know that.
I use this piece to compare. I build it so it's e.z. to do eh.

Still there's demand for a good flexible tracker. But we don't want it to be slow and heavy on memory. Still we all want these great features.... pref for opl3/4 (with good sample editors etc). hmm, maybe in about 10 year? the wishlist is, imo, to heavy for reality. So we've gotta compromise maybe? or let go of old hardware? dunno.
shoot!

Just finish Miracle, ro
And this time add a replayer so we can the music in our soft :\

Quote:

Anyways Sjoerd, think I see your point. It's not about feasibility (memory- or speedwise)... It's about code complexity. Adding stuff like MML and dynamic memory allocation is all very well possible, but it takes a lot more time to program. For MSX it's very easy to think like 'oh but if you do this-and-this MSX can do it, no sweat', but if you apply all those small ideas to an entire program in the end it adds up and makes the project a lot bigger.

Well, as some of you might know I thought of rf2. It was designed somewhat like this: (not exactly like this, because rf2 only had 16 channels )
Step 1 is to recognize tracks are evil, btw. Even the new Realfun doesn’t have tracks. It fakes them. Tracks are only useful for position tables, which are very evil. I don’t like position tables. (But Realfun will have one, of course). Anyway. The rf2 song format:
We have a song consisting of 256 pointers to tracks (let’s call them tracks anyway).
A track consists of 256 pointers to uhm, channelblocks.
A channelblock consists of let’s say 16 pointers to steps. (rf2 didn’t have this step, I thought 16 channels would be enough, what was I thinking? Anyway there’s room for 32 pointers, so 512 channels is very well possible).
A step is here the eventdata for 16 channels on a row.
The ‘RfMM’ memorymanager manages parts of 64 bytes. (4MB memory max per song, 16 bit pointers, 4M/64K=64 bytes). This is where the 4 bytes per step per channel came from J. (64 bytes for 16 cells => 4 bytes/cell). I didn’t want to crunch this any further, because it wouldn’t be useful (the smallest memory chuck being 64 bytes anyway) and to keep the edit functions (notably block functions) fast and relatively easy to program.
This combined with some very complicated (compared to moonblaster/old Realfun) instrument handling (more layers, for example a 2op and a 4op channel at the same time in one instrument, like meridian) made me think: what am I doing?
I mean: I never reached the 256 track limit, 32 channels has always been enough for me, if I want to voices I use two channels, and here I am doing this complicated stuff that no one is going to need.
So: if anyone wants to do this stuff: it’s very well possible (remember: tracks are evil), I have seen it work. It works. Great.
And GuyveR800 would still not be happy with it: 4 bytes/cell limit, only 256 tracks. (Although it’s very easy to make a song of 256 pointers to 256 ‘tracks’ to 256 channelblocks).

Again: 128 tracks of 32 channels and 16 steps per track, 2 events/cell sounds reasonable to me. Even 32 tracks of 32 channels of 64 steps per track sounds nice enough. And that's for a 256KB MSX.

Quote:

Anyways, I'm just trying to give my opinions and feedback, so don't take it out on me please. Even if it's not all 100% correct, useful, or whatever.

I have no problems with that. But some people here have some ‘I know it better’ attitude.

Quote:

(And don't go all cranky when someone deems some alpha version not very useful yet.)

I have about six disks full of songs made with that not-very-useful version. That’s one of the reasons the development wasn’t going that fast anymore: it fitted our needs.

Quote:

I think this thread is a great way to get input from others about desired functionality (the composers) and ideas to realize certain functionality (the programmers), and discuss pros and cons of several aspects. With that, not everything will always be positive, nor will everyone always agree, but that's life and that's not what the thread is about.

True.
But it’s great to know that if GuyveR800 or you, for example, ever makes a tracker it will have 65536 tracks of max. 256 steps, 256 channels, unlimited events per cell ( ), 256 voices with unlimited layers/elements and that it will be as fast as, well, name something very fast.

Quote:

Thing is: There is no other tracker then Oracle that supports variable patternlength and a max of 265 of them.

Oh, koustracker had it. Sure, it only had 11 channels in total (fm-pac w/drums), but still... Ran like a breeze.

Quote:

extended description of rf2

Sounds nice. Funny to see btw that your approach to bending the limits is quite different from what I would do.

Quote:

And GuyveR800 would still not be happy with it

Heh, wasn't I the one bitching about limits?

In any case, I think the 'virtual channels' stuff Wolf mentioned is pretty cool, and I can see a very distinct use in many-events-per-step as well. Fact is, I took a look at Koustracker just recently, and it very often has more than two, sometimes even something like 8 events per step. In particular at the beginning of a song (initialization) or on an instrument change, of course, plus that it also uses a seperate event to change the octave, etc... But still, I can imagine when changing an instrument you would also want to change the volume, the LFO, and still be able to change the 'x-factor' (;p) (I am referring to the FM thing that makes the colour of the sound change).

So, why not speculate about it (or let me speculate about it, if it's a non-issue for you), instead of answering with dripping sarcasm and two referrals to Guyver in every sentence when you're replying to a message of mine.


~Grauw "grumpy, must be the rain"

Quote:

And GuyveR800 would still not be happy with it: 4 bytes/cell limit, only 256 tracks. (Although it’s very easy to make a song of 256 pointers to 256 ‘tracks’ to 256 channelblocks).

Actually I'd be happy with anything that's better and faster than Moonblaster.

Quote:

But it’s great to know that if GuyveR800 or you, for example, ever makes a tracker it will have 65536 tracks of max. 256 steps, 256 channels, unlimited events per cell ( ), 256 voices with unlimited layers/elements and that it will be as fast as, well, name something very fast.

Hey, I never said anything about layers
Seriously though, layers is just an editor feature, it has little to do with a replayer (if 'properly'* coded).

*note the properly is in quotations, with that I mean my personal idea of how it should be programmed. I don't claim that it's the ONLY proper way.

Quote:

In any case, I think the 'virtual channels' stuff Wolf mentioned is pretty cool

Virtual channels may have their use, but without dynamic memory allocating system, it takes too much memory to have over 32 channels.

Quote:

and I can see a very distinct use in many-events-per-step as well.

But many-events-per-step will slow down the editor OR create lots of overhead. And it complicates the editor a lot.

Quote:

In particular at the beginning of a song (initialization) or on an instrument change

With variable lenght events you wouldn't need instruments anyway, you could put the instrumentdata in the event-stream, meaning an unlimited amout of FM instruments.

Quote:

So, why not speculate about it (or let me speculate about it, if it's a non-issue for you), instead of answering with dripping sarcasm and two referrals to Guyver in every sentence when you're replying to a message of mine.

Of course we can speculate about this, but telling me my design sucks because... blablabla. That's just not the way to do it. It doesn't suck, it fits its purpose.
And I quoted several massages, and removed quite a few until only yours remained

Quote:

Actually I'd be happy with anything that's better and faster than Moonblaster.

Me too.

Quote:

Hey, I never said anything about layers.

I know, but I have some wishes too

Quote:

Seriously though, layers is just an editor feature, it has little to do with a replayer (if 'properly'* coded).

True, but when I think of Realfun, I think of an editor. And it complicates the editor quite a lot, at least the way I wanted to do it. The replayer is something completly different.

Quote:

Quote: Seriously though, layers is just an editor feature, it has little to do with a replayer (if 'properly'* coded). True, but when I think of Realfun, I think of an editor.

That's a difference between our approaches. I think more along the lines of the replayer, since that ultimately has to have the features and speed. I think of an editor just as a front-end for the compiler.

To me, the editor can be anything. A tracker, a MML editor, or nothing at all (edit music with TED ^_^). The player is what matters most. Afterall, a tracker without a player (*cough*oracle*cough*) is useless when you want to play music during your game/demo/product.