Print

[sverx]

Hi there,
  I'm going to release, I hope in August, a demo of the features of the XM library (beta!) I'm writing for the NDS, so I need some 4 or 5 XMs that will be "packed" into the demo.
I need some of your best tunes, but there are some things you should consider:
1st: there are max 16 channels so your tunes shouldn't use more than 16 channels.
2nd: there's no "sample interpolation" or "volume ramping" so deactivate them in your tracker and check if they still sound good enough.
3rd: it's a beta so it support only few effects yet (8xx, 9xx, Axy, Cxx, EAx, EBx, EEx, Fxx)
4th: XM file size max 1MB, better if <700 KB anyway.

Said that I have to add that instrument volume envelopes are supported and panning envelopes are not... both 8 & 16 bit samples are ok, both forward/ping-pong loop ok... mmm... well, I guess it's everything.

Of course I will give credit to the author(s) and a little space (for a link?) for each tune. What else? yes, my gratitude, of course

Thanks! Ciao!

p.s. ... in the while let's run a survey on what is the most important effect still lacking support... uh?

[raina]

3xx & 4xx for expression, 1xx and 2xx for effect. And the WIP module I was thinking of offering you seems to use EDx for getting drum loop slice timing right.

[sverx]

3xx & 4xx for expression, 1xx and 2xx for effect.

The matter about effects 1xx, 2xx and 3xx is that I didn't find documentation about 'how much' the pitch of the note should be changed... I mean the 'base unit' that -multiplied by the effect value- I have to add/subtract/multiply/divide/dunno to the original/previous value to obtain the new value 

And the WIP module I was thinking of offering you seems to use EDx for getting drum loop slice timing right.

mmm... I'm still not supporting EDx, anyway I'll check later if it's possible to quickly add the support for it and I'll let you know.

Thanks!

[pailes]

The matter about effects 1xx, 2xx and 3xx is that I didn't find documentation about 'how much' the pitch of the note should be changed... I mean the 'base unit' that -multiplied by the effect value- I have to add/subtract/multiply/divide/dunno to the original/previous value to obtain the new value 

There is plenty of information available. Just use google or your favourite code search engine. Or simply download the MilkyTracker source code

[sverx]

I'm still not supporting EDx, anyway I'll check later if it's possible to quickly add the support for it and I'll let you know.

EDx suppport added, I just hope everything else still works... 

There is plenty of information available.

Well, I've already found some but it's still unclear to me. And reading someone else's code is even harder...    ... surely anyway I'll dedicate some more time searching about this argument Thanks

[sverx]

There is plenty of information available.

in the XM format documentation I've found that it says:

Period = 10*12*16*4 - Note*16*4 - FineTune/2;

it means that every 16*4 'period unit' there's a semitone, correct?
So a period unit should be considered as 1/64 of a semitone?
It means that effect 108 (when spd=9) will 'Slide Up' the note of a semitone? (8 period units by 8 times...)

Tell me if I'm in the wrong direction... 

[pailes]

it means that every 16*4 'period unit' there's a semitone, correct?
So a period unit should be considered as 1/64 of a semitone?
It means that effect 108 (when spd=9) will 'Slide Up' the note of a semitone? (8 period units by 8 times...)

It is actually 4*8 not 8*8... You may ask why 4, that has got something to do with the amiga period range in FT2 being 4 times more precise than original Protracker. And since linear and amiga periods are handled in the same way they're both sliding 4*operand. That goes for all slides except for the x-tra fine slide which is just 1*operand.

[sverx]

It is actually 4*8 not 8*8... You may ask why 4, that has got something to do with the amiga period range in FT2 being 4 times more precise than original Protracker. And since linear and amiga periods are handled in the same way they're both sliding 4*operand. That goes for all slides except for the x-tra fine slide which is just 1*operand.

Thanks, but I've read your sentence some 4 times and I still don't understand what you meant :|
Did you mean that one 'period unit' is 1/32 of a semitone (instead of 1/64)? Or did you mean that -say- if I use effect 105 with spd=6 it won't slide of 25 units? :|

Thanks once more!

[pailes]

The period unit (whatever that is supposed to be) is still 1/64 (at least for the linear case). But the increment/decrement on this unit is always the operand from the command*4.

You should forget about that that unit-thingy... There is periods and there is frequencies... to get the frequency you convert the period into the frequency. To slide the period you add/subtract a value to/from the period and that is always 4*operand-value.

and you should always consider that there is an amiga frequency option...

[sverx]

The period unit (whatever that is supposed to be) is still 1/64 (at least for the linear case). But the increment/decrement on this unit is always the operand from the command*4.

I see. So effect 105 slides period of a value 5*4 for each tick, of course skipping tick #0... it sounds like it is meaningful.

You should forget about that that unit-thingy... There is periods and there is frequencies... to get the frequency you convert the period into the frequency. To slide the period you add/subtract a value to/from the period and that is always 4*operand-value.

I've got to confess that I'm not using periods at all. Actually I calculate the frequency value using the 3pla: note number, relative note for the sample and finetune... with 'simple' math and using some precalculated arrays. So I'm trying to avoid the overhead of having everything expressed in periods and to do the conversion each time. After all, isn't that portamento slide just kind of 'dinamic changes' in the finetune value? 

and you should always consider that there is an amiga frequency option...

I'm not considering it at all, in fact. And my plans -at least actually- are that I won't support that. After all I'm not really trying to write an XM Player, there are already good ones, even on NDS, of course you know

Thanks!