cr1901 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://libera.irclog.whitequark.org/~h~yamahasynths
<fseidel> andlabs: not a YM2151 replacement, but a YM2151 interface board for Arduinos
<andlabs> huh
<andlabs> so it's one of those miscategorized things then ok
<fseidel> looks like there's software to let a PC control the YM2151 via the Arduino's UART, which is kind of neat
<fseidel> no idea how that would fare with stuff that hammers PCM through the thing, like the some Irem BGM...
<andlabs> are you sure about that
<andlabs> which Irem BGM
<andlabs> (I'm fairly certain Irem does not do that)
__sen has joined ##yamahasynths
gatecat_ has joined ##yamahasynths
gatecat has quit [Ping timeout: 268 seconds]
gatecat_ is now known as gatecat
sorear has joined ##yamahasynths
glowcoil has joined ##yamahasynths
<cr1901> ValleyBell: Is there a debug option in VGMPlay to print out where it found its VGMPlay.ini file (if found)?
<cr1901> I need to recompile, but I'm seeing something weird w/ playlists. vgmplay claims to find a vgmplay.ini file when playing playlists only. But not when I play individual VGMs. And the playlist fade time is 0. I don't think I have an vgmplay.inis with fade time 0 for playlists
<NiGHTS> vgmplay/VGMPlay.ini at master · vgmrips/vgmplay · GitHub
<fseidel> andlabs: IIRC Image fight does it for percussion
<andlabs> yeah I'm pretty sure that's just a clever FM voice
<andlabs> I ripped the one from the Stage 1 theme (which was also used in R-Type, which is where I ripped it from)
<NiGHTS> gist:95fe9123ba1a4dc8442eb99e27773d0b · GitHub
<fseidel> andlabs: I thought that, but then I read something somewhere about it actually being low quality PCM hammered through an FM channel
<fseidel> huh, guess I was right initially, I wonder who told me otherwise. >:(
<andlabs> or wait maybe that's the stage 2 one I forget which
<andlabs> it's one of the two
<myon98> I think it was made with one of the operators set to noise mode, I only remember it vaguely though
<fseidel> It sounds a bit like the FM percussion from ChoRenSha68K + Illumination Laser, so it's still totally possible it's FM
<andlabs> besides there's bette rways to do PCM over FM than you describe — CSM mode
<andlabs> then again I don't know if Yamaha ever actually documented how to do the conversion lol
<andlabs> anyway I ahve a different question https://twitter.com/pgandlabs/status/1449199923761750016
<NiGHTS> Pietro Gagliardi sur Twitter : "what do the icons on the back of a DVD mean lol good luck finding out, googling only gives you companies offering to sell you an icon showing a DVD like you would see in Windows Explorer or some shit"
<fseidel> but OPM doesn't have CSM, right?
<NiGHTS> Pietro Gagliardi sur Twitter : "what's this 2 why are there three of them this DVD is only one disc the region code is something different and says ALL I'm confused… https://t.co/Opunu9Z0u1"
<myon98> I remember running into a naive port of Image Fight music data to OPNA, and the percussion didn't work due to the lack of noise mode
<fseidel> guess that settles it then.
<andlabs> yes OPM had CSM mode
<andlabs> I still need to scan my copy of the Japanese version fo FM Music Macro which has the instructions for the SAY command
<fseidel> ah, I see it in the manual. neat
<andlabs> also that's one way to go about not localizing something: Just don't put it in the manual
<andlabs> the ROMs are the same so you can definitely use it in the English version
<andlabs> it'll even speak the error message in Japanese if you use it wrong
_whitelogger has joined ##yamahasynths
<ValleyBell> cr1901: I don't think there is an option for it unless you recompile.
<cr1901> alright, I'll do that some other time
<cr1901> or rebuild in debug mode and run gdb
<NiGHTS> vgmplay/VGMPlay.c at master · vgmrips/vgmplay · GitHub
<ValleyBell> activate this line
<NiGHTS> vgmplay/VGMPlay.ini at master · vgmrips/vgmplay · GitHub
<ValleyBell> The setting in the supplies .ini files is 0.
<ValleyBell> *supplied
<ValleyBell> (was a personal preference back when I wrote VGMPlay initially)
<ValleyBell> alternatively just build the "new" VGMPlay: https://github.com/ValleyBell/vgmplay-libvgm
<NiGHTS> GitHub - ValleyBell/vgmplay-libvgm: a new VGMPlay, based on libvgm
<cr1901> Well when a playlist is loaded, that code path I uncommented is never even hit... huh
<ValleyBell> There are 3 paths where it checks for VGMPlay.ini.
<ValleyBell> 1. /usr/share/vgmplay/ (or whatever prefix you have instead of /usr)
<ValleyBell> 2. the XDG config path
<ValleyBell> 3. the current directory
<ValleyBell> .. okay, the Makefile defaults to /usr/local/
<cr1901> Yea I compiled using the Makefile
<ValleyBell> other spot to activate debug output: https://github.com/vgmrips/vgmplay/blob/master/VGMPlay/VGMPlayUI.c#L377
<NiGHTS> vgmplay/VGMPlayUI.c at master · vgmrips/vgmplay · GitHub
<cr1901> It's not obvious to me... is FindFile_List where the logic for case sensitivity is?
<cr1901> because VGM Player is trying 4 paths (vgmplay.ini, VGMPlay.ini and the full paths to the current directory)
<NiGHTS> vgmplay/VGMPlayUI.c at master · vgmrips/vgmplay · GitHub
<ValleyBell> Yes, there is "file names"
<ValleyBell> and there is "paths"
<ValleyBell> FNList = the file names it tries, for case (in-)sensitivity
<ValleyBell> AppPaths = the folders it walks through
<ValleyBell> I made this clearer in VGMPlay-libvgm.
<ValleyBell> (FindFile_List takes both as arguments there.)
<cr1901> okay I see now
<cr1901> Yea the behavior I'm seeing in vgmplay on Windoze is that none of the debug code paths are hit when loading a playlist
<ValleyBell> ahhh, you're on Windows
<ValleyBell> It should at least hit a few of the code paths there.
<ValleyBell> but it is a lot simpler on Windows
<ValleyBell> You only get two paths: The path of the .exe file and the working directory.
<ValleyBell> oh!
<ValleyBell> I forgot:
<ValleyBell> It clears the screen when playing each song.
<NiGHTS> vgmplay/VGMPlayUI.c at master · vgmrips/vgmplay · GitHub
<ValleyBell> You need to insert a "getchar()" somewhere before that in order to see the scanned paths.
<cr1901> Or I can comment out the cls :)
<ValleyBell> or that :)
<cr1901> Okay, so when a vgmplay.ini is not loaded/found at all, playlist tracks immediately stop when they're over
<ValleyBell> I had to find some way to make the screen not being a mess when playing multiple files in succession.
<cr1901> Except for the last track, which fades out in 5000ms (sic)
<cr1901> not 2000, as is suggested by VGMPlay.ini defaults
<ValleyBell> well.... the logic is this:
<ValleyBell> Tracks "inside" the playlist, followed by another track: FadeTimePL
<ValleyBell> Any (looping) track not followed by another track: FadeTime
<cr1901> FadeTimePL should be defaulting to 2000, but it is not. We can discuss whether I should be using VGMPlay without a VGMPlay.ini at all, but this was confusing the hell out of me tonight :)
<cr1901> this behavior*
<NiGHTS> vgmplay/VGMPlayUI.c at master · vgmrips/vgmplay · GitHub
<ValleyBell> okay, yeah, it's a bug
<ValleyBell> I forgot to initialize FadeTimePL
<cr1901> A Jingle is presumably "a track that does not loop"?
<ValleyBell> VGMPlay-libvgm has it fixed.
<ValleyBell> yes
<cr1901> Okay that's fine, I'll see if I can migrate to VGMPlay-libvgm. I still wanted to know what was going on :P
<ValleyBell> That's fine.
<ValleyBell> VGMPlay-libvgm is a bit more difficult to build, as you need to:
<ValleyBell> 1. use CMake
<cr1901> My sympathies
<ValleyBell> 2. build the "libvgm" submodule first
<ValleyBell> 3. after that you can build VGMPlay
<ValleyBell> Using CMake is totally worth it though, because you can just configure it to not compile stuff you don't need.
<cr1901> Sure, I'm just not a fan of it :).
<ValleyBell> You don't want YM2612 emulation? disable the option.
<ValleyBell> You want YM2612 emulation, but don't care about the MAME and Gens cores? disable them and keep Nuked OPN2 enabled
<cr1901> Should I not bother making a PR for the old VGMPlay?
<ValleyBell> feel free if you want to
<ValleyBell> I don't work on it anymore, but I accept PRs.
<ValleyBell> By now the only thing in old VGMPlay that is missing in the rewrite is support for OPL hardware.
<ValleyBell> (and playing back CMF files, but that wasn't accurate anyway)
<ValleyBell> The old VGMPlay.ini is mostly compatible with the new VGMPlay.
<ValleyBell> (backwards compatibility is important to me, so I try to keep most things working)
<NiGHTS> Initialize FadeTimePL to default of 2000. by cr1901 · Pull Request #86 · vgmrips/vgmplay · GitHub
<ValleyBell> ... noooo
<ValleyBell> you broke the encoding
<ValleyBell> or... so?
<cr1901> That's what I get for not wanting to fire up Atom tonight
<ValleyBell> To be fair, the original file is CP1252.
<ValleyBell> not UTS-8
<ValleyBell> *UTF-8
<ValleyBell> Can you try doing a "git reset HEAD^"
<ValleyBell> and then just check in the change using "git add --patch" ?
<cr1901> This will have to wait till later this weekend. I'm out of energy, and I edited it directly from the GH web editor
<ValleyBell> ooooh, okay
<cr1901> because I thought a one line change would be quick. Apparently not.
<ValleyBell> welll.....
<ValleyBell> You don't have encoding errors documented in a C source file with CP1252 encoding every day :P
<ValleyBell> TBH I have no idea what GitHub did with the encoding.
<cr1901> The glyphs shown in both sides of the diff are the same, but GH claims to have converted the encoding to utf8
<ValleyBell> hmmm ... okay
<ValleyBell> well, I guess I can just merge it then
<cr1901> (Idk if "glyph" is the correct term, but "the actual shape of all the characters matches on both sides of the diff"
<cr1901> D raised to the third power x
<cr1901> D umlaut u x
<cr1901> etc
<ValleyBell> yeah, the "ü" is called "umlaut"
* ValleyBell is still waiting for GitHub to finally offer a "fast-forward merge" option.
<cr1901> I thought it did via a rebase merge
<cr1901> (morally equivalent w/ a single commit)
<ValleyBell> rebase merge still changes the "committer" to me
<cr1901> ahhh
<ValleyBell> > cr1901 authored and ValleyBell committed 3 minutes ago
<cr1901> D to the third power, on the other hand, cannot be expressed in this plane of existence thus has no name
<cr1901> ahhh
<cr1901> Anyways I will look into migrating to libvgm-vgmplay
<cr1901> Can I tell the CMake build to use an external libvgm?
<ValleyBell> It's really nitpicking, but I just want to import the commit as-is without change when possible.
<ValleyBell> yes
<cr1901> Well the "ValleyBell committed" is unavoidable
<cr1901> okay cool, because I keep my own copy of libvgm around already
<ValleyBell> It will just "find" the external libvgm by itself.
<cr1901> If I want to do libvgm dev, can I still point the vgmplayer to my dev repo, or is there better ways to test adding a new core to libvgm?
<ValleyBell> If it should use the wrong libvgm build, just change the "libvgm_DIR" variable.
<cr1901> ahh
<ValleyBell> I have it like this:
<ValleyBell> D:\...\libvgm\buildVC2010
<ValleyBell> D:\...\libvgm\buildVC6
<ValleyBell> D:\vgmplay-libvgm\buildVC2010 - pointing to libvgm VC2010 version
<ValleyBell> D:\...\vgmplay-libvgm\buildVC6 - pointing to libvgm VC6 version
<cr1901> NTFS symlink?
<ValleyBell> The libvgm_DIR variable has to point to the CMake build directory
* cr1901 nods
<ValleyBell> or the directory with the "libvgmConfig.cmake" in it, if you installed it.
<ValleyBell> If you have only 1 instance of libvgm, it works all by itself.
<ValleyBell> You only need to do manual work if you build it in multiple configurations - like I do with VC6 and VC2010.
<cr1901> right, but are you using a symlink to point to each build dir?
<ValleyBell> nope
<ValleyBell> I just set the "libvgm_DIR" variable in the project configuration.
<cr1901> D:\vgmplay-libvgm\buildVC2010 POINTING to libvgm VC2010 version
<cr1901> ooooh
<cr1901> wait nevermind
<cr1901> I get it
<ValleyBell> from CMakeCache.txt:
<cr1901> buildVC2010 contains your CMakeCache.txt
<ValleyBell> libvgm_DIR:PATH=D:/.../libvgm/buildVC2010
<ValleyBell> yeah
<cr1901> nextpnr place-and-route FPGA tool has a similar setup, where you can build the moral equivalent of the "WAD" separately from the rest of the tool, and then set a var to point to the WAD
<cr1901> or you can build the WAD at the same time as the rest of the tool
<ValleyBell> libvgm being a submodule in the vgmplay-libvgm repo is just to ensure that both versions are compatible with each other.
<ValleyBell> I sometimes break the API between libvgm and vgmplay. So I wanted to have a reference to a working state of both in the repo.
<ValleyBell> That doesn't happen very often though.
* cr1901 nods
<cr1901> okay, I think I'm satisfied w/ tonight... did a lot of cleanup and recompiled a lot of tools
<cr1901> Bedtime for me
<ValleyBell> sleep well!
natalie has quit [Ping timeout: 245 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 joined ##yamahasynths
natalie has joined ##yamahasynths
SceneCAT has quit [Ping timeout: 264 seconds]
SceneCAT has joined ##yamahasynths