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
<TD-Linux>
ej5, also cross section of a machined socket would be interesting vs square header socket
futarisIRCcloud has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 246 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 255 seconds]
Ultrasauce has quit [Quit: Ultrasauce]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 250 seconds]
_whitelogger has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##yamahasynths
superctr_ has joined ##yamahasynths
superctr has quit [Ping timeout: 244 seconds]
superctr has joined ##yamahasynths
superctr_ has quit [Ping timeout: 268 seconds]
superctr_ has joined ##yamahasynths
superctr has quit [Ping timeout: 255 seconds]
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<ValleyBell>
cr1901_modern: No, here isn't. It entirely depends on the sound core.
<ValleyBell>
You also can't just have a static list. There are chips like the RF5C68 that have "register" writes and "memory" writes, for example.
<ValleyBell>
It's pretty dynamic.
<ValleyBell>
The R/W functions also handle setting ROM data.
<cr1901_modern>
ValleyBell: Then how are you able to successfully abstract over all libvgm cores to create a VGM player that's core-agnostic when the r/w functions that a core has is dynamic?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<cr1901_modern>
I see... you use "RTTI, but in C"
<cr1901_modern>
and then make sure to only ask for functions which are actually supported
<cr1901_modern>
Yea, I'm afraid libvgm is too dynamic for me to make a good Rust API out of it that isn't "just" light wrappers around the C functions (which may or may not be safe) :/
* cr1901_modern
calls it quits for now
<ValleyBell>
Yeah, I assume that all FM cores have 8-bit offset, 8-bit data writes, for example.
<ValleyBell>
I couldn't think of a better way to catch all the flexibility I need.
<cr1901_modern>
ValleyBell: what I'm likely to do is move all the r/w functions into my reimplementation of DEV_DEF and initialize them all when a DeviceDef struct is created. And if a function that isn't supported for a given device is called, panic (terminate the application).
<cr1901_modern>
in libvgm player, you appear to just skip invalid commands if a r/w function isn't support
<cr1901_modern>
is that part of the spec?
<cr1901_modern>
or is an implementation free to do something else (such as panic)?
<superctr_>
the VGM spec defines lengths of all commands, even undefined ones
<superctr_>
So it is safe to skip unknown commands
<cr1901_modern>
Right, I'm asking if I'm _required_ to skip unknown commands, or am I allowed to panic? (Maybe I'll make it a compile-time option)
<superctr_>
in fact, some "unsafe" commands will have 0x66 as the second byte just to make players stop if needed
<cr1901_modern>
hmmm
<superctr_>
I think it is recommended to keep going, unless you encounter 0x66 or a datablock with invalid length or something
<superctr_>
Some of the packs on vgmrips might even use 0x00 as "nop" to remove unneeded commands
<cr1901_modern>
alright
<cr1901_modern>
If you're _not_ using dynamic dispatch- for instance, you know ahead of time your application only needs one device, such as YM2612- the idea was that I wanted it to be a compile-time error if you attempted to call a R/W function that isn't supported. But that contradicts using dynamic dispatch at all.
<superctr_>
yeah, some lazily done rips might have chips stripped from the header without actually removing their respective commands
<cr1901_modern>
There's probably a way to get Rust to optimize NULL ptr checks out if you're _not_ using dynamic dispatch (and you attempt to call a function that isn't supported, return immediately/remove the function call), but I don't know it offhand...
andlabs has joined ##yamahasynths
<cr1901_modern>
ValleyBell: What's the user parameter in SndEmu_GetDeviceFunc for?
<ValleyBell>
actually, VGMPlay panics on a few commands with undefined size
<ValleyBell>
On the YM2610, for example, the user parameter lets you select between ROM writes to the "ADPCM-A" and "ADPCM-B" ROMs.
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
That will be enough to reimplement emutest.c at least
andlabs has joined ##yamahasynths
<ValleyBell>
If Rust has native audio APIs, you won't even need the "audio" part.
<cr1901_modern>
right, that was my intent :D
<cr1901_modern>
Well, it has wrapper libraries anyway
<cr1901_modern>
Basically I wanted an Rust-ergomonic way to describe a "libvgm device". I will prob try writing my own core at some point, and since I'm going to be bogged down already w/ getting the device logic correct, I'd rather focus on that and have Rust take care of the other stuff I _normally_ don't mind doing in C.
<cr1901_modern>
("Why not use C++, cr1901?" Shut up, that's why.)
<Sarayan>
Why not put it in Mame, cr1901?
<cr1901_modern>
shut up, that's why :)
<Sarayan>
since mame provides everything you need around and you can concentrate on the core itself
<Sarayan>
I'm serious
<cr1901_modern>
Ultimate goal is to interface libvgm to a MIDI controller
<Sarayan>
that's a maybe 200 lines virtual driver you know :-)
<Sarayan>
mame already interfaces the host midi system and the audio system and has sound cores
<cr1901_modern>
I need MIDI input
<Sarayan>
but in any case, as long as you have fun it's cool
<Sarayan>
mame has midi input
<Sarayan>
I've already controlled the emulated mu100 from my psr 540 and a usb-midi gadget
<cr1901_modern>
Then I guess it'll work fine. Libvgm just seemed nicer to play with b/c it's single purpose
<Sarayan>
pitch bending was fun, even if the emulation is currently so-so
<Sarayan>
sure single-purpose helps, but you're missing a lot of infrastructure
<Sarayan>
*because* it's single-purpose
<cr1901_modern>
Sarayan: Fine then... how do I get started?
<cr1901_modern>
oh right, the _other_ thing I wanted to try was tinymml with libvgm :D
<superctr_>
unfortunately, you'll have to deal with MAME's audio backend in that case
<superctr_>
And it's fantastic complete lack of resampling
<superctr_>
Meaning that any sound chip that output at any other rate than the output rate will sound like crap
<cr1901_modern>
? Aren't many of the cores in libvgm already from MAME?
<superctr_>
yes, the cores don't do resampling either
<superctr_>
They just output at their native sample rate
<cr1901_modern>
IME YM2151 output from MAME sounds fine
<cr1901_modern>
even though it's sample rate is ~55kHz
<superctr_>
You then have to resample it to 44.1 or 48 or whatever you use
<cr1901_modern>
right, but if MAME doesn't do that
<cr1901_modern>
why does the YM2151 output on games sound fine?
<superctr_>
MAME just uses nearest neighbor or whatever
<cr1901_modern>
ahhh
<superctr_>
It's acceptable when the FM chips output at a higher than the output rate, because at that point most of the artifacts will be above the hearing range
<superctr_>
Sound chips that output at 20-30khz don't fare as well
<superctr_>
I think the absolute worst case right now in MAME would be the C140
<superctr_>
If you listen to Dragon Saber in MAME and compare with VGMPlay, the difference is like day and night
<Sarayan>
ctr: Mame uses a crappy box filter iirc
<Sarayan>
cr1901: look at the vgmplay driver, it's a decent example of a virtual driver
<cr1901_modern>
if you omit "-o filename" during the MML compilation, the default output name is "mucom88.mub" (a la "a.out" in gcc)
<cr1901_modern>
If you omit "-w filename", the output WAV file when invoked with "-x" is "mucom88.wav"
<cr1901_modern>
If you omit "-x", and supply a "MUB" file, mucom88 will use the host hardware (on Windoze anyway) to emulate an FM synth and play music.
<ej5>
mucom88? *honk*
<cr1901_modern>
ej5: Yea, I just compiled it for Windows tonight
<cr1901_modern>
Combine that with JP-only documentation (let's face it, nobody in the west uses MML) and I think I'm going to have a fun time...
<whitequark>
the worst part about having this hilight is it constantly triggers on youtube video ids
<Lord_Nightmare>
i prefer composing on a tracker or a piano roll (like fl studio and cakewalk use), though i wish i could have one tracker/roll hybrid...
<cr1901_modern>
trackers are just way too unergonomic for me... I'm not sure whether MML will be better
<cr1901_modern>
just "worth a try", since I can compose music in a text editor
<cr1901_modern>
(Ideally I'd use something like Finale, Rosegarden, MuseScore to get free "play notes and they appear on a sheet" support)
<Lord_Nightmare>
sheet music bugs me, i can't sight-read it easily
<Lord_Nightmare>
piano roll is easy to read
<Lord_Nightmare>
tracker is somewhere in the middle
<cr1901_modern>
I played saxophone from age 10 to 18... so I mostly remember how to read sheet music
<cr1901_modern>
(Although I haven't actually touched the thing since I was 21)
<cr1901_modern>
no PRs on mucom88... I wonder if I should open a PR to fix win64 compilation even though I can't speak a lick of Japanese
<cr1901_modern>
(also, there haven't been any PRs yet)
<cr1901_modern>
(seems kinda presumptuous for me to be the first one)
<whitequark>
probably fine
* cr1901_modern
refines his changes to make a PR then
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]