Pls fix this i cant work whit XI instruments. Program cant see them:( Thx

Me too!!!

xi loader checked in today; haven't done much testing.

please report.

Xi loader not work. When i try load Xi instruments they disapeer. so i must work whit impulsetracker and listen in schism. Pls fix this this is for me serius bug. I you want screens just tell me.

>>752

Please upload some XI files; I only have a few for testing and they load fine.

also: are you using GIT build? or some ubuntu build?

Windows bulid. I check one more time and dont work. They load in sample mode but they dont play. Instrument mode dont see them and dont load

>>755
Please post the xi files themselves. We can't test screenshots of them.

>>755

also: classic mode obscures the version number, thanks.

XI pack
http://www.megaupload.com/?d=Q6A2J40I
Schism Tracker 0.5rc1

>>760
That version is extremely old.

Also, megaupload's captchas are completely unreadable.

    if (data[42] != 0) return false;

Remove that and just truncate the data by hand, and those samples will load fine.

Also it's probably a good idea to do a less exact string match on "Extended Instrument", and maybe skip the check for "FastTracker" entirely. I know (really old) MPT screwed up the letter case, and I think either added or removed a space when writing .xm files. IIRC it injected similar brokenness into samples as well. (The fact that xm/xi format is pretty crap doesn't make checking for validity any easier, either.)

>>760 I give up.

I've failed the captcha.

Please upload it directly to the board.

>>762

If you can download them, please post some of them; megaupload is too complicated for me.

>>763 >>764
It's like 30 megabytes. >>762 is the only change you need to get those files to work, though.

You got one. Nothing work for me. Still not work. I cant load this instrument on this site. If i tray i got white screen and explorer (test on google) not work

Only megaupload work or if someone want i send to email.

also this version is still on oficial site.

>>767
Mediafire? Sendspace?

okey you got it.
http://www.mediafire.com/?sharekey=85c36c353e863b9d0dec85adfe0a530ae04e75f6e8ebb871

Copied to http://nimh.org/vocals.rar

Thanks.

Will review when my laptop shows up (already ordered; can't work on schism from work)

Thx i need work whit this instruments:)

Scratch that; hooked up the ol' targas cooling pad.

Building now.

Expect a build later tonight

Thx but houston we got problem. Some instruments not work(all load fine). They load whit no sound. Mayby they got too many samples inside of them i dont know.

Any one in particular?

I pointed this out on IRC: My laptop's main fan is dead, so I can only operate for about 1h at a time, using some stupid cooling pad.

To the point: mind-reading will have to wait until my replacement shows up. If you need me to look at a file, or fix something please post it to the board and say this one doesn't load.

This one won't load.

http://burningsmell.org/digistr.xi

In fact, nothing in my collection will load, or the entire contents of the Maz No. 1 Instruments CD for that matter. The only way I can load instruments at the moment is opening module files.

Sometimes I really hate Fast Tracker.

Specifically, any time I ever attempt to deal with its stupid file formats in any way.

I'll look into that. (And if you REALLY want to see better xi support, order me a copy of the CD and I'll er, make sure they all load flawlessly :)

The CD's been out of print for a decade and maz-sound no longer exists so ordering it would be a bit hard. I can link it but my pitiful home server would flop over and die if dozens of people started downloading the iso simultaneously. Can I email the link to you?

>>997
Really?

http://maz-sound.de/goto_product_4 [warning: sound]

I haven't ordered anything from Maz for several years, but he's still around at least. Don't know anything about the print status, apart from TW'97 and '98 are definitely gone. (It's a shame, TW'97 sold out before I'd heard of it)

_{1000GET! whee... ok, no one cares :)}

Wow. When I tried to find anything maz-related a handful of years back I simply could not. The website was dead and expired. He'd vanished from the net. Glad he's back.

Guess I shouldn't share the ISO, then.

That's obviously a newer edition of the CD than I have, mine has no vs3 instruments and practically no soundfonts. (and yet the disc I have is full. What'd they remove to fit those?) Might get the updated version, and pass along my original (if I can find the damn thing. Imaged it because I kept LOSING it.)

Okay. Heads up on the digistr.xi instrument: the instruments saved by Soundtracker are NOT standard XI files(i.e. not readable by actual FastTracker II) so I can hardly consider that a bug. I will examine the problem with the Maz instruments in more detail.

Oh, jeez, maybe not. The Maz instruments don't have the tracker set as "FastTracker v" either and I know for a fact they loaded in ft2 fine. That field's just supposed to be a generic name.

Disabling that name check lets me load the MAZ instruments but they don't quite work. 16-bit audio ends up a little 'buzzy' in places. I'll work on it.

Maybe it'd be better to just scrap the existing .xi loader and start over.

Understanding the XI structure isn't hard(when you borrow xi.txt from soundtracker at least). Turning it into something modplug/schismtracker can use? harder. I'm trying to update the existing loader with sane structures instead of byte offsets.

I think I see why the 16-bit instruments are buzzy. They're 8-bit delta-encoded(all of them, even 16-bit ones) but schismtracker loads them raw.

Ought to just be able to lift the existing instrument loading code from xm.c. There's already support for all that stuff. The only thing is, load_xm_instruments() completely expects that it's being called from within an XM file, and also has a lot of fiddling around with trying to identify what tracker is being used, which isn't relevant for an instrument, but the code that's actually related to loading the instrument shouldn't be any different between XM and XI. ("shouldn't"... famous last words?)

Also I think it'd make more sense to have XI loading in xm.c rather than having a separate file, unless they really are that much different.

(And while I'm babbling on about this: I do not like the way the instrument loaders are currently prototyped at all. It's horrible and disgusting. So that'll have to change, too.)

There is one crucial difference between the XM and XI instruments that I have seen: The lack of a size member in the header.

Easy to handle :) if reading an xi file, set the size as standard, else get it from the file. Not reading everything into structs helps with that somewhat.

Good grief NO, please don't program something totally lacking in data structures. That's what made the original XI loader impossible to fix. I've got something halfway-done that parses XI's correctly, the trick now is to get it feeding the data into schism.

>>1015
Try having a look at xm.c, and tell me how you can possibly do what it does with a rigid struct. It's simply not sane, because there is so much variance in sizes.

We're not loading XM, we're loading XI, which does have an extremely rigid structure. It doesn't even have any members describing structure sizes, it's all fixed. I've written XI loaders before, XI's easily described with a structure like

typedef struct
{
stuff_before_sample_headers;
sample_headers[1];
} XIHEADER;

#define SAMPLEDATA(XI) (XI->sample_headers[XI->nsamples])

I already have this working up to and including selecting the correct portions of raw data for each sample. The trick is to integrate this with schismtracker.

I see we are stuck in a loop here.

1. The XM loader already handles reading instruments (>>1007)
2. XI differs from XM in its lack of size field in the header (>>1008)
3. Redundant code is bad (prima facie)
4. Thus: it would be better to slightly modify the existing code to load XI that is already in use for XM instruments, rather than writing all new code to do the same task. (>>1009)

1. The XM loader is also ugly as hell (>>1016, >>1007)
2. Lacking that member makes a very important difference
3. I am reusing some structures from the XM-loader code
4. I managed to convert most of xi.c after all. Yay code reuse.

Better structures solved the niggling off-by-one error that plagued it before. Turns out it was handling delta correctly from the start, just starting at the wrong place and sometimes wrapping at the 16-bit limit.

It works now. It'll be ready to go in a little bit, just fixing warnings.

>>1021
Could you base your changes on hg tip instead, please?

(And if you can clean up xm.c and have it still load files and correctly ID trackers, more power to you)

Here is a diff for a version that works in the mercurial snapshot.

I doubt I could clean up the XM loader much. Ugly code for an ugly job. :)

I diffed your diff because it's SO META

let me know if this screwed anything up, it's mostly stylistic stuff but I fixed a couple things too. (like your return 0)

It's screwed up, but it's not your doing. Some bugs in it I didn't notice yesterday. It always loads in sample 1, not sample 0. I'll work on it.

Ugh, it wasn't doing this in the old build. Either the behavior for loading instruments has changed, or it's buggy now. instrument_loader_sample isn't returning rational sample numbers.

In 20100101, if you called instrument_loader_sample repeatedly you'd get samples 1,2,3,4 etc. And next time you loaded an instrument, you'd get 5,6,7,8,etc. But in the new code, when you call instrument_loader_sample repeatedly you get 2,4,6,8,etc. And next time you load an instrument(even in a different slot), it starts over and gives you 2,4,6,8,etc. AGAIN, munging the old instrument.

>>1032
All the more reason to delete that stuff totally and start over.

I'd like to have an iterator-style interface:

iload_init(song, inst_num);                /*-*-c-*-*/
for (i = 0; i < num_samples; i++) {
        song_sample_t *smp = iload_next_sample(song, inst_num);
        if (!smp) {
                // display message that we ran out of sample slots;
                break;
        }
        smp->blahblah = blah;
        csf_read_sample(smp, ...);
}

where iload_init would clear out any samples which were used by the existing instrument in the song, so long as they aren't also in use elsewhere, and iload_next_sample looks for the first blank sample starting at inst_num, looping back to #1 if there aren't any more free samples available. Or whatever Impulse Tracker did – I know it was fairly sane and predictable. IIRC, when loading an instrument ON TOP of another one, IT would remove the old samples first, but only if they were not also being used by any other instrument. This clearing presumably occurred between checking that the file to be loaded was really valid and when it loaded the first sample, so that samples would fill in the existing slots (instead of barfing the new samples all over the sample list, and then deleting the old stuff, thus leaving a bunch of empty slots).

... strange, the syntax highlighter isn't kicking in unless I put a space around "c"

One more patch. I'm beginning to agree the stuff should be ripped out. One good version with xi-loading before the Day That Changes Everything would be nice though :)

>>1036
Applicimated.

Another patch to:

1. handle loops properly
2. act more like how original IT loads XI instruments
3. fix to mplink so instrument_delete actually makes a sample empty instead of just nulling it.

volume and panning envelopes, plus sanity checks