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…]
<cr1901_modern> chakan is painful to listen to
<Xyz_39808> duhguh duhguh duhguh duhguh duhguh duhguh duhguh duhguh BWAHH BWAHH BWOHH BWEHH BWEHH
<cr1901_modern> Yea, something like that
<cr1901_modern> Like HOW did this pass QA?
<cr1901_modern> (Clarification: The sfx in particular shouldn't have made it past Q&A. I'm neutral on the music.)
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 264 seconds]
andlabs has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nukeykt has joined ##yamahasynths
andlabs has joined ##yamahasynths
<cr1901_modern> nukeykt: Oh cool, you're here so I can ask you something :P. A couple of VSTs of your cores have appeared recently (I'll see if I can find the link). Did you have any involvement w/ creating them?
<Lord_Nightmare> I'm not nukeykt, but my personal opinion is as long as they're vst3 vsts (since the vst2 headers are incompatible with the gpl afaik?) and the source code is available, i don't see much of an issue.
<cr1901_modern> I wasn't worried about that... I was just curious if he was involved in making them/how hard it would be
_whitelogger has joined ##yamahasynths
natalie is now known as Guest55222
Guest55222 is now known as natarii
<nukeykt> Nope
<cr1901_modern> nukeykt: I see, and I can't find the damn link at this time. I've been meaning to download Ardour and play w/ your OPN2 core in it via the VST plugin
<cr1901_modern> Yes, that is in fact EXACTLY the link I was looking for, and Idk why I keep losing it lmao
* cr1901_modern bookmarks it
<cr1901_modern> Lord_Nightmare: You can't actually get the VST2 headers anymore, correct?
<Lord_Nightmare> not legally
<cr1901_modern> the linked project claims to be able to build VST2 plugins
<cr1901_modern> Not that I care about that :P
<Lord_Nightmare> if you google for the filename you can find the sdk but its illegal to use, and technically illegal to link against a gplv2 or v3 project
<cr1901_modern> Well I'm not about to call the copyright police on them, just was a curiosity
<Lord_Nightmare> nukeykt: where is nuked-opl source code btw? it isn't on https://github.com/nukeykt/Nuked-OPL where i'd expect it to be...
<cr1901_modern> https://github.com/chocolate-doom/chocolate-doom/tree/master/opl It's in Chocolate Doom as well
<cr1901_modern> (I thought Choco Doom was mainly Vanilla Doom w/ bugfixes, thus only ran on DOS or in DOSBOX)
<Lord_Nightmare> https://github.com/Wohlstand/libADLMIDI has its license set wrong: since it includes nuked-opl the whole project has to be licensed as gplv2, not lgplv2
<nukeykt> chocolate doom one is original code, NBlood one has modification for full stereo panning
<Lord_Nightmare> because of that, https://github.com/jpcima/ADLplug also has its license set wrong since it links to libADLMIDI
<cr1901_modern> Unless an exception was granted
<nukeykt> nuked opl in libadlmidi is lgpl
<Lord_Nightmare> ah, so it has different licenses
<Lord_Nightmare> in different places
<Lord_Nightmare> sorry for coming to the wrong conclusion
<Lord_Nightmare> i should check the header next time
<Lord_Nightmare> i think JACK may have its own reverse-engineered vst2 headers which are allowed for gpl (or lgpl?) use
<Lord_Nightmare> not sure
<cr1901_modern> I was curious to the extent that the VST2 headers are "difficult" to obtain.
<cr1901_modern> USE_NUKED_EMULATOR >Very accurate, however, requires a very powerful CPU
<cr1901_modern> nukeykt: Have you done profiling on nuked-opn2?
<nukeykt> nope
<cr1901_modern> (It works fine for me/at full speed on platforms I care about.)
<cr1901_modern> But curious, since I don't think I would expect even an accurate FM synth to require that much CPU
Xyz_39808 has quit [Read error: No route to host]
Xyz_39808 has joined ##yamahasynths
<cr1901_modern> Gonna try building the VST3 after I sleep hopefully. I wonder if I can use it without Ardour right now? Being a DAW, the learning curve is _not_ something I can sink time into right now.
<cr1901_modern> Maybe in a few weeks...
<cr1901_modern> I just want to "press a key on my MPK mini and have YM3438 goodness come out of my laptop speakers"
<cr1901_modern> (and well, using the knobs to change instrument params live would be nice, but I'm not holding my breath...)
<ValleyBell> I know it's a bad comparision, but I can't run Nuked-OPN2 at full speed when compiled with MSVC 2010's Debug mode on my i7 7700K.
<ValleyBell> The Visual Studio debug mode often is 10x as slow as Release mode though.
<ValleyBell> But I think anything below 2 GHz is out of the question for running Nuked-OPN2.
<cr1901_modern> This is a 2011... I think 2 GHz Core i7
<cr1901_modern> Anyways it's starting to show it's age, even if single core perf hasn't improved much in 8 years
<ValleyBell> Even if you can run it with this, you might have trouble doing something else at the same time.
<cr1901_modern> I didn't appreciate the difference between debug and release until I purposefully compiled llvm in debug mode... HOLY SHIT it's so slow
<ValleyBell> It doesn't seem as bad in GCC
<cr1901_modern> I didn't think it would matter _that_ much
<ValleyBell> but it's really, REALLY bad in MSVC.
<nukeykt> I was able to run debug MSVC build of Genesis Plus GX without any problems on i5-3210m
<cr1901_modern> I haven't looked at the optimized output, but like all good C APIs, nuked* cores provide a pointer to a struct as the first argument. My guess is that all the "->" accesses start adding up in debug-msvc land
<cr1901_modern> ValleyBell: But also, isn't libvgm dynamic dispatch heavy?
<cr1901_modern> (Well, the C version of it anyway)
<cr1901_modern> (And assuming you were testing nuked* as part of libvgm)
<ValleyBell> I think it was slow in both libvgm and VGMPlay.
<ValleyBell> But maybe everything adds up.
<ValleyBell> I also have "edit and continue" enabled in debug mode and I always have the debugger attached.
<ValleyBell> maybe that's a part of it as well
nukeykt has quit [Remote host closed the connection]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
balrog has quit [Quit: Bye]
balrog has joined ##yamahasynths
andlabs has joined ##yamahasynths
nukeykt has joined ##yamahasynths
<cr1901_modern> ValleyBell: What is "edit and con- oh, it's a visual studio thing
andlabs has quit [Ping timeout: 245 seconds]
andlabs has joined ##yamahasynths
<ValleyBell> It's a VS thing.
<ValleyBell> You can set a breakpoint somewhere in the code and it will stop there.
<ValleyBell> Then you can edit your code and it will recompile it AND resume right where you stopped.
<ValleyBell> It's a really neat feature.
<ValleyBell> You would expect something like that to work in interpreted languages like BASIC, of course.
<ValleyBell> But for compiled C/C++ I imagine it gets really complex.
<whitequark> it's surprisingly enough not *that* complex
<whitequark> a runtime with tiered optimizations like JVM already has to be able to backtrack any optimizations it did
<whitequark> and it's easier in a controlled environment like a debugger if you don't have to do that concurrently with other threads or something
<whitequark> all you have to do is to make sure you can determine the values of all locals at a safepoint, and that you can restart from a safepoint
nukeykt has quit [Ping timeout: 260 seconds]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern> hmmm... when you put it that way it seems much more managable
andlabs has joined ##yamahasynths
UnluckyPony has quit [Ping timeout: 245 seconds]
<cr1901_modern> interruptinuse: Okay, I gotta admit, "tsar bimbo" is an excellent pun
<andlabs> ?
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SceneCAT has joined ##yamahasynths