ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<andlabs> oops
<sorear> I think the real takeaway here is that we've finally moved to open-source compression algorithms
<cr1901_modern> wait, the oman archive is in the pokemon leak, but not the n64 one?
<cr1901_modern> And yes, rar has always been annoying
<superctr> i mean, the n64 stuff is in both of them, but the pokemon leak has the original oman archive as well
<cr1901_modern> Huh... all those leaks come from a hack of a Nintendo server.
<cr1901_modern> But AIUI, the oman archive was from SGI
<cr1901_modern> ("Oman" was an SGI employee)
<superctr> well, the 4chan thread is basically a compilation of various leaks
<superctr> someone posted the oman archive and up it went
<superctr> so it's not all from the same source
<cr1901_modern> ahhh
<cr1901_modern> it's reasonable for the n64 leak, if it was unmodified, to have the SGI stuff. But I would've been surprised if it was the same exact archive
<superctr> i'm sure most of the pokemon stuff is from the same source though (though still not everything, i believe some of the "Debug ROMs" were released earlier and dumped from actual cartridges)
<cr1901_modern> We might never know for sure their source*
<cr1901_modern> (*We know who dumped it- I forgot their name. But who knows if they posted it unmodified)
<cr1901_modern> err s/dumped/leaked/. I know nothing about the Debug ROMs
<cr1901_modern> Same person who did this leak did the spaceworld leak IIRC
<superctr> the ique n64 leak is not completely unmodified. there's a tree containing the n64 os 2.0L SDK source code (the library sources, not just the actual SDK released to developers) merged with the SGI sources (which is the same as the oman archive)
<superctr> but those changes were done by the ique team (or broadon as it turns out)
<superctr> then there is a separate tree with the ique modified software/hardware sources
doppler has quit [Quit: doppler]
<andlabs> Pietro Gagliardi, [03.05.20 00:44] also can I say I don't feel like hearing what developments happen after today
<andlabs> Pietro Gagliardi, [03.05.20 00:44] because I ahve a lot of shit going on right now and I don't want to be locked in irrationally angry and want to burn the world down mode
<andlabs> but if you insist, my advice:
<andlabs> Pietro Gagliardi, [03.05.20 00:34] also start working to change copyright law
<andlabs> Pietro Gagliardi, [03.05.20 00:34] legal change has to start in Europe because everyone else just copies European law, but cultural change has to start in America because that's where most of the companies are situated in and that's also where the moral standard originated
<andlabs> Pietro Gagliardi, [03.05.20 00:35] insert Tom Scott's newest video about blaming the right people here
<Lord_Nightmare> which oman leak is it? the smaller one or the bigger one?
<Lord_Nightmare> there are two, both named oman.rar iirc
<Lord_Nightmare> and the larger of the two i thought was lost to time
_whitelogger has joined ##yamahasynths
<cr1901_modern> So an unmodified broadon tree was stuck into the leak, and a modified ique tree was _also_ stuck into the leak.
<cr1901_modern> ?*
<cr1901_modern> andlabs: You can't un-leak something. The n64 emu devs will have to learn that.
<cr1901_modern> In a sense, I think it's unfortunate, b/c it means the limits of clean-room REing those chips won't be tested like they were on SNES
_whitelogger has joined ##yamahasynths
<superctr> well, that's good, since then they can focus on the Saturn or PS2 /s
doppler has joined ##yamahasynths
<ZirconiumX> WQ still has my PS2 board I think, superctr
andlabs has quit [Quit: Textual IRC Client: www.textualapp.com]
andlabs has joined ##yamahasynths
<Lord_Nightmare> superctr: is that the 151mb one? or the one that's much larger?
<Lord_Nightmare> the 151mb one I found a copy of, but not the other one
<superctr> the rar is 151 mb
<superctr> i believe the top directory is the "PR" (Project Reality) source tree
<superctr> since it matches with the iQue leak (where it has been merged with the 2.0L SDK source tree), and that is what one of the documents in said leak say too
<superctr> in the iQue leak the path is "depot/rf/sw/n64os20l"
<andlabs> depot?
<andlabs> sounds like perforce to me
<andlabs> (hi I work for google)
<andlabs> on topic again
<andlabs> what is still lacking in dosbox opl emulation?
<andlabs> out of curiosity
<andlabs> I can't tell from the general meh-ness of ibm pc game music
<superctr> it's cvs
<superctr> apparently
<andlabs> heh
<andlabs> would make sense for a unix house I guess
<andlabs> afk
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<Lord_Nightmare> dosbox opl emulation lacks people who did active research willing to touch the currently licensed driver, except for a few
<Lord_Nightmare> there's too many gplv2 and gplv3 licensed FM cores around which are next to useless for commercial applications
<andlabs> ah heh
andlabs has quit [Ping timeout: 260 seconds]
andlabs has joined ##yamahasynths
<cr1901_modern> Lord_Nightmare: (Semi-rhetorical) And why do you think gpl is favored in emulation?
<superctr> i sometimes feel too that the GPL is too "restrictive" for those purposes, i think it would be pretty cool to see decent FM emulation in commercial games/emulators
<superctr> but at the same time, i get really pissed off when i see things like Hoot stealing code without even giving credit, and GPL would have been helpful there
<superctr> so i accept the current status quo. But if i ever write an FM emulator from scratch, i would seriously consider what license to release it under
<cr1901_modern> If you're going to be a reference impl of cycle-accurate behavior, my opinion is keep it GPL to (severely) discourage behavior where commercial products make improvements and don't share their changes back
<superctr> well, LGPL would suffice in that case
<cr1901_modern> because of the link exception?
<superctr> you also want to give an incentive for commercial developers to actually use your code too, so they make improvements and share them in the first place
<superctr> yeah. LGPL, but with an extra exception to allow static linking. because that is an arbitrary limitation of LGPL that I think is pointless (if the source code to the library is available, there is no need to use the exact same binary)
<whitequark> superctr: Apache2, maybe?
<whitequark> er, sorry, brain fart
<whitequark> *MPL, maybe?
<whitequark> MPL seems to be designed for this exact use case
<cr1901_modern> https://www.mozilla.org/en-US/MPL/2.0/FAQ (Q2) Hmm... looks like I have some reading to do
<superctr> i would have used MPL if it didn't have "Mozilla" in the name..
<cr1901_modern> superctr: Artistic license then (with caveat that I don't know many ppl using it)?
<superctr> that's an option
<cr1901_modern> There was some caveat to the Artistic license that I didn't like when I first learned about it. So I never used it for my software. But tbh, at this point, I don't remember what it was.
<sorear> does _anyone_ besides Perl use that?
<whitequark> yes
<whitequark> it pops up in weird places
<cr1901_modern> >All modified files containing MPL'd code must be disclosed under the MPL. on https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) This seems like a good compromise.
<andlabs> yeah
<andlabs> dualing the MPL with the GPL is a common compromise for this case
<andlabs> unfortunately it leads to stupid shit like this
<andlabs> a source-available -- that is, nonfree (despite being $0) -- fork of firefox for the amiga
<andlabs> this is allowed because the MPL allows choosing only the MPL
<andlabs> for forks
<andlabs> honestly I want to say a lot of the GPL usage out there is not understanding licenses
<andlabs> and no, the LGPL would not help dosbox's case
<andlabs> for dosbox you'd either have to have exactly one dosbox implementation used by all games available on [gaming store] with the storefront offering the source code separately, or each individual game doing so
<andlabs> this might work for GOG
<andlabs> *the former
<andlabs> by the way, DOSBOX is already GPL.
<andlabs> so all of this is moot
<cr1901_modern> >honestly I want to say a lot of the GPL usage out there is not understanding licenses
<cr1901_modern> I would not be surprised.
<andlabs> meanwhile in things I didn't think were still around
<andlabs> cr1901_modern: oh I now remembered what phrase I wanted to use instead of "not understanding licenses"
<andlabs> "cargo culting"
<andlabs> I want to make it open source, all the open souce I know uses GPL, so I'll use it too
<cr1901_modern> Well, my original q to LN was referencing the attitude of "I don't want commercial software making changes without contributing them back". Which is common for emulators.
<cr1901_modern> >this is allowed because the MPL allows choosing only the MPL
<cr1901_modern> I don't understand the case of timberwolf. >>
<cr1901_modern> What does source-available mean?
<cr1901_modern> And if it's what I think it means ("you can't change it to release a new product"), how does that help timberwolf?
<andlabs> it means "the source is available under licensing terms that are decidedly not open source or free software"
<cr1901_modern> They have to license their changes under MPL, so someone could take their MPL-licensed changes, stick it back into Firefox codebase, and viola, new product
<andlabs> nope
<andlabs> firefox code has to be released under all licenses, not just one
<andlabs> in this case, the new code isn't licensed under the MPL
<andlabs> and changes are not licensed under the GPL or LGPL, only the MPL