Feature request: import patterns / samples / instruments from other module.

[BlackStar-EoP]

Long story short: I use Schism tracker for songs from my band and am currently using 2 decade old Impulse Tracker modules. I am currently replacing all the drum samples in the modules and what would be very convenient is if I take one of those old songs, keep all the pattern data, but have an import function in the file menu to import all samples from my 'master' schism tracker file. Reason for this is that those old modules have low quality drum samples and I am replacing them with high quality ones, but I already have some songs that now have 95 samples, and putting them all inside all the other files is a PITA.

Could also be done differently, having one master sample schism tracker file with empty patterns and importing the patterns from an old module. I'll have a look at the code to see if this can be done quickly :)

[BlackStar-EoP]

A very (very) quick scan of the codebase gave me the following function:

song_t song_create_load(const char file)

It might be possible to do this easily, I'll hack around a bit with the code, not sure how difficult it is to compile with VS22, but I'll see, no guarantees though ;)

[BlackStar-EoP]

@jangler I am currently actively working on this feature. I already managed to compile most of the files for Visual Studio 2022, there is quite a lot of non ISO C code which has been worked around and I probably broke the entire video module. Will keep you posted here. The plan is to have a single pull request for only this feature, without all the changes I had to make to get it to compile in VS22.

[jangler]

Is there a reason you're using Visual Studio? This is how you're supposed to build Schism on Windows: https://github.com/schismtracker/schismtracker/blob/master/docs/building_on_windows.md

[BlackStar-EoP]

Mainly the VS debugger other than that no real specific reason, I like a challenge. I'll see how far I get with this otherwise I'll go with the build env specified in the link :)

[sagamusix]

That being said, in the long run it surely would be great to get rid of all the GNU-isms in the code and have it build with a standard C compiler, which would also make the requirement for this build toolchain obsolete.

[BlackStar-EoP]

@sagamusix I already did a commit in my fork of the code, I got rid of the struct inits as { } and replaced them with { 0 }, and the ranged switch case labels

[mrpapersonic]

in the long run it surely would be great to get rid of all the GNU-isms in the code and have it build with a standard C compiler, which would also make the requirement for this build toolchain obsolete.

Just a little update on this, I just pushed a bunch of commits that made Schism compile with TinyCC on Linux, results on other platforms may vary tho

[sagamusix]

I left a few comments about the changes :)

(whenever there is some weird-looking csf_ code, feel free to ask me, chances are high that it was already weird like that in libmodplug / OpenMPT and that I had to touch it at least once when working on OpenMPT)

[BlackStar-EoP]

Awesome news guys. I basically stopped after getting hundreds of compiler errors and the fact that there's no good alternative in Windows for dirent (At least not at the time when I checked)

Perhaps I will pick this up again in the near future (soon(tm)). Dirent at least has some alternatives such as https://github.com/tronkko/dirent

What I wanted to do in my fork was use std::filesystem, but that's opening a whole new can of worms...

[mrpapersonic]

well good news on that side too: dirent shouldn't be used on win32 anymore because I updated everything to use the native unicode APIs.

std::filesystem can't be used because Schism is written in C and that's a C++ thing.

[BlackStar-EoP]

"std::filesystem can't be used because Schism is written in C and that's a C++ thing."

Which is exactly why I mentioned that's opening a whole new can of worms ;)