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 has joined ##yamahasynths
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
andlabs has joined ##yamahasynths
<cr1901_modern> I talked to wq a bit in DM while I was out...
<cr1901_modern> I think there should be a "hello world" for the familys on the wiki
<cr1901_modern> cc: Lord_Nightmare
<cr1901_modern> I can get started w/ an example for OPM and maybe start w/ an example for OPL
<cr1901_modern> 2*
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
<cr1901_modern> err nevermind
<cr1901_modern> I remembered
<cr1901_modern> wrong tab
<TD-Linux> heh your pic definitely looks signed. which doesn't match the dac datasheet but it wouldn't be the first error at this point
<mofh> cr1901_modern: I could do OPN(A) at some point
_whitelogger has joined ##yamahasynths
<Stilett0> cr1901_modern: I went through the thread here: https://www.vogons.org/viewtopic.php?f=62&t=64901 and all the Snark Barkers/Snood Bloopers/etc. from the first VOGONS run are spoken for
<cr1901_modern> Stilett0: Thanks
<cr1901_modern> mofh: I would appreciate that. I can do OPM just fine. I wish I was able to answer wq's question from memory, but for OPL I couldn't (and even OPM I would have to test)
<cr1901_modern> if anyone knows offhand, what does initial clear actually _do_? I seem to recall that it doesn't actually zero out all internal registers on power-on reset
<cr1901_modern> From using jotego's JT51 core, I explicitly remember having to give all registers initial values, otherwise the random power-on reset values of the registers would make their way to the output audio.
mad has quit [Ping timeout: 255 seconds]
<whitequark> cr1901_modern: AFAICT ~IC *does* clear internal registers on OPL2
<whitequark> after power on it outputs some strange stuff
<whitequark> after an ~IC pulse it outputs something more reasonable
<whitequark> more or less corresponding to zero level
<cr1901_modern> whitequark: Ahhh okay. In my own testing w/ YM2151, IC does *not* reset the registers, so I figured it might be a good idea to reset them manually to avoid problems
<cr1901_modern> Been spending the last hour trying to get this working: https://github.com/DhrBaksteen/ArduinoOPL2
<whitequark> lol wtf just how buggy is it
<whitequark> why is the documentation so bad
<whitequark> did they even try proofreading it
<whitequark> forget proofreading. did they try *reading* it
<cr1901_modern> No, it was very clearly copied verbatim from JP datasheets
<cr1901_modern> There _is_ no official datasheet for the YM2612 for instance
<cr1901_modern> instead Sega got Yamaha to give them some internal info, which they transcribed _badly_ into the Genesis technical manual
<cr1901_modern> it is known to have glaring flaws omissions
<cr1901_modern> >lol wtf just how buggy is it
<cr1901_modern> >Well, that's the thing... last time I played w/ 2151 it was a softcore. I don't actually _remember_ the /IC behavior for the physical chip. So I asked: https://twitter.com/cr1901/status/1099195256917164033
<cr1901_modern> ... MY GOD WHY DOES THIS SOUND SO BAD?!
<cr1901_modern> it's clipping _so_ fucking badly
<whitequark> Sarayan: okay so, do you understand the DAC bitstream format?
<whitequark> can you explain it to me like i'm a terminal idiot?
<whitequark> i just want to get back 16 bit samples
<cr1901_modern> whitequark: FWIW, I have a YM3014 DAC impl in migen somewhere. But it predates the 2015 API change
<cr1901_modern> I was trying to _test_ a sine tone on the linked dev board above, but it sounds like it got run through a trash compactor. So I'll just use DOSBOX emulation and play w/ an Adlib tracker
<whitequark> incredible
<cr1901_modern> ej5 has some... criticisms on the linked board. I can't tell whether it's the lm386 fucking up or the shift register or what... GAH!
<whitequark> Sarayan just told me about a "busy flag".
<whitequark> this is never mentioned in the datasheet
<whitequark> what the f uck is a "busy flag" in the context of an OPL2
<cr1901_modern> Busy I think is the top bit when you read from the chip
<cr1901_modern> it means you have to wait to do the next write for about 32 cycles
<whitequark> that says "IRQ"
<whitequark> in the datasheet
* cr1901_modern opens the datasheet
<cr1901_modern> interesting, you're right. No busy fla
<cr1901_modern> g*
<whitequark> OPLL docs mention 12 wait cycles after address write and 84 wait cycles after data write
<cr1901_modern> OPL3 doesn't have a busy flag either. I wonder if it's a OPM/N thing (it _def_ exists there)
<whitequark> and... based on your ArduinoOPL2, if i translate the timing to the default master clock
<whitequark> that's definitely a thing
<cr1901_modern> At least 32 master clock cycles before next address write or data write
<cr1901_modern> OPL3, but I think it's safe to assume applies to OPL2
<cr1901_modern> Okay it's official, OPL needs more love in here. There's too much OPM/N bias
<Ultrasauce> i did happen to impulse purchase some OPL3 a few hours ago
<whitequark> cr1901_modern: OPLL timings are higher
<whitequark> 84 cycles for data writes
<whitequark> and your arduino library also has higher OPL2 timings
<Ultrasauce> we'll see if that turns into an impulse-actually-bother-to-do-anything-with-this-pile-of-parts
<cr1901_modern> whitequark: Oh well I just learned something interesting
<cr1901_modern> OPM3 uses a 14.32 MHz clock
<cr1901_modern> err OPL3*, freudian slip
<cr1901_modern> whitequark: Yea, go w/ 84 cycles
<cr1901_modern> my mistake
<whitequark> Lord_Nightmare: oh btw
<whitequark> the datasheet says about outputs "output except ~IRQ" in the Vih spec
<whitequark> so this strongly implies that ~IRQ is open drain
<cr1901_modern> There are 9 channels... why are there 0x15 registers in each section for Attack/Decay/Sustain/Release and friends
<whitequark> incredible
<whitequark> i added write latencies
<whitequark> it.. outputs something that looks like real samples now
<whitequark> 9820
<whitequark> 9910
<whitequark> 9988
<whitequark> 99f0
<whitequark> 98a0
<whitequark> 9a40
<cr1901_modern> 18 (0x12) of those registers I can account for- 2 operators for 9 channels
<cr1901_modern> but the other 3 Idk what they do
<whitequark> probably unimplemented
<whitequark> cr1901_modern: can you please write a formula to convert the DAC samples to
<whitequark> something sane
<whitequark> i think i get DAC words that are correct now
<cr1901_modern> I assume the samples you listed are MSB on the left side?
<whitequark> yeah
<whitequark> these are in the sane byte order, not intel
<cr1901_modern> heh, well it took me a bit to realize (the last 3 bits in all your samples are 0, so that should correspond to the last 3 bits that the YM3812 emits)
<whitequark> yes
<whitequark> interestingly if i do not respect the write timings, sometimes those last 3 bits are not 0
<whitequark> nice metastability i guess
<whitequark> cr1901_modern: did you sya you had a DAC in migen?
<cr1901_modern> I do, I'm looking for it
<whitequark> ah
<whitequark> ok, i got *some* sound out of t
<whitequark> that sounds... fm-modulated
<whitequark> it is definitely not what i put in
<cr1901_modern> I have it on a backup drive it seems
* cr1901_modern logs in
<cr1901_modern> whitequark: Even before I find it, I explicitly remember saying "screw the sign bit"
<cr1901_modern> and used unsigned
<cr1901_modern> fwiw
<cr1901_modern> whitequark: http://ix.io/1BPg
<cr1901_modern> I don't deal w/ a sign bit it seems
<whitequark> holy shit
<whitequark> i have music
<whitequark> it's awfully mangled
<whitequark> but i have music
<cr1901_modern> that sign bit shit is gonna bother me for the rest of the day lmao
<cr1901_modern> but I'm glad :)
<whitequark> let me put it up
<whitequark> little endian u16 samples at 49 kHz or so
<cr1901_modern> downloaded
<cr1901_modern> I'm opening an ipython notebook to play w/ it
<whitequark> holy shit
<whitequark> i made it
<whitequark> perfect sound
<cr1901_modern> your data that you sent looks a bit strange to me, but I also rushed churning out a graph
<whitequark> cr1901_modern: that's because i accidentally saved raw samples
<whitequark> in fp format
<whitequark> give me a moment
<cr1901_modern> Oh I figured that
<cr1901_modern> I was trying to convert it
<whitequark> mantissa = (sample >> 3) & 0b111111111
<whitequark> exponent = (sample >> 13) & 0b111
<whitequark> sign = (sample >> 12) & 0b1
<whitequark> high_bits = 0b0000000_000000000 if sign else 0b0111111_000000000
<whitequark> high_mant = high_bits | mantissa
<whitequark> sample = (sign << 15) | ((high_mant << (exponent - 1)) & 0x7fff)
<whitequark> this is the formula
<whitequark> it works quite well
<cr1901_modern> wonder if I got it wrong all those years ago and never noticed
<cr1901_modern> yup your formula is def better than mine.
<whitequark> lmao
<whitequark> i think something's still not quite right
<whitequark> hm
<whitequark> cr1901_modern: https://vgmrips.net/packs/pack/tyrian-pc
<whitequark> these ... don't match up
<whitequark> track 06
<whitequark> the javascript player plays it at 44100
<whitequark> (i can tell because of displayed track length and VGM sample count field)
<whitequark> but the frequency field in the VGM says it should be played at a much higher rate
<cr1901_modern> Wonder if the javascript player is resampling
<cr1901_modern> Or does it not _sound_ right either
<whitequark> no, it sounds the same in javascript as when i take the DAC output
<whitequark> and play it at 44100
<whitequark> but this doesn't match the master clock value
<cr1901_modern> Strange
<cr1901_modern> I'll dl and try myself
* cr1901_modern has a command line vgm player he likes
<cr1901_modern> you may want to compile VGM play
<cr1901_modern> Oh btw, track 06 is a good track of Tyrian :3
<whitequark> ok, let me recapture a bit
<whitequark> i have some weird boundary issues around PCM capure
<cr1901_modern> whitequark: Okay I'm remembering something
<cr1901_modern> VGM is hardcoded to 44100 Hz
<whitequark> WTF
<whitequark> WHY DO YOU EVEN HAVE A MASTER CLOCK FIELD THEN
<cr1901_modern> VGM is a bad format
<whitequark> WHY ARE ALL OF THESE FORMATS AND ALL OF THEIR DOCUMENTATION SO FUCKING AWFUL
<whitequark> AAAAAAA
<cr1901_modern> >WHY DO YOU EVEN HAVE A MASTER CLOCK FIELD THEN
<cr1901_modern> For resampling purposes I think
<whitequark> i'm in despair! horrible outdated formats and incomplete documentation has left me in despair!!!
* cr1901_modern feels like he should've broken these horrible truths a bit more gently...
<cr1901_modern> whitequark: Okay I'm remembering something else now
<whitequark> so let me get this straight
* cr1901_modern holds off
<whitequark> the *delays* are specified at 44100 samples
<whitequark> but the *chip* is running at 49000 samples.
<whitequark> that
<cr1901_modern> Well, there are VGM opcodes to delay by 1/60th of a second
<whitequark> would explain why it sounds kind of wrong but not very much
<whitequark> the only ones i have here operate in terms of samples
<cr1901_modern> you have a global counter for your chip that repr master clk... every number of ticks that corresponds to 1/44100th of a second, you're expected to read the next VGM opcode
<whitequark> wait, what?
<whitequark> i thought VGM writes are "instantaneous"
<cr1901_modern> well they are
<whitequark> so isn't it more like,
<cr1901_modern> When I say "opcode" I mean "increment the file pointer in the VGM file"
<whitequark> this is not what the VGM spec tells me, hrm
<whitequark> I have xeactly two commands in the VGM file
<whitequark> 0x5A aa dd : YM3812, write value dd to register aa
<whitequark> 0x61 nn nn : Wait n samples, n can range from 0 to 65535 (approx 1.49
<whitequark> seconds). Longer pauses than this are represented by multiple
<whitequark> wait commands.
<whitequark> do I really wait one sample on each 0x5A?
<cr1901_modern> that is my interpretation of the spec
<cr1901_modern> whitequark: Since I'm batting like 0 for 5 today, I could be wrong about most of this. At the very least, it is correct that 0x61 is in units of 1/44100th seconds.
<cr1901_modern> and of course you have to wait the prerequisite 84 master cycles before doing each write.
<whitequark> hrm
<whitequark> how does write latency interact with, latency of vgm opcodes
<cr1901_modern> What _I_ don't know is- since on a real chip you have to wait 2*84 master cycles for command 0x5A to finish
<cr1901_modern> do you subtract that off the time you wait until 1/44100 of a second elapses?
<whitequark> 2*84?
<whitequark> not 12+84?
<cr1901_modern> sorry 84*. Where does 12 come from?
<whitequark> 12 is for address, 84 is for data
<cr1901_modern> Oh, oops
<cr1901_modern> yea 12+84
<cr1901_modern> thought it was 84 cycles for both addr/data
<whitequark> oh hm, i might be getting some buffer overflows here...
<cr1901_modern> ... what _is_ your setup atm?
<whitequark> glasgow.
<whitequark> lemme enlarge some buffers
<cr1901_modern> well yea, but is glasgow just running the YM3812 interface and VGM is being done on the laptop side, or?
<whitequark> yes
<cr1901_modern> what VGM player did you modify to talk to Glasgow?
<cr1901_modern> I'm prob gonna do some testing of my own, since I'm having trouble w/ the arduino board
<whitequark> i did not modify a VGM player
<whitequark> i implemented the spec
<cr1901_modern> oh my sincere sympathies :P
<cr1901_modern> So the DAC format, IIRC, is the same for all the Yamaha DACs. I remember my DAC impl (3012, not 3014) passed the tests I gave it. Looks like whatever tests I was giving it were wrong LOL.
<whitequark> ok, i figured out buffering
<whitequark> same link
<cr1901_modern> test.u16?
<whitequark> yep
<cr1901_modern> I see something reasonable on the output
<whitequark> play it
<whitequark> $ play -r 49715 test.u16
<cr1901_modern> I don't have play? I'm on Windoze
<whitequark> ok gimme a sec
<cr1901_modern> ooooooh
<cr1901_modern> sounds good :)
<whitequark> I think it has a few issues still, mostly because of buffering in Glasgow
<cr1901_modern> But this is the OPL I remember too
<whitequark> I think it has an underflow towards the mid-end part of the track
<whitequark> I need to add an underflow indicator I think
<whitequark> the buffering is kind of really tricky to do well
<whitequark> because the FPGA bus is simplex
<whitequark> and I still don't have a good arbiter
<cr1901_modern> simplex from cypress to FPGA?
<whitequark> yes
<whitequark> so I have a command pipe and a data pipe
<whitequark> and the FPGA multiplexes them
<whitequark> badly
<whitequark> because I suck at scheduling
<cr1901_modern> mood
<whitequark> but not as badly as yamaha sucks at writing documentation
* cr1901_modern wipes the smirk off his face In all fairness, I should've warned you...
<cr1901_modern> OPM docs are _okay_. OPN, depending on which variant, you can get good docs
<cr1901_modern> the Genesis sound chip docs are downright wrong
<cr1901_modern> OPL seems really bad
<cr1901_modern> OPL2*
<whitequark> ooh I might connect it to my ΣΔ DAC...
<whitequark> Glasgow as AdLib :P
<cr1901_modern> connect it to an ISA bus, it'd still be less damn expensive than a genuine Adlib :)
<whitequark> i mean, i could just clone the adlib schematics
<whitequark> now that i have plenty of cheap YM3812s
<cr1901_modern> ej5 did that already
<cr1901_modern> it was his project before the Snark Barker
<cr1901_modern> whitequark: After reading the OPL2 datasheet _only_, I'm only confident I understand what 75% of the OPL2 regs do. Many of them are obvious to me from OPM equivalents. A few others I knew apriori what they do from seeing pictures/diagrams here and there.
<cr1901_modern> Naturally I don't remember where I saw those diagrams. They're not in the datasheet
<whitequark> ok, let me clean up everything
<whitequark> and push it
<whitequark> literally every single on topic response is just more depressing
<cr1901_modern> Someone who has contacts at Creative was in your mentions
<whitequark> oh?
<whitequark> oooh
<whitequark> i missed that
<cr1901_modern> http://map.grauw.nl/resources/sound/yamaha_ym2151_datasheet.pdf Oh shit. I can't find any reference to "wait 32 cycles" in the OPM datasheet either
<cr1901_modern> there's exactly one reference to the "B" flag
<cr1901_modern> which if there wasn't an application manual, how the hell would you know what that stands for?
<cr1901_modern> (Busy)
<cr1901_modern> Actually it's even _more_ bare bones than the OPL2 datasheet!! At least there was an attempt to explain each register: http://map.grauw.nl/resources/sound/yamaha_ym3812_ds.pdf
<cr1901_modern> whitequark: This is the equivalent document for OPM that ankrmu was talking about: http://map.grauw.nl/resources/sound/yamaha_ym2151_synthesis.pdf
<cr1901_modern> >a period of 68 master cycles is required
<cr1901_modern> > Summary of the Principles of FM-type sound generation
<cr1901_modern> https://twitter.com/whitequark/status/1099091520655892480 Btw, which doc did this come from?
<whitequark> YM3041B doc
<whitequark> wait, no
<whitequark> "YM3812 Application Manual"
<whitequark> ok
<whitequark> let me clean it up and commit
<cr1901_modern> >"YM3812 Application Manual" Could you please link me that, I'm having trouble finding it
<whitequark> it's in my library
<whitequark> Electronics/FM Synthesizer
<cr1901_modern> I don't have access to that
<cr1901_modern> I was mainly curious how you got hold of it
<whitequark> I don't remember
<whitequark> hm
<whitequark> do you have an account on cloud.whitequark.org?
<cr1901_modern> no
<whitequark> oh. ok give me a sec
<cr1901_modern> thanks
<whitequark> I do not remember where I got it
<whitequark> I was very angry and searching for any available dat
<whitequark> *data
<cr1901_modern> LSI-2438120 is very close to LSI-2438124
<whitequark> # Ref: CATALOG No. LSI-2138123 (YM3812)
<whitequark> # Ref: CATALOG No. LSI-2438124 (YM3812 Application Manual)
<whitequark> consecutive ones, hm
<cr1901_modern> However you found the application manual... excellent work!
<cr1901_modern> I'm not able to duplicate your success
<cr1901_modern> but importantly it exists and is preserved and it should prob be on archive or some place
<whitequark> cr1901_modern: so the transfer function for DAC is as follows: assign V = {S, {7-E{~S}}, M, {E-1{0}}};
<whitequark> it's actually nicer in migen... give me a sec
<cr1901_modern> Did you have to sign up for an account on some shady download site to access LSI-2438124?
<cr1901_modern> re: DAC, I see
<whitequark> nope, I just googled
<cr1901_modern> Gah, I can't find it T_T... every website wants me to sign up for some dodgy shit
<cr1901_modern> when you get the chance could you do a quick history search? The fact that this document magically appeared is bugging me XD
<whitequark> i think the key is to search while really pissed off
<cr1901_modern> I'm only slightly pissed off
<whitequark> get angrier!
<whitequark> assign V = {S, {{7{~S}}, M, 7'b0000000}[E+:15]};
<whitequark> I think this is actually legal Verilog
<whitequark> see, this is actually quite elgant to implement
<cr1901_modern> doesn't look too bad
<cr1901_modern> and I'm more tired than angry. I guess it'll remain a mystery until I get angrier. Might help me seek out other datasheets I've presumed do not exist.
cr1901_mobile has joined ##yamahasynths
l_oliveira has joined ##yamahasynths
<cr1901_mobile> I guess now I do have IRC everywhere lol
<cr1901_mobile> @whitequark you may want
<cr1901_mobile> To store the raw DAC inputs with your test harness as well
<cr1901_mobile> I think the raw floating point output from three ym3812 should optionally be stored when doing model comparison*
<cr1901_mobile> I wonder if some enterprising musicians took advantage of DAC imperfections to create instruments (a la ladder effect on YM2612)
<whitequark> cr1901_modern: the decoded DAC output has a 1:1 mapping to wire DAC values
<whitequark> so it is always possible to just do the reverse transform
<whitequark> but yeah, sure, this is as easy as one command line switch
* Sarayan waves
<Sarayan> so, music now? :-)
<whitequark> yes
<Sarayan> cool
<whitequark> I'm putting finishing touches on the Glasgow applet
<whitequark> send me your all favorite VGMs
<Sarayan> I'm more interesting on having the opl2 *in* glasgow :-)
<Sarayan> s/ing/ed/
<Sarayan> all the internal registers are in fact rotating shift registers, with the write (and the read) taps in specific places in the loop
<Sarayan> that gives interesting timings on write
<Sarayan> they rotate all the time in sync with the oscillator loop
<Sarayan> so that the correct value for the correct channel is available exactly when it is needed
<whitequark> Sarayan: well we need the glasgow opl2 applet for model checking
<Sarayan> it's a very cute fully-synchronous design, shared by all the yamaha fm chips
<Sarayan> true that
<cr1901_mobile> One of my favorite opl tunes is prepsong.kdm but that's not vgm format lol
<whitequark> what is kdm
<Sarayan> never heard of kdm
<cr1901_mobile> Ken's digital music
<cr1901_mobile> The Build Engine dev
<cr1901_mobile> Ken Silverman
<cr1901_mobile> Try "zero wing" on vgmrips
<whitequark> ok
<Sarayan> vgz = gzipped vgm
<whitequark> yeah, figured that out long ago
<whitequark> ok, i only have let's see
<whitequark> i only really need to write a proper VGM reader now
<whitequark> instead of a hack
<whitequark> and detect underflows
<whitequark> then it's ready
<Sarayan> and then on to delayering ;-)
<whitequark> yes
<whitequark> i'll get HF next week
<whitequark> probably towards the end
<whitequark> and within a few months should be able to etch implants
<whitequark> btw, donations to keep the lab up appreciated, though i will set it up regardless
<whitequark> the total cost would probably be around $1-2k
<Sarayan> opl2 won't need implant etching fwiw
<whitequark> i know
<whitequark> i'm thinking of delayering and capturing high res photos of all yamaha chips
<whitequark> i'm going to go through the trouble of all this NRE, might as well get the job done
<cr1901_mobile> NRE?
<whitequark> nonrecurring expenses
<whitequark> setup costs.
<cr1901_mobile> Ahhh
<whitequark> like i find it conceptually offensive that we have to rely on 30+ year old silicon sometimes
<whitequark> that has such large node size that you can probably draw it with a loupe and a pen
<cr1901_mobile> Soon enough there won't _be_ any 30 yo silicon
<whitequark> exactly
<whitequark> i want to buy the last set of yamaha chips anyone will ever need
<cr1901_mobile> Having redundancy in die images and hdl/neoasic impels can't hurr
<cr1901_mobile> Hurt*
<whitequark> i'm not sure if we have delayers for any yamaha chips yet?
<cr1901_mobile> Oh that may be true. I just meant images w/ all layera
<whitequark> yeah
<whitequark> need a better scope and a positioning stage
<whitequark> there's a nice looking stage on ebay
<cr1901_mobile> Eg digshadows ym2151 image is pretty good, but has a few blemishes
<whitequark> i guess the scope and optics will cost me another $1-2k
<whitequark> which is really very cheap
<cr1901_mobile> A ym2151 image you do won't have the same blemishes
<whitequark> a few decades ago this was the domain of university labs and very well equipped companies
<whitequark> now i'm just some rando bored in her apartment
<whitequark> hm
<whitequark> I will need Glasgow revD soon, I guess
<whitequark> these parallel buses are annoying lol
<whitequark> YM3812 already takes all 16 pins
<cr1901_mobile> Heh
<Sarayan> dig's ym2151 image is nice, but a little too low res given the density for vectorization
<Sarayan> I know cr disagrees, but heh :-)
<whitequark> Sarayan: yeah I'll look at a much higher res camera
<whitequark> early next weel
<cr1901_mobile> I've not run into problems yet for the sections I've done
<whitequark> *week
<whitequark> also different lenses
<Sarayan> wq: you res is enough for opl2, it's the crap focus that's the problem :-)
<Sarayan> your
<cr1901_mobile> Sarayan: clearly I'm not gonna complain about a second reference omg ;)
<cr1901_mobile> Img* damn autocorrect
<whitequark> Sarayan: enough... barely
<whitequark> i wonder if focus stacking would help here
<Sarayan> I'm not compentent to answer :-)
<l_oliveira> <cr1901_mobile>I wonder if some enterprising musicians took advantage of DAC imperfections to create instruments (a la ladder effect on YM2612) <- Some MD games actually did and when SEGA went to the new all in one chipset they had a "modified" YM3438 chip in it (the chip is CMOS). They had to change some things to make the YM3438 behave more like a YM2612 but the part you mean to talk...
<l_oliveira> ...about still behaves differently than a YM2612. So these games do sound different on a Genesis2/MD2
<cr1901_mobile> l_oliviera: Indeed. That's the ladder effect
<l_oliveira> I prefer the YM3438 sound though
<cr1901_mobile> I wondered if YM serial DACs had same bugs
<l_oliveira> YM3438 sounds closer to YM2608
<l_oliveira> also, YM2612 has lower output impedance, there's more noise
<l_oliveira> and early MD units use that high gain amplifier from sony (for compact cassette players) it injects a bit of white noise on the sound background
<l_oliveira> CXA1032
<cr1901_mobile> Basically there's always gonna be an unsatisfiable Genesis audiophile :P
<whitequark> i mean not really
<whitequark> get a real genesis, measure the transfer function
<whitequark> you can get it as close as you want
<l_oliveira> I made my YM2612 gadget for MSX using all MD parts so it did sound real
<l_oliveira> even the CXA1032
<cr1901_mobile> AFAIK, there are genuine perceptible differences in even current 2612 emus and the silicon
<whitequark> cr1901_mobile: btw the js player on that page def sounds different to a real YM3812
<l_oliveira> these flaws are integral to the experience, you know
<cr1901_mobile> Oh I'm sure
<cr1901_mobile> ^^whitequark
<cr1901_mobile> I'm just thinking to the future.
<l_oliveira> my friend coded a frequency translator code for OPN series chips
<l_oliveira> I am going to bug him to backport it to OPL chips
<cr1901_mobile> There will be an audiophile crowd for retro sound chips. Just like records vs CD
<l_oliveira> there is already, no? @cr1901_mobile
<cr1901_mobile> Probably :P. I don't spend much time reading sega16/smspower threads on the FM chips
<l_oliveira> it's even easy to reach accomplished composers on twitter and they've been releasing a ton of retro stuff
<cr1901_mobile> l_oliviera: Oh sorry. To be clear, I'm using "audiophile" pejiratively
<l_oliveira> You can reach people like Yuzo Koshiro, Masahiro Kajihara or Takeshi Abo on twitter easily
<cr1901_mobile> Like the "gold hdmi cable carries sound better" audiophile
<l_oliveira> man that's even scary
<cr1901_mobile> I was talking to Takashi Abo in DM a few days ago
<whitequark> Like the "gold hdmi cable carries sound better" audiophile
<cr1901_mobile> I invited him here w/o knowing much about him
<whitequark> this is actually one of their *less* inane claims
<l_oliveira> Steins;Gate lol
<whitequark> it gets significantly worse
<l_oliveira> just to mention something big from him
<cr1901_mobile> LOL worse you say?
<Sarayan> opl2 is fully digital, there's no variability going in there
<l_oliveira> all FM synths from Yamaha that are usable on personal computers are fully digital, no?
<cr1901_mobile> Sarayan: I thought maybe the serial DACs had bugs we don't know about
<whitequark> content warning: dangerous for your brain
<cr1901_mobile> That musicians took advatnage of
mad has joined ##yamahasynths
<l_oliveira> oh I just remembered I should follow you on twitter, whitequark
<cr1901_mobile> Why did I open that link? I knew nothing good would come from it...
<whitequark> this is not even the worst link i've seen
<whitequark> there are people who argue against negative feedback in amplifiers, for example
<whitequark> not any specific circuit. any negative feedback period
<whitequark> it is apparently a Big Deal in those circles
<cr1901_mobile> Probably the same ppl who think Class A is the One True Amplifier
<cr1901_mobile> l_oliviera: if umemoto were still alive I would've reached out to him as well by now
<l_oliveira> audiophile castor oil stuff?
<cr1901_mobile> Right
<l_oliveira> that's good stuff man
<l_oliveira> read the text and have a good laugh
<cr1901_mobile> I get the desire for accuracy. Once the desire for accuracy leaves the digital realm though, it's subjective.
<l_oliveira> optical cables with gold tips anyone?
<mad> it's not just accuracy... there's a desire for basically a man-toy
<l_oliveira> they sure look great
<cr1901_mobile> man toy?
<l_oliveira> yeah, the same reason people spend money with lambos and ferraris
<l_oliveira> but on cars people are actually getting real benefits
<mad> that's why they like vinyl... you can touch it, you can tape pennies to the cartidge, you can buy fancy needles, you can brush it with electrostatic brushes
<cr1901_mobile> Mmm... yea I dont really get that. I'll take functional over stylish anyday.
<l_oliveira> me too
<mad> compared to CD where you basically can't do anything
<whitequark> man-toy
<whitequark> heh yeah
<l_oliveira> but these people are seeking the experience from 1970s
<cr1901_mobile> Well you can't do anything YET :P
<mad> "experience" that's exactly the word
<mad> they want an experience, not the audio that's the most like what the musicians recorded ;)
<cr1901_mobile> I dont think there's anything inherently wrong with that.
<l_oliveira> the other day I saw an article on radioactive anti-static vinyl cleaner brushes
<whitequark> ahaha
<whitequark> cute
<cr1901_mobile> Probably the same people who want to bring back asbestos
<l_oliveira> asbestos are not bad when it's quiet at the insulation. BUT when the building is torn down, try to contain it
<l_oliveira> no, thanks
* cr1901_mobile thinks of the edible radium packets from the 1910s
<mad> that's like people who want to bring back measles :3
<l_oliveira> Brazil still have a lot of stuff made out of asbestos
<mad> there's a town nearby named asbestos
<cr1901_mobile> l_oliviera: well I wouldn't be surprised if they determine fiberglass is a carcinogen too :/
<l_oliveira> we had a company here which made Water containers for houses with asbestos
<l_oliveira> it is in Portuguese but you can look the pictures if you find it of interest https://revistapegn.globo.com/Negocios/noticia/2017/11/eternit-anuncia-que-vai-parar-de-usar-amianto.html
<l_oliveira> "eternit announces it will stop using asbestos"
<l_oliveira> using that to store water you will be drinking, sounds insane, no?
<whitequark> asbestos is harmful when inhaled
<whitequark> water is fine, the problems are elsewhere
<l_oliveira> they say it is a carcinogen
<l_oliveira> and there's the problems with breathing the powder, of course
<whitequark> it is a carcinogen by inhalation
<whitequark> the fibers are so thin they physically damage the DNA in lung cells
<whitequark> as absurd as that sounds
<mad> it's tiny fibres
<l_oliveira> not absurd after reading how helium atoms disrupt mems oscillators... lol
<cr1901_mobile> New project idea: ##openasbestos
<whitequark> ##openasbestosmine
<l_oliveira> that sounds so toxic lol
<mad> but yeah the idea of not using negative feedback in amplifiers... that's kinda dumb :D
<whitequark> ok, i wrote a python vgm stream reader...
* cr1901_mobile is napping... be back in a bit
cr1901_mobile has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
<whitequark> cr1901_modern: I: glasgow.applet.yamaha_opl: VGM file contains commands for YM3812
<whitequark> I: glasgow.applet.yamaha_opl: recording at sample rate 48611 Hz
<whitequark> different sample rate
<whitequark> huh
<whitequark> hmmmm
<whitequark> cr1901_modern: that file is really weird
<whitequark> cr1901_modern: whoa
<whitequark> amazing music
<l_oliveira> is that a log of register writes?
<l_oliveira> or recorded analog audio?
<l_oliveira> (nvm seen it on twitter)
<l_oliveira> There's a reason why we call these documents from Yamaha "datashits"
<whitequark> lol
<l_oliveira> also all Yamaha chips have register "quirks" that are intentional and can be used to ID the chips
<l_oliveira> someone did a great job reverse engineering the test registers for the YM2612/YM3438 and documenting it publicly
<l_oliveira> they used the data to make a hardware feedback/peek meter for a fancy hardware music player
<whitequark> how does that work?
<l_oliveira> it polls the test register and reads data from the internal chip operators in real time
<l_oliveira> the MCU then processes and sends it to alot of leds on the control panel
<l_oliveira> also the chip has a test pin with some other output
<l_oliveira> the project is open source
<l_oliveira> lemme try to find it
<whitequark> oh huh
<l_oliveira> found it
<l_oliveira> midibox was it
<Sarayan> wq: if you need help about resampling, ping me
<whitequark> Sarayan: i think the browser can do it
<whitequark> unsure though
<Sarayan> 'kay then
<Sarayan> don't use mame code, it has the crappiest resampling code ever :-)
<whitequark> lol
<mofh> Sarayan: okay so it wasn't just me thinking that
<cr1901_modern> mmm
cr1901_modern has quit [Ping timeout: 250 seconds]
<ej5> whoah