English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Blitz Basic (http://eab.abime.net/forumdisplay.php?f=126)
-   -   Load Protracker file in Blitz? (http://eab.abime.net/showthread.php?t=105277)

Bren McGuire 06 January 2021 00:01

Load Protracker file in Blitz?
 
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 06 January 2021 02:37

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 06 January 2021 16:41

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 06 January 2021 19:48

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 06 January 2021 19:58

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

?



Quote:

Originally Posted by Coagulus (Post 1451295)
What are you trying to access? The Protracker format is well documented and if loaded into a bank is accessible and editable.


Coagulus 06 January 2021 20:35

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 06 January 2021 21:41

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 06 January 2021 22:03

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

Bren McGuire 07 January 2021 01:44

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 :) )

Quote:

Originally Posted by Daedalus (Post 1451319)
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 07 January 2021 18:29

Quote:

Originally Posted by Bren McGuire (Post 1451351)
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 :)

Quote:

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.

Quote:

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.
Quote:

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

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 08 January 2021 16:32

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! :bowdown And thank you for such an amazing resource


Quote:

Originally Posted by Daedalus (Post 1451534)
You're welcome (I did much of the Blitz section on AmigaCoding too ;) )


Akira 08 January 2021 16:57

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

Akira 12 January 2021 23:41

Quote:

Originally Posted by Daedalus (Post 1451534)
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 13 January 2021 11:30

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.

Akira 13 January 2021 18:38

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 13 January 2021 18:42

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...

Akira 13 January 2021 20:24

Quote:

Originally Posted by E-Penguin (Post 1453449)
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.... :crying

idrougge 14 January 2021 03:28

Quote:

Originally Posted by Akira (Post 1453444)
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 14 January 2021 10:42

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 14 January 2021 14:52

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.


All times are GMT +2. The time now is 03:07.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.

Page generated in 0.08340 seconds with 11 queries