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
SceneCAT has quit [Ping timeout: 246 seconds]
<Lord_Nightmare>
Wohali: i have two ceramic mc3417 chips here
<Lord_Nightmare>
they're analog CVSD codec chips
<Lord_Nightmare>
unlike the mostly-digital HC55516/55532/55536/55564 chips, the mc3417, mc3418 and the later mc341xx chips which replaced those two are almost entirely analog
<Lord_Nightmare>
afaik the only digital parts of them are the input d-latch and the 3 or 4 bit shifter, as well as the 'overload detector' which fires if the last 3 or 4 bits are all the same value
<Lord_Nightmare>
everything else is analog
<Lord_Nightmare>
while on the hc555xx chips, everything is digital except the voltage comparator
<Lord_Nightmare>
using some extremely clever 1st order IIR filters
<Lord_Nightmare>
this means while the mc3417 needs external components for the output filter and the syllabic filter, the hc555xx does it digitally, internally
<Lord_Nightmare>
jeri ellisworth's reimplementation of the hc55516 is sort of a weird hybrid approach: she implemented the syllabic filter digitally (but without the 'leaky' part of the 'leaky integrator', so it isn't 100% accurate), but the output filter she did using a simple r/c analog filter
<Lord_Nightmare>
once I get an hc555xx and mc3417 and mc3418 decapped, i plan to make a 100% digitally accurate reimplementation of the hc55564
<Lord_Nightmare>
i also have a very weird plan to make a win 3.1/95 16/32 bit ACM decoder for IBM_CVSD wav files
<Lord_Nightmare>
which afaik never had a real digital decoder for them
<cr1901_modern>
ValleyBell: Is this like a kernel mode driver? I wanted something more user-mode (intercept MIDI messages in an application, redirect to libvgm)
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
balrog has quit [Quit: Bye]
balrog has joined ##yamahasynths
Foone has joined ##yamahasynths
nukeykt has joined ##yamahasynths
<cr1901_modern>
nukeykt: Downloading your zip file and gonna play w/ it before bed
<cr1901_modern>
curious how bad it sounds... how'd you derive an opn core when the virtualPC had a (bad) opl3 core?
<cr1901_modern>
okay... this is pretty bad ._.
<cr1901_modern>
Devilish Intro is obliterated by this core
<fseidel>
worse than Genecyst?
<cr1901_modern>
No, I can at least recognize almost all the instruments w/ this core
<cr1901_modern>
but they clip, sound too loud/too soft, bad relative volume between channels, white noise
<cr1901_modern>
etc
<cr1901_modern>
Final boss theme has half its instruments completely overpowered by the other half
<fseidel>
I had a friend in high school who legitimately could not tell the difference between a real sega genesis and the Dreamcast Sega Smash Pack audio
<fseidel>
and that was some BAD YM2612 emulation
<fseidel>
I guess that's how this sort of thing happens
futarisIRCcloud has joined ##yamahasynths
Xyz_39808 has quit [Read error: Connection reset by peer]
Xyz_39808 has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined ##yamahasynths
futarisIRCcloud has joined ##yamahasynths
nukeykt has quit [Quit: Page closed]
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
nukeykt has joined ##yamahasynths
<cr1901_modern>
nukeykt: How'd you construct your OPN emulator from the bad OPL3 one?
<ValleyBell>
cr1901_modern: No, it's a user mode driver. It runs in the same virtual memory space as the process that opens the MIDI device.
<ValleyBell>
(and if my DLL should crash, it will take the MIDI program with it)
<cr1901_modern>
then how does it intercept MIDI calls without relying on kernel mode?
<cr1901_modern>
FWIW, portable virtual MIDI devices is something I'm interested in
<ValleyBell>
It registers itself as a MIDI device.
<cr1901_modern>
And you can do that from user mode?
<nukeykt>
First i partially reverse engineered that opl core, then i ported write handler from my early ym2612 core(that predates nuked opn2), wrote opn2 fm algorithms and made necessary tweaks in other code
<nukeykt>
i didn't bother with lfo and detune implementations
<ValleyBell>
It's just adding a registry entry in a list of DRV/DLL files with audio drivers. Then Windows will will go through that list and try to call the DriverProc function for each file.
<ValleyBell>
something like that
<ValleyBell>
kode54 did most of the research for the BASSMIDI and VST MIDI synth drivers.
<ValleyBell>
and I just took the BASSMIDI one and modified it
<cr1901_modern>
Sounds like a mess to make a portable layer :(
<ValleyBell>
I once wanted to make a generic MIDI driver with a plugin system
<cr1901_modern>
I tried REing the Genecyst OPN to OPL implementation last week, but I kinda rage-quitted when I couldn't get data references to work right
<ValleyBell>
e.g. with a plugin DLL for PSG-only and another plugin for MegaDrive hardware
<ValleyBell>
It's definitely possible, but I never got far.
<cr1901_modern>
I basically want a way to talk to actual FM synths as MIDI devices (without needing to buy a GIMIC), _and_ to provide a fallback if said hardware doesn't exist
<ValleyBell>
That should be no problem
<ValleyBell>
as long as you can get access to the FM synth working
<cr1901_modern>
so enthusiasts without the hardware can still connect their MIDI controller to their DAW and still talk to FM synths, regardless if they have custom FM synth hardware
<cr1901_modern>
ValleyBell: That's the thing... if libvgm could be accessed as MIDI devices, then I get free support for basically every DAW
<cr1901_modern>
if not, I have to write a per-DAW plugin
<ValleyBell>
That mid2smps MIDI driver does just that. You can use it with any program that has MIDI out support.
<cr1901_modern>
(And only one I'm even remotely familiar w/ is Abelton)
<ValleyBell>
I've been using it with MIDI Orchestrator Plus (a 16-bit Windows program) on Win2k/WinXP. Or with WinJammer in Windows 7.
<ValleyBell>
And lots of people are using the MIDI driver with FL Studio.
<cr1901_modern>
I guess I could modify mid2smps for OPM, OPL, etc
<ValleyBell>
and I only ever did one DLL
<cr1901_modern>
I wanted something cross-platform tho
* cr1901_modern
keeps moving the goalposts
<cr1901_modern>
Oh I've no doubt your work is good, just not quite what I'm looking for :P. I wanted a generic API, so say, Rosegarden users can talk to FM synth devices on their Linux laptops
<cr1901_modern>
(is Rosegarden still popular?)
<ValleyBell>
You're not going to be able to have one file that works on both, Windows and Linux.
<cr1901_modern>
Not with that attitude I can't :P
<ValleyBell>
On Windows you need a DLL that uses the Windows driver model. On Linux doing something with ALSA works.
<cr1901_modern>
One file isn't that important... more important is to have a unified codebase where I can have at least some semblance of code-sharing
<cr1901_modern>
ideally, with a unified API
<ValleyBell>
Well... with libvgm I've been try to do that when it comes to audio output at least.
<ValleyBell>
How good are you at compiling code under Windows?
<cr1901_modern>
^I think I've sufferred multiple lifetimes so other people don't have to
<cr1901_modern>
I don't even have Visual Studio installed- I used msys2/mingw64 for everything
<cr1901_modern>
Okay, so Mac has IAC for Virtual MIDI devices. kode54 and ValleyBell figured out how to get a DLL to attach itself as a MIDI device using user mode code in Windows. >>
<ValleyBell>
For Linux, you can just have an application running in the background.
<cr1901_modern>
mofh: When you're around, could you possibly tap into your cursed ALSA knowledge... how would one go about creating a bus for MIDI devices like IAC?
<ValleyBell>
That's what Munt (MT-32 emulator) does
<cr1901_modern>
How does the virtual device side of IAC work then? The same way?
* cr1901_modern
does not own Mac hardware at the moment
<cr1901_modern>
yes I really should go on Craigslist to find one for cheap
<cr1901_modern>
or I guess I could run it in KVM, which IIRC is what whitequark does for solvespace dev
SceneCAT has joined ##yamahasynths
l_oliveira has joined ##yamahasynths
<cr1901_modern>
ValleyBell: Do you have any applications of libvgm that use dynamic dispatch to choose the core at runtime (including the penalty taken for "vtable" access each time)?
<ValleyBell>
all of them do
<cr1901_modern>
Okay, so that means the penalty for dynamic dispatch is minimal for meeting timing
<cr1901_modern>
Probably gonna implement libvgm-rs as a trait object (Rust version of vtables)
<ValleyBell>
You can change FCC_MAXM to FCC_MAME and it will use another core
<ValleyBell>
SndEmu_Start() will choose the selected core and return a structure that contains the vtables.
<cr1901_modern>
Oh, prob no need for me to implement it myself then :P
<ValleyBell>
I put some thought into it after getting tired of the mess that I did in VGMPlay. :P
<cr1901_modern>
I thought about making it possible to abstract over the curChip, to return a unified trait object for _all_ libvgm cores (and each function of course requires a vtable access to choose the correct chip, and then _another_ vtable access to choose the correct impl)
<cr1901_modern>
But Idk how useful that is. Making a good Rust API is gonna take a while lol.
<ValleyBell>
That "unified trait" is a struct called "DEV_INFO".
<cr1901_modern>
Ahhh okay, that gives me some inspiration (see DM as to "the technical bullshit as to why I'd reimplement DEV_INFO")
futarisIRCcloud has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nukeykt has quit [Quit: Page closed]
_whitelogger has joined ##yamahasynths
andlabs has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
* cr1901_modern
wakes up
<cr1901_modern>
guess I'll spend some time on libvgm-rs on this lazy Sunday afternoon
<cr1901_modern>
Also distracts me from fixing asyncio problems in Python
<Wohali>
cr1901_modern: boards are fabbed but haven't shipped out yet, am guessing they'll ship tonight. that means I'll have them ~end of week
<cr1901_modern>
Wohali: Excellent, thanks :D
<Wohali>
I then need a few days to ssort out how I'm going to package them, and get some decent shipping estimates from Canada Post. THen I can start accepting payment.
<Wohali>
Most likely I will ship *without* tracking because it's like $30 cheaper, but I might offer the option if people really want that.
<cr1901_modern>
I'll manage to live without tracking
<Sarayan>
that sucks
<Sarayan>
I can't find my sc01a
<Wohali>
cr1901_modern: i don't see anyone really wanting to pay $30 tracking for a $5 item
<cr1901_modern>
right. $5 is not something I'll lose sleep over if something happens to the product I paid for
<Sarayan>
top of the columns is currently incomplete though
<cr1901_modern>
did you ever revert the commit where I broke dietools? Someone who knows the Windoze API intimately is willing to help me implement atomic move correctly, but we just haven't been able to sync
<cr1901_modern>
Also IIRC atomic move is _also_ broken for mview in the POSIX version
<Sarayan>
you broke dietools?
<Sarayan>
ok, what atomic move are you talking about?
<cr1901_modern>
>One of the two "must-have" features I need.
<cr1901_modern>
In case you're curious, and even if you aren't I'm telling you anyway :D
<cr1901_modern>
The second feature is inkscape-like scrolling w/ the mouse
<Sarayan>
yeah, that would be real nice
<cr1901_modern>
which should be relatively easy to impl
<cr1901_modern>
I just haven't done it :P
<Sarayan>
MW, shift-MW, ctrl-MW
<cr1901_modern>
yup, those are great keybindings for moving quickly in a large image
_whitelogger has joined ##yamahasynths
<cr1901_modern>
Sarayan: Anyways like lots of things I do, adding those bindings shouldn't be particularly difficult, just I haven't sat down to actually do it yet. Sometime soon tho!
ahihi has quit [Quit: make something beautiful]
ahihi has joined ##yamahasynths
<whitequark>
cr1901_modern: yes kvm
<whitequark>
you need a really old macos and you have to kind of hack it
<cr1901_modern>
Guess I'll look for mac h/w for cheap then
<cr1901_modern>
ValleyBell: Building libvgm-emu by itself fails w/ "cannot find stdtype.h"
<cr1901_modern>
Looks like it's at the root of the repo?