Load Protracker file in Blitz?

[Bren McGuire]

Is there any free code out there to be able to load a protracker file in Blitz?
I'm not looking for player code necessarily, but something that can take a protracker file as input, load its samples in memory and access its sequence, but not necessarilty play it.
I guess as such it should not have any assembler in it to do this unless it is impossible to do without assembler.

I'm trying to make some analytics.

[Coagulus]

If you're not looking to play it you could load it into a bank?

http://eab.abime.net/showthread.php?t=61648

[Bren McGuire]

That seems a bit crazy, is there really no protracker player source?
I know exactly what data I want to get out of the file for my analysis, I don't need to plonk the whole module in RAM and then read memory addresses.

[Coagulus]

What are you trying to access? The Protracker format is well documented and if loaded into a bank is accessible and editable.

If you use the PHXplayer lib the module can be played from the bank too.

[Bren McGuire]

Hold on a second, will have to say I am a total Blitz noob first to not get hammered :P

Now, I was reading again through the Blitz manual and I see Blitz already has a way to load MODs and MEDs into your program.
I also see you can load a sample from disk, and create sound data, but I cannot see how you would access the data loaded by LoadModule or LoadMedModule directly.

Would Bank allow me to do what I want? I want to:

- read module name and display it
- read sample name and display it
- create sound object from sample data loaded by module
- play that sound object

?

Originally Posted by Coagulus

What are you trying to access? The Protracker format is well documented and if loaded into a bank is accessible and editable.

[Coagulus]

Haha no hammering here. I'm a noob when it comes to many things Amiga. I had fun trying to access modules. At one point I was loading them into a bank , saving them to RAM and then loading them using the player code!

I don't think the built in commands give you much access to the mod data itself. At least the PHXplayer loads into banks and plays from there meaning you can peek and poke whatever you want and still play it.

1 and 2 definitely. 3 not so easily as I don't think you can play a sound from a memory location in Blitz using Blitz commands normally.

A botch could be to add a pattern with the sample you want to play triggered and then jump to that pattern when the mod is played... not an elegant solution and there may well be a better answer.

[Daedalus]

To play a sound, once you know where in memory it's stored, you could create a dummy sound object and either copy the data into the object, or modify the object's pointer to point at the data. It's unlikely the sound data will be in the Blitz internal sound object format, so you might need to do some basic decoding and manually set the other parameters in the sound object structure. You can see the sound object structure here: http://www.amigacoding.com/index.php...ct_types#sound and include the definition in your code by adding the bb2objtypes.res resident file to the compiler options.

[Coagulus]

You see, that's a much more proper way of doing it.

[Bren McGuire]

So how to know where the sample data will be at?
Would loading the MOD file as a Bank as Coagulus mentioned work? The Protracker MOD file format is well documented and if I can put the MOD file at a certain memory location, offsetting from there should be kinda trivial.

Can this be done with LoadModule or LoadMedModule at all?
Do I need to include PHX's routine at all if all I want is to load the sample data in memory and then play it off using regular Blitz sound procedures?

As for the sound data itself, wouldn't using the SoundData procedure be good for this? The manual says "altering IFF sounds is OK" but doesn't detail how.
Oh, seems like DecodeSound might be what I need to use, actually.

Thanks both for your valuable help (and Dastardly for the Blitz wiki on Amigacoding, been reading all day )

Originally Posted by Daedalus

To play a sound, once you know where in memory it's stored, you could create a dummy sound object and either copy the data into the object, or modify the object's pointer to point at the data. It's unlikely the sound data will be in the Blitz internal sound object format, so you might need to do some basic decoding and manually set the other parameters in the sound object structure. You can see the sound object structure here: http://www.amigacoding.com/index.php...ct_types#sound and include the definition in your code by adding the bb2objtypes.res resident file to the compiler options.

[Daedalus]

Originally Posted by Bren McGuire

So how to know where the sample data will be at?
Would loading the MOD file as a Bank as Coagulus mentioned work? The Protracker MOD file format is well documented and if I can put the MOD file at a certain memory location, offsetting from there should be kinda trivial.

Yeah, that's probably the way to do it. Just be doubly sure your offsets are valid, because once you go into things at that level, it's very easy to bring the whole OS down with a bad calculation or assumption

Can this be done with LoadModule or LoadMedModule at all?
Do I need to include PHX's routine at all if all I want is to load the sample data in memory and then play it off using regular Blitz sound procedures?

If you're just loading the file and interpreting it yourself, there's no need to load it with a dedicated library. Alternatively, if you do use e.g. LoadModule, you can get the location of the Blitz object (which then contains the module address) with the Addr Module(0) function.

As for the sound data itself, wouldn't using the SoundData procedure be good for this? The manual says "altering IFF sounds is OK" but doesn't detail how.

Yes, that can be done if you know where the audio data is, but that alone is simply changing the bytes of an already existing sound object. You need to do a bit more to change the size of the object, for example.

Oh, seems like DecodeSound might be what I need to use, actually.

Thanks both for your valuable help (and Dastardly for the Blitz wiki on Amigacoding, been reading all day )

You're welcome (I did much of the Blitz section on AmigaCoding too )

[Bren McGuire]

Mate I don't know what I was smoking, I meant to write DAEDALUS, I must have been reading another thread at the same type and confused users. Sorry! And thank you for such an amazing resource

Originally Posted by Daedalus

You're welcome (I did much of the Blitz section on AmigaCoding too )

[Amiga1992]

Well this is wild, I'm looking to do something similar here, will be reading up on this thread. Thanks to all.

[Amiga1992]

Originally Posted by Daedalus

Yes, that can be done if you know where the audio data is, but that alone is simply changing the bytes of an already existing sound object. You need to do a bit more to change the size of the object, for example.

OK looking into this, what does DecodeSound actually do? BEcause if you pinch the data from a Protracker file, the samples are stored as absolutely raw sound data, so it's not actually an iff. The descriptors are actually separated, else where in the format.

Document says "allows to include sounds inside code", but I am assuming this is if you incbin an iff file? So DecodeSound would be useless in this scenario, and SoundData is exactly what you'd want to use.

Please correct me if I am wrong.

[Daedalus]

Ah, that's a good point actually (I haven't tried it myself) - DecodeSound probably does expect an IFF header on the sound data that the Protracker file doesn't contain. Apologies!

Some additional manual interpretation of the ProTracker format is needed then, so you can get the necessary details from the file and manually copy the sound data over to a new sound object.

[Amiga1992]

I just realized that this could easily land into a memory nightmare because DecodeSound would make a copy of the sample data into a new sound object, so you'd need a lot more RAM than the module takes just to be able to do this.

Unless there's a way to make the sound objects just reference the sound data via a pointer instead of having the actual sound data in them...

[E-Penguin]

You can create a pointer to a sound type and point it to the memory address. Getting the syntax right will be the tricky bit...

[Amiga1992]

Originally Posted by E-Penguin

You can create a pointer to a sound type and point it to the memory address. Getting the syntax right will be the tricky bit...

I guess we will have to test and find out....

[idrougge]

Originally Posted by Akira

Unless there's a way to make the sound objects just reference the sound data via a pointer instead of having the actual sound data in them...

Unfortunately you can’t specify that something must be INCBINed into chip memory, so the data must be copied.

[E-Penguin]

I guess you could test the pointer address to see if it's under $20 0000, then it must be in chip and thus avoid having to do a copy.

[Daedalus]

AmiBlitz3 includes the "Chip" compiler directive for locating chunks of the executable in chip RAM, but I've never tried using it. in theory it would allow you to Incbin data that will be always loaded into chip RAM. It can only be used once though, so you would put it at the end of the actual program, and put all your Incbin chunks after that.

Under Blitz 2 it would always end up in fast RAM if there's fast RAM available. That's a nice suggestion, to check if it's in chip RAM first and then do a copy if needed.