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 quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 246 seconds]
Stilett0-afk is now known as Stilett0
andlabs has joined ##yamahasynths
futarisIRCcloud has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
_whitelogger has joined ##yamahasynths
<ValleyBell> cr1901_modern: Feel free to make a pull request that adds Rust bindings.
<cr1901_modern> The convention is to make it a separate repo. Is it possible to make one under the libvgm GH group?
<cr1901_modern> (More importantly, some care is going to have to be taken for me to get the bindings right. So the bindings will prob need to wait)
<ValleyBell> Right now libvgm is at my private namespace, but when it's "finished", I plan to move it to the vgmrips group.
<ValleyBell> I could do that with your repo as well.
<ValleyBell> The API for the emulation part should be stable.
<cr1901_modern> works for me (I _think_ you can move a rust crate after publishing it, or I can just redirect)
<cr1901_modern> Sure. What I'm seeing from your audemutest is that sampling and playback are coupled to the device emulation?
<ValleyBell> Yes, you just emulate + render as many samples as you need.
<ValleyBell> Actually, reading the backlog more carefully, I noticed that you wanted something else: https://github.com/ValleyBell/libvgm/blob/master/emutest.c
<cr1901_modern> yes, that is what I want right there
<ValleyBell> That one is the "real" simple sample that only does emulation and writes 16-bit stereo samples to a file.
<ValleyBell> Device configuration usually requires only the DEV_GEN_CFG to be filled in. It's only a few sound chips (like the SN76496) that require more parameters.
<ValleyBell> In any case you need to time your register writes based on sample rendering.
<ValleyBell> In emulation, register and memory writes take 0 time. Emulated time only advances when samples are generated.
<cr1901_modern> Idk what my hypothetical application will look like at this point. The Rust bindings are on a "for fun" basis right now :)
<cr1901_modern> and of course that then needs to be resampled to 44.1kHz
<ValleyBell> yeah
<ValleyBell> Though it depends on the sound chip whether or not it can output at 44.1 KHz.
<ValleyBell> Most FM cores will allow rendering at arbitraty sample rates. But sharp sounds and cymbals may sound wrong if you do that.
<cr1901_modern> Right, and Idk how libvgm handles the sample rate mismatch sincr 44.1kHz is baked into the format, but the chances of having an FM synth chip output that as well is nonexistent
<cr1901_modern> does a VGM "delay 1 sample" actually attempt to delay by 1/44100, or are all the delays polled at the end when a buffer is ready to be resampled?
<cr1901_modern> wq's gateware approach will work fine for nukeykt's core, which emulates the chip delays
<ValleyBell> Simplified, it processes all VGM commands from the current sample, then emulates all chips for 1/44100 second, then processes all VGM commands from the next sample, etc.
<cr1901_modern> meaning in some 1/44100 increments, you could process two samples
<cr1901_modern> (since most of the FM chips emit samples at 55kHz or so)
<ValleyBell> yes
<ValleyBell> The resampler takes care of that.
<ValleyBell> It asks the FM chip for as many samples as required for outputting another 1/44100 Hz sample.
<ValleyBell> which may be 0 or more (because if you have a chip that outputs 32 KHz, you may not need to emulate it for every 1/44100 s step)
<cr1901_modern> Is there a way to just get the raw output of the chip over a number of 1/44100 samples without doing anything fancy like sinc resampling?
<cr1901_modern> The idea is that I wanted to throw the samples into a rust function for actually converting to sample rates humans use
<cr1901_modern> (single responsibility principle etc etc)
<ValleyBell> libvgm currently uses a custom linear resampler.
<ValleyBell> But you don't need to use a resampler.
<ValleyBell> emutest.c doesn't do any resampling for example.
<ValleyBell> audemutest.c does resampling (see Resmpl_Init)
<cr1901_modern> What I wanted was: say I send chunks of 1024 samples to the sound card. After emulation at the proper rate, I should get approx 1024 * (55000/44100) samples back from the chip
<cr1901_modern> that needs to be resampled down to 1024
<ValleyBell> yes
<ValleyBell> and you can either use libvgm's resampler for that or do it by your own
<cr1901_modern> okay that answers my question
<ValleyBell> The resampler is just an optional layer you can put on top of the sound core output.
<cr1901_modern> Can it be gated in the CMakeLists.txt file
<ValleyBell> No, it depends on how you code it.
<cr1901_modern> or just "don't use it and it won't be linked in"
<ValleyBell> just don't use it
<ValleyBell> The sound cores will always output at their native rate.
<cr1901_modern> right
<cr1901_modern> Anyways I automatically generated some rust bindings, but of course I don't actually know how to use them right now lmao
<cr1901_modern> rust to C bindings are two-prong... you generate a low-level binding called "libvgm-sys", by convention
<cr1901_modern> and then you generate a high level binding meant for general consumption called "libvgm-rs"
<cr1901_modern> because C code is a good way to invoke UB in Rust without that separation
<ValleyBell> Anyway, I'll start doing some work now :P If you need more help, you need to join the #vgmrips channel on digibase, because there I get notifications when poked.
* cr1901_modern nods
<cr1901_modern> thanks for the pointers
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr1901_modern1 has joined ##yamahasynths
cr1901_modern has quit [Ping timeout: 250 seconds]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
SceneCAT has quit [Quit: *Mreow*]
andlabs has quit [Quit: Textual IRC Client: www.textualapp.com]
andlabs has joined ##yamahasynths
SceneCAT has joined ##yamahasynths
<Sarayan> yay, over 8800 transistors
<Sarayan> hey whitequark, are you around?
<whitequark> yes
<whitequark> Sarayan: ^
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##yamahasynths
ej5 has joined ##yamahasynths
<__sen> Sarayan: 8800 transistors in?
<Lord_Nightmare> ValleyBell: the proper way to do resampling is probably polyphase, i'd assume
<cr1901_modern> https://twitter.com/wootshack/status/1109947702912188417 You can actually hear the attack and decay
<cr1901_modern> (this is the Sonic 1 shield sound effect for those who don't know)