.FTM Plugin

Post about feature requests here.
User avatar
AceMan
Posts: 3
Joined: Tue Nov 24, 2015 9:38 am
Location: Poland
Contact:

Re: .FTM Plugin

Postby AceMan » Fri Nov 27, 2015 7:32 am

the file assiociation would sorta screw up.


Well, file associations are always up to the user.

TechEmporium wrote:How about compatibility between each FTM file version? And what about modules that use multiple chips/channels?


FamiTracker engine handles them, right? So would plugin.
There are dozen of plugins that determine version of the file and then use specific routine.

Programs like FastTracker have been programmed in such a way as to revolve around the extended module's protocol to be able to display it like a project file, when in fact the XM file itself is actually a firmware file type for the Amiga's audio chip.


What :D

XM (Extended Module) is FastTracker II module format which adapted Amiga MOD format and added more channels, commands etc.
But I probably get what you had in mind. MOD/XM/IT/S3M/MED/DIGI/DBM and many more formats are designed to play directly without additional processing. Module files especially designed to 8bit machines (C64/ZX/GB/NES etc) often need additional player coded into the file, and that's why another format (with player) is needed.

But we are not talking about playing music on original machines. Believe me that when it's possible, most people prefer listening to original tracker files, at least just to watch those lovely hex variables ;)

User avatar
TechEmporium
Posts: 113
Joined: Wed Apr 22, 2015 12:44 am
Contact:

Re: .FTM Plugin

Postby TechEmporium » Fri Dec 04, 2015 12:03 am

Actually, it IS possible (that wasn't what I was arguing against at all). What I was saying was that this goes beyond the scope of FamiTracker itself (i.e.: look up cpow's project to create a uFMOD-like library for FTM files).

Also, if you didn't understand what I was saying earlier about the different FamiTracker versions made & how they each handle FTM files differently, I'll give you an example of how this makes your desire a bit problematic.

We'll take FamiTracker 0.3.0, 0.3.6 & a third-party build that allows for multiple expansion chips within its FTM files.

If I were to make an FTM file in 0.3.6, then try to open & play said file in 0.3.0, all instruments containing built-in volume control will be muted. If I were to open a multi-expansion FTM (made in a third-party FamiTracker version) within the official 0.3.6 (or the most recent version,) the program will give an error, saying that the FTM file is corrupt. As you can see, there actually is no real established standard for the FTM file itself; as much as everyone would like it to be more standardised, it's as dynamic as each new version of the program.
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
(Lousy modern technology!)

http://techemporium.bananabo.xyz/
http://techemporium.vashid.us/

User avatar
HertzDevil
Posts: 462
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: .FTM Plugin

Postby HertzDevil » Fri Dec 04, 2015 3:21 am

TechEmporium wrote:How about compatibility between each FTM file version? And what about modules that use multiple chips/channels?

The CFamiTrackerDoc class determines which version each individual data block belongs to, then loads it appropriately; as long as a most recent version is used, all FTMs of previous versions should be guaranteed to load properly. If one were to make a FTM library right now, it shall fully support all FamiTracker versions from 0.2.2 to 0.4.6. There is no point in deliberately using code that is forward-incompatible.

Multi-chip FTMs never "corrupt" the file and render them unusable in official builds (except when all chips are enabled, due to an erroneous conditional that can be removed by anyone having the source code), for if it weren't so, none of the threads at the music boards would use multiple expansion chips since they would be incompatible with the latest stable or beta build. I have clarified this on multiple occasions, but you seem to refuse to listen.
Constructing Chiptune; Construing 8-Bit. Makes 0CC-FamiTracker and MEGA ZUN.

Join my forum for 0CC-FamiTracker discussion and more

cpow
Posts: 29
Joined: Wed Jul 29, 2015 6:18 pm

Re: .FTM Plugin

Postby cpow » Sun Dec 13, 2015 6:51 pm

FamiTracker Qt compiles all of the Famitracker functionality into a library. The front-end player I wrote for it was simply meant as a demonstration of the concept. Writing a WinAmp compatible plug-in that uses FamiTracker Qt library should be easy.

8BitZtunerYT
Posts: 378
Joined: Thu Apr 23, 2015 7:20 pm
Location: Somewhere stuck in Winamp
Contact:

Re: .FTM Plugin

Postby 8BitZtunerYT » Sun Dec 13, 2015 9:18 pm

cpow wrote:Writing a WinAmp compatible plug-in that uses FamiTracker Qt library should be easy.


[HYPE INTENSIFIES]
slowly ceasing to exist.
"8BitZ caresses his keyboard as he orgasms to the sounds of Winamp."
-retrodpc, 2015

cpow
Posts: 29
Joined: Wed Jul 29, 2015 6:18 pm

Re: .FTM Plugin

Postby cpow » Sat Dec 19, 2015 3:14 am

8BitZtunerYT wrote:[HYPE INTENSIFIES]


I managed to get all of the pieces together and have a plugin loading. Smooth sailing, perhaps. :D

EDIT: That moment when you realize that you're making your life too difficult. Not sure why I thought I had to build the plugin DLL using MSVC. D'oh!

cpow
Posts: 29
Joined: Wed Jul 29, 2015 6:18 pm

Re: .FTM Plugin

Postby cpow » Tue Dec 22, 2015 4:12 pm

So. Quick observation. I have created a plugin that successfully loads and -- for the most part -- successfully initializes the FamiTracker Qt. There is one minor issue, though.

Both WinAmp and FamiTracker support plugins.
Both WinAmp and FamiTracker expect their plugins to be in <Executable Path>/Plugins
WinAmp places naming restrictions on its plugins. in_*.dll represent input plugins, out_*.dll represent output plugins, etc.

The problem:
FamiTracker does not place naming restrictions on its export plugins.

So when FamiTracker initializes and attempts to load its custom exporter plugins, it attempts to load and inspect each DLL in C:\Program Files (x86)\WinAmp\Plugins for FamiTracker's export plugin symbols. This -- the library loading -- causes WinAmp to crash.

I'd like to propose a naming restriction on FamiTracker custom exporter DLLs. I'm not sure how many of these there are. But it would eliminate my current issue and any issue in the future similar to this.

Perhaps: ftmx_*.dll?

Unless anyone else has any other solution ideas? Before it's suggested, I *don't* like the idea of one-offing a "WinAmp-compatible" in the FamiTracker Qt DLL to support this.

8BitZtunerYT
Posts: 378
Joined: Thu Apr 23, 2015 7:20 pm
Location: Somewhere stuck in Winamp
Contact:

Re: .FTM Plugin

Postby 8BitZtunerYT » Tue Dec 22, 2015 6:13 pm

Not a expert in programming here, but temporaily removing the FT Custom DLL Support could solve it until a permanent solution is found?
slowly ceasing to exist.
"8BitZ caresses his keyboard as he orgasms to the sounds of Winamp."
-retrodpc, 2015

User avatar
HertzDevil
Posts: 462
Joined: Thu Apr 23, 2015 7:39 pm
Location: Hong Kong SAR
Contact:

Re: .FTM Plugin

Postby HertzDevil » Wed Dec 23, 2015 1:20 am

cpow wrote:I'm not sure how many of these there are.

This, and Gradualore's original text exporter which I found in FamiTone 1.
Constructing Chiptune; Construing 8-Bit. Makes 0CC-FamiTracker and MEGA ZUN.

Join my forum for 0CC-FamiTracker discussion and more

cpow
Posts: 29
Joined: Wed Jul 29, 2015 6:18 pm

Re: .FTM Plugin

Postby cpow » Thu Jan 07, 2016 2:19 am

Image

It's making noise, but in a cheating sort of way.

Not integrated with the visualizer yet, but once I stop cheating the player that'll also be done.

To integrate the FTM visualizers would require a separate visualizer plugin.


Return to “Feature Requests”

Who is online

Users browsing this forum: No registered users and 1 guest