Originally wrote this as a response to kleeder's comment in the Jeskola Buzz thread but got sidetracked to some different topics regarding what qualifies something to be a format on BotB, and I figured it was enough of a tangent to warrant splitting off into a different thread.

TLDR:
- don't mind if formats are Windows-only, hopefully the penguins can figure it out
- we already have a number of weird Windows-only-esque formats
- what do about paid/non-free formats?

Re: Linux compatible formats - despite being a Linux user myself, I understand from a general software engineering/support perspective that supporting Linux users, which is usually a tiny fraction of the user base (although maybe on BotB it's somewhat significantly higher), is almost always unfavorable in terms of cost vs. benefit. So that being said, I think I'd understand multi-platform not being a requirement or priority for format selection. I feel like what ends up happening in these cases is someone eventually figures out how to make it work on Linux, or it becomes a group collaborative effort to figure it out. (rereading kleeder's comment, this is basically what the last paragraph is saying so yeah)

Some other format-specific points about platforms:
- famitracker/0cc/famiplus are Windows only but work fine on Wine. Vanilla FT has some Wine-specific issues with the instrument dialog but they can be worked around, and I think Wine-specific fixes were made in 0CC onward.
- clipnote is Windows only, when I tried it in Wine it would launch but functionally didn't work.
- klangfreude I remember having sound and/or UI issues in Wine.
- PandaTracker and fSound have worked fine in Wine for me.
- OpenMPT is "Windows only" but also specifically has Wine support.
- smw/Lunar Magic is also Windows only but works fine in Wine. In theory an SMW ROM hack could be made without LM, but it's basically the tool for the smw format. A lot of other SMW hacking related tools also seem to be Windows only, with varying degrees of Wine compatibility.

Some other format-specific points about freeness (as in monetary free, but possibly also freedom/rights to content):
- SMW is not free nor is there really a free replacement for it. Entry submissions are in the form of ROM patches which I don't think contain any of the original non-free content but ultimately require having the original content to make use of it.
- Doom/Boom are kinda not free: the game engine is free to use (as in both $0 and GPL), but the original game assets are not free, but Freedoom is a free alternative to game assets. However, I think entries are generally expected to use the original game assets but theoretically could be played with free alternatives.
- Renoise is semi-free: the demo can be used to open and make entries but not render to file. This has been deemed okay for the format though.
- MT32/SC55 I think are technically not free since they require non-free system/data ROMs to properly play back entries? I'm also not 100% clear where the XG VST that's commonly used sits in being free (rights-wise) to use - maybe an abandonware kind of situation?

For the most part, I personally don't have a big issue with formats being paid, but makes sense to require formats to be either free or low enough cost or have a reasonably accessible and/or appropriate alternative to be as inclusive as possible.

i appreciate you bringing this up! and you've been around a lot longer than i have, so it's good to hear your perspective.

in fact it's entirely possible that my conceptions about format qualifications are some bastard child of truth and fiction; i'm not sure if i ever saw it In Writing that multiplatform accessibility was key or if i inferred it from past format request discussion.

with that said though, i think they're reasonable tenets to stick to if at all possible. however, there might be reasons to make exceptions, and buzz might have one - it is a storied piece of software that's been around forever as one of "the classic trackers". that connection to old demoscene means it sits perfectly in our roster otherwise, ... and while i'm not happy about its level of accessibility per se, perhaps it's most appropriate to prioritize the history and what BotB is about, where its focuses are within the scene, than uhh, "accessibility at all costs" if you will.

i feel a little more strongly about the "format should be free" distinction; all the examples you brought up are great, but in my opinion still fall on the "OK" side of the line in their cagey fake freeness. necessity of user-side ROMs and game assets is definitely not ideal but i would rather see the formats exist than us reside fully above the board. however, something like deflemask paid-version - imo that's a no-go, it's over the line of what i'd think is fair.

In my case specifically, I use neither Wine nor a Windows emulator in most of these cases, and when I make exceptions, it's through DOSBox, not Windows or Wine. The exception that I cite I have used before is actually FMC, as well as at least one genuine Impulse Tracker render. Plus, I made the command line portion of AddmusicK (a SMW music authoring tool) cross platform with some adaptations from HertzDevil's AddmusicK fork to replace some of the code that previously failed to compile... but in hindsight, I ended up migrating to Terrific Audio Driver for the most part.

For Renoise, I've never bothered paying, and instead I just record the thing myself. I have Blackhole on the Mac these days for this kind of stuff.

channelf too requires the roms to get played back correctly, which i think is a grey area too.

i dont have much to add other than the part: mt32/sc55 are technically just midis you submit. its free to create a midi with any free tool you can find. the part that is semi-free is to check if ur midi plays back how u want it. therefore its in a weird state. only the render-part is "not free". same as with renoise i guess.

its good to see it written down in a forum post but has rarely caused issues in the past iirc.

i think its probably best to look at pandatracker, fsound, and klangfreude as weird outliers rather than as feet in the door for less-accessible formats

Okay, deviating a bit from this, but I do have to bring this up-

YM2151.

Sharp is... basically the same thing? But with a PCM channel. Why have the other option at all?

okay ... nsfc
nsf is... basically the same thing? but with a dpcm channel.

the reason is because there is and was enough interest to have both formats.

the other thing is that sharp x68k targets a specific (real) machine that had that chip in it alongside the sampler chip, whereas ym2151 is just a format for That Chip

When adding formats, rather than following any strict rules, I think it's best to take into account a variety of factors, including accessibility, historical significance, and popularity in the community.

So for example, I think the Sharp x68k has a big enough community around it to warrant having its own format separate from ym2151, and as Dami mentioned above, Buzz has a strong history in the scene which I think warrants it being a format despite its inaccessibility.

So maybe not a very satisfying conclusion, but basically -- I think we should go on a case-by-case basis while trying to maintain accessibility as much as possible!

Makes sense.

Also, on the subject of Doom, I have tested a few previous entries on BotB using Freedoom just for fun, and it works well. It’s certainly usable and playable.

In terms of SMW, why doesn’t someone make a Freedoom equivalent to SMW for those not comfortable with… obtaining ROMs? I don’t know anything about SNES coding, but it should be possible, right?


also kleeder, why the mockery? I was just stating my view.

My basic feeling has always been that general accessibility is good, but it can never be absolute. My computer when I joined in 2013 simply could not handle wine/windows emulation nor deflemask and so almost every chip was inaccessible as far as I was concerned (I'd also struggled in 2005 with the same issues, but not on botb)

Some formats are simply harder to get into for different reasons but if the tools to create them are free the community can generally come through for the rest of it. There will always necessarily be a grey area in favor of legacy and creative spirit or we'd be policing stuff like amen break use and samples from SNES/GBA/etc games *insert funny joke about policing the use of the amen break for other reasons*


That said, if there's a truly windows-only format that was like a windows-native application or something, I'd advocate for garageband as a format since it is free to anyone who has a certain type of computer, tablet, or phone: devices which are in fact paid, prerequisites for participating on the website and derive from a decision that is inherently prohibitive for some formats.

Wine nowadays is more accessible than the DOS emulation you'd have to do to be able to make music for some formats (i.e. Adlib, pc-x801) a few years back, that's for sure (DOS emulation nowadays is easier too tho)

Re. 2151: interesting, I used to think YM2151 was created instead of x68k because there wasn't support for the PCM on Furnace or Deflemask until after the format became a thing, and thought the format would be replaced with x68k if that support ever came. But it very clearly became its own thing.

When I was most active (~2016-18) we requested X68K around a lot but that was ignored

This is a departure from the topic, but I think still fits under qualifications for formats as it was something I thought when I saw x68k on the compo.

There needs to be better research regarding size/memory limitations for "platform" formats, because of furnace's and VGM's swiss knife, but bloated, nature.

I was adamant about the 4MB limit on msxplus because of this, and it was why I requested .S98 for PC-x801 instead of .VGM when Bambootracker came around, as the VGM players for it are very limited. I gotta look into the hardware and VGM software limitations for the x68k, but I definitely don't think it can play 12MB VGMs (apparently it has a limit of 8MB RAM?).

Determining these kinds of limitations in the ruleset help both hardware compatibility and adds another layer to making the format more it's own thing (i.e. this would be another point of difference between YM2151 and X68K), and it's easier to have these in mind during the creation of the format than fixing in retrospect.

Yeah I'm not the biggest fan of .vgm being the lingua franca for a lot of formats since I don't think it represents a lot of formats all that well. [Hot Take Mode:] It's really like halfway between a hardware faithful format and mp3.

Or in nerdy mathy terms, VGM is a superset of what is reasonably playable on actual hardware because of things like sub-frame sample waits (aka non-50 Hz/60 Hz frames or "overclocked"). It also has the problem where some files just have way too much data for things like data streams, prime example being Dual PCM on Genesis where the PCM stream is supposed to be mixed/computed by some player program and a smaller set of data for the samples but in VGM you're basically interleaving an entire wav file into the VGM.

The biggest offenders I can think of off the top of my head are sms (sub-frame ticks and SnoozeTracker), sgen (PCM streams too big to realistically fit in storage/memory), hes (same deal with PCM streams), etc., and the easiest solution would be to only allow playable ROM exports or filetypes adjacent to that (like .hes or .nsf) but until Furnace and all the other tools support ROM export, that'll be quite a bit to ask for.

i'm all ears for updating max_filesize where it's relevant. but i'd want to be pretty confident in the reasoning before making changes! i agree it makes sense though and you make a very good point

Had a look into the x68k limitations in regards to VGM Playback. Like the MSX's, its VGM player is only limited by the amount of available RAM.

Edit: should be noted that the player is very inconsistent with PCM playback, but it's in active development so that can change

The maximum amount of RAM the X68K can have is 12MB, but that's only if you have the later higher end machines with 4MB base RAM and 2 4MB expansions.

I think 8MB probably would be the ideal max filesize, so it's playable on all machines, given expansion cards, and not requiring hardware mods.

Re: ROM formats, yeah, there should be an effort to avoid situations like the HES format with VGMs that cannot be played with future formats (I understand limiting the format now would be controversial until there's a proper converter for Furnace files).

On the case of computers like X68K and MSX it's OK to have VGM as the submission format, since the players are there and you just need to put them in the disk image to be able to play (distributing the player binaries could result in licencing issues).