Add Libxmp#2483
Conversation
|
like play .mod .s3m .xm .it etc... |
I saw that, but have never heard of such things until like just now How would this differ from a generic .mid/ .midi file player? |
|
unlike .mid it has instruments inside file, also used a lot in demoscenes there is also some archive website like https://modarchive.org |
I see So like DAW content in a file? Is it like a half between MusicXML and MIDI? I've never heard of such a thing this is interesting |
|
sort of? but wikipedia can explain better than me:
|
|
so like VSTs, audio loops, and everything in Logic Pro, but stored in a file. Interesting |
|
i guess yes, (but i barely know abt music, i might be misunderstanding what VST is...) |
I had to look it up, it's Virtual Studio Technology I just know them as software instruments though |
|
yeah same |
|
it's harder to justify a 1MB wasm bundle for something like this than DECtalk |
|
well then you can just remove from json file no? |
|
we're not merging new extensions without putting them in extensions.json. every time we do that, we just make a bunch of maintenance for ourselves without any user benefit i'm not saying no to this idea. i'm just saying that you'll have to justify why we should make every copy of the desktop app 1MB larger due to including a WASM library for parsing a niche file format |
|
you're just saying niche because you don't know it existed - it's been used for long time and maybe games you've played (e.g. popcap games like peggle, "unreal", ut, many amiga games including lemmings, etc...) also by json file i meant that one which sits in top directory, not extensions.json why even care about 1m? you use electron in first place, if you really care about size, electron already makes size big enough. nsis compresses 1mb too so it'd be also even smaller. |
if they're unknown even to a musician like me, they're quite niche. MIDI is industry standard and it makes more sense to integrate a MIDI player into #1725.
TL;DR: It's not necessarily about a "1 megabyte" size limitation. It's about the return on investment or size-to-benefit ratio. Yeah, we all know electron is size-intensive. However, that 1 MB will multiply across all of the different Turbowarp Desktop builds we have to make for the different platforms, and those binaries have to be stored somewhere. Servers aren't cheap. While many of them are stored on GitHub, others are expensive (such as the $100/year required to host on the Apple App Store). I know it's a difficult situation to get through since I've done it myself. You could respectfully argue for justifying why that size is beneficial, but I didn't succeed very well with that. For #1974, I had to re-compile a custom version of Ammo Physics with build flags that removed extraneous features, only to cut the file size by 50%. Even then, the WASM for Ammo is still 1 MB, but I can't compress it much further without removing necessary features the extension uses. It's really just about how much stuff you're getting in an extension that big. The features should justify its size |
i am sorry but it's just because you probably don't know because you just didn't do enough research. (if your proof is based on that you're artist - why would me or many of my friends who aren't musician would know tracker modules?)
But it's not like 1MB will increase that fee or something (I would love to say more but since you don't seem to want to read sentences with more than 2 periods, so I won't.)
I would love to argue but if one does not reply to me with respectful messages (which other one did not to history here), I would rather not bother and keep replying like other one does (plus 800kb is the best i could without losing important functionality) |
I don't want to start an internet war here. I don't have any problem with reading more than two sentences. But I can't research something I've never heard of or never used. Even if I have never used it, that's my own problem. There's people smarter than me and I don't know everything. I also don't have a problem with this extension idea. But you'll have to take it up with @GarboMuffin about whether or not the size/benefit ratio is justified |
me neither but if other one keeps calling huge history part like that it definitely would. not my fault
i cannot be bothered to path-find but articles you've read definitely have something related to trackers (if you have researched about music)
well i am glad about that |
|
Well i have managed to get way less size (264K), at the cost you lost most of supports. If that's what you wanted i guess i can use that. |
I know a lot abotu classical music and write pieces often, but I've not heard of trackers. I've heard of tracks (like those in a DAW) but I'm not sure if the two are the same or different. I know there's terminology for everything though... |
|
actually compiled result is 340K (.a is 264K tho but doesn't matter much it's around 80k) |
I don't think I was asking anything like that, but okay |
Well you asked for it:
🤷 |
|
All I wanted was some more justification of the goals and needs because the pull request was rather empty It's not like the marginal cost of adding 1MB matters - it doesn't - but if we keep adding 1MB wasm bundles it will matter at some point. So I just need to make sure what we're doing actually something someone other than you might use Generally I am very busy and can only spend single digit number of minutes per extension. I don't have much time to hunt down things that aren't stated super obviously |
well other people will use it. at least i know 3 will, but i don't mainly live in this community to know about that.
not really? you call history "niche" and now you call my pr empty? |
Explanation, not request, but okay |
well i thought it's too late and i'll commit anyways |
Okay |
@NishiOwO He means as the PR barely has any blocks, aka an "empty" extension |
well i could add more blocks but I thought it was enough. i can add more if you suggest me some |
|
@NishiOwO may I ask why this was closed? |
thought it wasn't going to be merged, also does not feel good about how person replied. i found more progressive fork; i've decided to contribute there |
|
it's understandable have fun :) |
Original code is at https://github.com/nishiowo/tw-libxmp