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
cr1901_modern2 has quit [Quit: Leaving.]
cr1901_modern has joined ##yamahasynths
emeb has quit [Quit: Leaving.]
HXLNT has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined ##yamahasynths
<Foone> cr1901_modern: your mention of the zero wing ending resulted in this: https://twitter.com/Foone/status/1352244581245489153
emily has quit [Quit: Bridge terminating on SIGTERM]
ugla has quit [Quit: Bridge terminating on SIGTERM]
emily has joined ##yamahasynths
ugla has joined ##yamahasynths
<cr1901_modern> Foone: Bahaha nice. I didn't know about the secret endings.
<andlabs> is that the test mode code that I put on tcrf? or a different one?
<cr1901_modern> TCRF is mentioned in the thread, so... probably your test mode
<andlabs> ok good
<andlabs> I wonder if my really dumb comment is still in the page source
emeb has joined ##yamahasynths
<cr1901_modern> ej5: https://twitter.com/cr1901/status/1352284005983465473 I like your Propellor tweet
<cr1901_modern> whitequark: https://twitter.com/whitequark/status/1352265920715124738 If this is what I think it is (dedicated vgmplayer application using jt51 and cxxrtl), this is beautiful
<cr1901_modern> awesome <3
<whitequark> about 1/5 of realtime speed
<whitequark> which is very bad
<cr1901_modern> Maybe bad for realtime listening, but I'm still impressed.
<whitequark> i think it's terrible and i even know where the terribleness in the codegen is
<whitequark> just don't have the energy to fix it
<Sarayan> I love step 6
<cr1901_modern> I get closer to 1/10th speed on Sandy Bridge. But it's well... Sandy Bridge. Trying on a Skylake machine running Linux
<whitequark> the reason i used make is to parallelize
<whitequark> this laptop has 16 cores which makes converting entire packs tolerable
<whitequark> uh... is vgmrips down?
<cr1901_modern> It appears down for me
<cr1901_modern> Ever see this error: http://ix.io/2MOG (My gcc could be too old- it's 16.04)
<whitequark> try using clang
<whitequark> it does sound like a gcc bug
<whitequark> (also, cxxrtl should be pure c++11 compatible)
<cr1901_modern> I get hundreds of errors w/ c++11 mode :P. But I'll try w/ clang now. I forgot I had my own copy installed
<cr1901_modern> ^Ignore that msg
<cr1901_modern> re: the errors
<cr1901_modern> http://ix.io/2MOI With clang, I get this
<whitequark> hm. that's weird
<cr1901_modern> It's clang-10, fwiw. Compiler header bug from 5.x days that trips up newer compilers?
<whitequark> try replacing `music.push_back({delay, address, data});` with `music.push_back({delay, (uint8_t)address, (uint8_t)data});`
<cr1901_modern> same error... interesting
<whitequark> hang on
<whitequark> music.push_back(std::make_tuple(delay, (uint8_t)address, (uint8_t)data)); ?
<cr1901_modern> Theeere we go... compiled :)
<whitequark> ok, let me add one more change
<whitequark> for the clock rate
<cr1901_modern> I have the gist checked out. So make changes and I'll pull
<whitequark> done
<whitequark> ah, wait
<cr1901_modern> waiting
<whitequark> i *think* this is it
<whitequark> you can check the changes
<cr1901_modern> clang++ is fine
<cr1901_modern> waiting on g++ to finish up (takes notably longer to compile, prob myraid of reasons why)
<cr1901_modern> g++ works
<cr1901_modern> Or rather, "g++ -std=c++11" works :)
<whitequark> g++ is a lot slower on cxxrtl code for a bunch of reasons that mostly have to do with cxxrtl being developed against clang
<whitequark> shockingly, cxxrtl seems to work even under msvc
<cr1901_modern> On my skylake the g++-compiled jt51_play is ~7 times slower than real time
<whitequark> -O3?
<cr1901_modern> yes, -O3
<whitequark> could throw -march=native in as well, not that it does much
<whitequark> hm
<whitequark> what about clang++?
<cr1901_modern> g++: 12 seconds of VGM in 90 seconds (7.5)
<cr1901_modern> doing clang now
HXLNT has quit [Ping timeout: 246 seconds]
<cr1901_modern> Okay this is def close to 5 times slower w/ clang
<cr1901_modern> (no march=native)
<cr1901_modern> 12 seconds of VGM in 60 seconds (5)
<cr1901_modern> Sounds beautiful when played <3
<cr1901_modern> Unfortunately, when I try to run jt51_player on Windows on the same VGM, the resultant WAV file sounds like noise.
<cr1901_modern> This should be easy enough to debug tho- WAV is nearly raw samples
<cr1901_modern> for me* to debug
<whitequark> cr1901_modern: oh i did everything wrong
<whitequark> moment
<whitequark> fixed now
<cr1901_modern> Awesome. Running now (it's def slower on Windows- running benchmark now)
<cr1901_modern> clang++ w/ -O3, version 9 Windoze: 12 seconds of VGM rendered in 375 seconds (31.25)
<cr1901_modern> Hrm, and the wav still sounds wrong... oh son of a bitch
<cr1901_modern> it's inserting CRLF into the output wav
HXLNT has joined ##yamahasynths
<cr1901_modern> yea, that would be a problem
KitsuWhooa has quit [*.net *.split]
KitsuWhooa has joined ##yamahasynths
<cr1901_modern> Hrm, even when I use std::ofstream wav_file(argv[2], std::ofstream::binary), CRLF is inserted in place of LF
<cr1901_modern> Ooooh I see... clang doesn't auto-add .exe to output filename, while gcc does
<cr1901_modern> so I've been running the wrong binary for the past 17 minutes
HXLNT has quit [Ping timeout: 246 seconds]
<cr1901_modern> whitequark: Patch for you http://ix.io/2MP6
<whitequark> thought so :s
<whitequark> moment
<cr1901_modern> Hilariously, this one change also got gcc at -O3 to do 12 seconds of VGM in 250 seconds (20.8)
<cr1901_modern> So we know where the bottleneck is :P
<whitequark> er, what
<cr1901_modern> I think part of the hot path is checking whether the character is 0x0A
<cr1901_modern> to convert it to CRLF
<cr1901_modern> if you are in binary mode, you skip that check
<whitequark> oh, factor of 20 nstead of factor of 30
<whitequark> that's still... super slow
<cr1901_modern> right, but might be gcc. Also 10 year old hardware. Recompiling w/ clang now
<cr1901_modern> And it might be that write single bytes is inefficient
<cr1901_modern> on Windoze*
<cr1901_modern> errr, single 16-bit ints
<whitequark> the writes should be buffered i think?
<whitequark> hm, maybe not
<cr1901_modern> This wouldn't be the first time I've seen behavior like this. Claire's libxsvf library is (was?) extremely slow on Windows. Like 5 minutes to program a low-end Xilinx CPLD slow. And profiling showed it to be waiting for libusb due to lack of bufferring.
<cr1901_modern> Not saying it's related/the same reason of course
<whitequark> cr1901_modern: updated, i've also added some code that fixes the WAV file size
<whitequark> so players don't get confused
<cr1901_modern> Awesome, thanks. And disregard re: optimization. I think it's a gcc vs clang thing. Clang speed is about the same: 11 seconds of VGM in 377 seconds w/ the binary fix. Still very slow; I should do a profile.
KitsuWhooa has quit [Ping timeout: 256 seconds]
KitsuWhooa has joined ##yamahasynths
brendantcc has joined ##yamahasynths
<cr1901_modern> whitequark: If you want I'll still do a profile later. I got distracted (nap) and have meatspace stuff to take care of
<whitequark> sure