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
ValleyBell2 has joined ##yamahasynths
ValleyBell has quit [Read error: Connection reset by peer]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 248 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 244 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 248 seconds]
_whitelogger has joined ##yamahasynths
andlabs has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
whitequa1k is now known as whitequark
_whitelogger has joined ##yamahasynths
Sarayan has joined ##yamahasynths
ValleyBell2 has quit [Quit: WeeChat 1.6]
ValleyBell has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andlabs>
you have to call AudioQueueStop from inside your callback, and then burn off all the allocated buffers without re-enqueueing them
<andlabs>
that explains why libvgm's vgmplay was mising the beginnings of songs
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
l_oliveira has joined ##yamahasynths
<andlabs>
well it looks like I didn't drop the video game music bent, because I'm now combining all the little tools I wrote in the past few days into a single program that can play any number of file formats I add to it and can virtually enumerate folders and later zip files, and now I have folders, kss, spc, and gbs
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<andlabs>
kode54: also suggestion for psflib: add a field to psf_file_callbacks or argument to psf_open that gets passed to psf_file_callbacks->fopen
Xyz_39808 has quit [Ping timeout: 276 seconds]
<superctr_>
don't like apple going full NIH
<superctr_>
just makes developing cross platform applications a hassle
<superctr_>
probably what they want
<whitequark>
except audio sucks on every platform
<superctr_>
ahem
<superctr_>
pulseaudio
<whitequark>
so it's not like there is a good design you can clone
<whitequark>
LMAO
<whitequark>
no.
<superctr_>
the pure definition of suck
<superctr_>
but what i would like is everyone coming together and designing a good cross platform audio API like we did for graphics APIs like OpenGL/Vulkan etc
<Ultrasauce>
there's openmax
<Ultrasauce>
opensles
<Ultrasauce>
i hear the usb audio standards are normative, consistent, and well thought out
<superctr_>
which has been adopted by nobody
<superctr_>
regarding opensl es
<whitequark>
OpenGL is not a good or cross-platform graphics API
<whitequark>
OpenGL is like the pulseaudio of 3D graphics
<whitequark>
it's braindead on every level, and ES adds several more levels to be braindead on.
<whitequark>
and every platform has its own subset you can rely on, and that's before we get to what you need to get 60 fps on every platform
<whitequark>
which is a set of hidden assumptions you can uncover by reverse engineering its drivers
<superctr_>
it is still cross platform, apple just decided to unilaterally deprecate it after they went NIH with Metal
<whitequark>
they did not go NIH with Metal, Metal predates Vulkan
<whitequark>
arguably, the rest of industry decided to go NIH with Vulkan
<whitequark>
as for being cross platform: no it's not
<superctr_>
it was designed originally for IRIX
<whitequark>
any real opengl program is full of ifdefs, and you would never get a well
<superctr_>
and now we're using it on windows/linux
<whitequark>
working opengl program without specifically tailoring it for macos.
<whitequark>
so?
<whitequark>
i can use directx on linux, natively
<whitequark>
that means directx is crossplatform, surely.
<superctr_>
yeah, i remember apple used an ancient opengl that they never updated
<superctr_>
windows/linux drivers have been more up to date, though of course it is very driver-specific
<whitequark>
that's also true for other drivers
<whitequark>
on linux, if you can use mesa, good
<superctr_>
many issues that only happen on some specific AMD/nvidia GPUs, etc
<whitequark>
if you don't use mesa... you need a whole different set of assumptions
<whitequark>
the problem with considering opengl crossplatform is that you have to assume for that, that opengl provides an abstraction
<whitequark>
it does not
<Ultrasauce>
audio interface compatibility is a clusterfuck right down to the analog physical layer
<linkmauve>
whitequark, uh, I have written an OpenGL and ES game which didn’t do anything platform-specific, and still ran fine on OS X too.
<whitequark>
it provides a set of calls that look like an abstraction but in reality just do whatever
<linkmauve>
That one time I tested it there, that is.
<whitequark>
linkmauve: it looks ok if you just need like 5 triangles
<linkmauve>
The only joke driver I’ve had issues with was Intel’s Windows driver.
<linkmauve>
But that one’s a joke anyway.
<whitequark>
but for example, the moment solvespace is trying to render something large, or do something interesting with shaders? it falls apart
<whitequark>
turns out you actually can't call glGenBuffers per frame, for example.
<linkmauve>
Citra later encountered the same bug I had, it was drawing exactly four triangles in total, each frame.
<linkmauve>
whitequark, uh, is Apple’s driver so bad quality?
<linkmauve>
glGenBuffer should just be a matter of giving you an integer…
<whitequark>
and here we have an excellent example of *why* opengl is not an abstraction
<whitequark>
what glGenBuffers does internally is lets the driver maintain a set of bindings and garbage collect its data structures, but this is not exposed nor explained in the API
<whitequark>
so if I read the API and the driver author reads the API our assumptions diverge because it's so underspecified, and awfulness results
<linkmauve>
I’m pretty sure some drivers only allocate the actual objects on use.
<whitequark>
that doesn't matter
<linkmauve>
Exactly.
<linkmauve>
So why would a driver fail to allocate during another frame is beyond me.
<linkmauve>
Other than it’s a garbage driver.
<whitequark>
it doesn't matter because it's not in the API contract, so I can't say "it's a garbage driver"
<whitequark>
OpenGL never guaranteed to me that I can do this per frame and expect good performance
<whitequark>
juts like it does not guarantee to me that I can use a zillion of its other features and get good performance
<whitequark>
that's why it's shit
<superctr_>
so yeah
<whitequark>
almost everything you can express in OpenGL is something you don't actually want
<superctr_>
one can write a terrible Vulkan backend and then blame all the issues on the API
<superctr_>
or Metal, for that matter
<whitequark>
APIs should be hard to misuse. that's the #1 purpose of designing an API: ensuring interoperability.
<whitequark>
OpenGL does not ensure interoperability.
<whitequark>
it doesn't really ensure anything
<whitequark>
that's why it's shit.
<superctr_>
yeah, but having to add #ifdefs is still better than having to rewrite your entire graphics code from scratch
<superctr_>
which, Metal will force you to do (now you have MoltenVK which if you use, Apple will reject your app)
<whitequark>
POSIX is another absolutely terrible API. but people like it because they didn't have to rewrite their code from scratch (until they do because they need Windows, but I digress)
<whitequark>
"it generally computes something approximating a good result" is the lowest possible bar any program or API implementation can be held to. maybe it was good enough in the 80s when things generally didn't work, but it has not been good enough for like 20 years
<superctr_>
POSIX was defined over a span of 30 years, until someone finally decided to write a document
<linkmauve>
whitequark, that hasn’t been my experience with OpenGL at all tbh.
<superctr_>
no committee or individual created it from scratch
<linkmauve>
Except that some vendors chose not to ship any extension, so performance was obviously sub-par.
<superctr_>
and what you get is a result of that
<whitequark>
sure, and it's the same with OpenGL
<superctr_>
it's like English, you have a language with a lot of features that make no sense, and yet everyone uses it and understands it
<superctr_>
now you could invent your own language which fixes all the issues, call it esperanto or lojban or whatever
<linkmauve>
>everyone
<superctr_>
it's perfect on paper, but if you try to speak it, nobody will understand it
<whitequark>
yeah, because Vulkan totally failed. oh wait it didn't
<whitequark>
i'm not interested in excuses for shitty APIs, i'm interested in APIs that aren't shit
<whitequark>
and complacency is not a way to get there
<whitequark>
raise your bar, people
<superctr_>
well, my issue is that companies see APIs as a way to ensure exclusivity to their platform, and Apple in particular
<superctr_>
since they reject Vulkan et al, and enforce the use of their proprietary APIs
<linkmauve>
superctr_, and Microsoft before that.
<whitequark>
well, I don't know much about Metal or Vulkan, but DirectX is quite a bit nicer than OpenGL
<linkmauve>
Thankfully Google dropped their plans for a third one, and backed Vulkan instead.
<whitequark>
so there's a legitimate technical reason to go for DirectX
<superctr_>
at least on Windows the GPU vendors ensure GL/Vulkan support in their drivers
<whitequark>
and actually a world where Linux graphics is based on DirectX isn't that bad.
<superctr_>
it's of course not perfect, since GPU vendors can't write good drivers
<superctr_>
but MS isn't actively interfering with open APIs, apart from competing against them with DX12
<linkmauve>
whitequark, which reminds me that the new OpenGL driver for my Intel GPU also does support d3d9.
<whitequark>
mesa has supported d3d9 and d3d11 (iirc) for quite a while, though afaik nothing has shipped that uses it
<whitequark>
it's more of a curiosity
<linkmauve>
Not d3d11, that was a one-shot from somebody who abandonned it pretty soon, and it’s been dropped from Mesa not long afterwards.
<whitequark>
ah i see.
<linkmauve>
whitequark, wine does use it.
<superctr_>
there are legal reasons to not use DirectX
<linkmauve>
The d3d9 code.
<superctr_>
MS could pull an Oracle if they wanted
<linkmauve>
superctr_, btw, Khronos also could, against some Mesa drivers which haven’t passed conformance. :D
<whitequark>
^
<linkmauve>
Although there is now an agreement to let them pass it free of fees, if a proprietary driver previously passed it for the same hardware.
<linkmauve>
(Which means the proprietary driver vendor already paid the fee.)
<TD-Linux>
one thing that makes DirectX good is that the part you talk to is not a driver library, it's Microsoft's library
<superctr_>
at least Khronos offers the conformance tests
<TD-Linux>
the driver API is lower level
<superctr_>
the chance that MS will do something similar is 0%
<TD-Linux>
vulkan is basically that. except for the high level library
<superctr_>
Mesa
<Lord_Nightmare>
whitequark: any new news re: the ym2413?
<whitequark>
Lord_Nightmare: still do not have my microscope, I really need to take care of that.
<whitequark>
the guy who fixed it has a schedule that is very inconvenient
<whitequark>
I'll try to arrange things this weekend.
<Lord_Nightmare>
ah
<Lord_Nightmare>
i'm hoping very hard that yamaha did NOT use implant ROM on the earliest production ym2413 chips, but it may be a futile hope
<whitequark>
yeah, I remember that
<whitequark>
I am not sure when I will be able to talk to SEM folks... health being a fuck
<whitequark>
might try to arrange something where I don't have to be physically present there.
<Lord_Nightmare>
whats interesting is i don't think the pss-170 is even the first product that used the ym2413: i think it was used in some sort of set-top-box "CAPTAIN" tv-terminal teletext thing first
<Lord_Nightmare>
but i have no idea the proper name of that product
<Lord_Nightmare>
nor if anyone still has any, they were japan-specific
<Lord_Nightmare>
perhaps the OPLL was used in later CAPTAIN units as a lower cost replacement for the ym3526?
<superctr_>
the OPLL datasheet does say "Tones applicable to the 'CAPTAIN' and TELETEXT are included among built-in tone data"
<superctr_>
probably
<Lord_Nightmare>
I'm convinced that every one of the yamaha FM chips has a product it was designed for, and the fact that it was sold publically was just icing on the cake
<superctr_>
yeah, though the OPN chips were more "general purpose" or directed at PCs in general
<superctr_>
apart from OPN2 series and OPNB, of course, those were directed at consoles and arcade machines respectively
<Lord_Nightmare>
ym2149 was for MSX(?), ym2151 was designed for the SFG-01, ym2203 i think was designed for PC88, ym3526 was for CAPTAIN, ym2413 was probably also for CAPTAIN or for both that and the PSS-170, ym2608 was for later pc88, ym2610 was for NeoGeo, YM2612 was for megadrive/genesis; ym3812 MIGHT have been designed/commissioned by adlib, ymf262 was for creative labs sbpro2
<Lord_Nightmare>
ym3812 is the only one i'm not really sure about
<superctr_>
YM2612/YM3438 was also used in FM Towns
<Lord_Nightmare>
ymf262 was definitely designed for creative labs though, it even maps the two 'halves' of the chip in the same way that the two ym3812s are mapped in the early sbpro cards
<superctr_>
3438 is probably a little special as it was probably intended for the MD until it was realized that it wasn't fully compatible
<Lord_Nightmare>
3438 is weird, i suspect it was designed for the later megadrive/md2 but as you said there were issues with open bus and timing?
<superctr_>
the YMF278B was clearly intended for cheap PC sound cards, being an OPL3 with the wavetable part from the YMW258 (with register map changes) added
<superctr_>
YM2610 was definitely directed at arcade machines in general, it is possible it was commissioned by Taito (or SNK) but i'm not really sure
<Lord_Nightmare>
ymw258 (GEW8) was the second(? or third? gen) yamaha AWM1 sampler, ymf278b is an opl3 plus a gew8, and a simpler bus interface for a fixed function reverb/dsp chip
<superctr_>
the 2203 and 2608 I think were just directed at PCs in general, not designed for anything particular apart from being a logical and backwards-compatible upgrade for the YM2149
<Lord_Nightmare>
the original gew8 had a more complicated interface for an external dsp
<Lord_Nightmare>
Sarayan may end up having to reverse engineer it
<Lord_Nightmare>
i think the gew8 dsp allowed you to upload dsp programs to it
<Lord_Nightmare>
while the opl4 dsp has fixed programs in it in ROM which you choose one?
<superctr_>
ValleyBell spent a lot of time trying to improve OPL4 envelopes
<Lord_Nightmare>
likely the same dsp arch inside if i had to guess
<superctr_>
i think that we can figure out the YMW258 once the H8/500 CPU in the TG100 is emulated :P
<Lord_Nightmare>
sarayan has dome some work on AWM2, which iirc has an undocumented dsp which does the actual waveform processing and filtering
<superctr_>
the DSP used in that module is also undocumented, IIRC
<Lord_Nightmare>
but i believe Sarayan was successful at RE-ing the AWM2 dsp
<Lord_Nightmare>
so some of the tricks there may also apply to AWM1
<superctr_>
OPL4 has no DSP, and samples are transferred to any external DSP via the I2S bus
<Lord_Nightmare>
also opl4 supports 8, 12 and 16 bit waveform modes, while gew8 might only support 12, but i suspect also supports 8
<superctr_>
i believe the particular DSP that was used in OPL4 sound cards was documented to some extent, or at least there is a datasheet
<superctr_>
YMW258 supports 8 bit samples
<superctr_>
Sega uses them
<Lord_Nightmare>
gew6 however (the 'one gen older than gew8 awm chip') i think is 12 bit only
<Lord_Nightmare>
gew8 might support 16 bit too, its not clear.
<superctr_>
that stuff would be possible to verify with a real TG100
<superctr_>
just replace the sample ROM
<superctr_>
no need to worry about offsets as it has that sample table in the beginning of the ROM
<superctr_>
as i've said, when it comes to the sample ROM format, the sample format bits are the only obvious difference from the OPL4
cr1901_modern has joined ##yamahasynths
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
Guessing not, but did I miss anything in the past few days?
<Lord_Nightmare>
cr1901_modern: check the logs
<Lord_Nightmare>
but yes, you did, though i'm not sure how relevant it is
<cr1901_modern>
Right, that would be the smart thing to do.
<cr1901_modern>
I had to go back to the hospital due to neutropenic fever, and when I tried bringing my laptop, the power supply bit the dust. Now I have a new power supply, and I was discharged today.