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 joined ##yamahasynths
<cr1901_modern>
https://github.com/onitama/mucom88/pull/9 Worth a shot. IME most Japanese programmers can speak English fine too. Sample size: The Japanese NetBSD developers.
<whitequark>
that seems like it'd result in self-selection for english knowledge
<cr1901_modern>
Probably LOL
<cr1901_modern>
When valsound was in this room that one night, he explicitly said he was using an autotranslator (which was sufficient for us to have a convo)
<TD-Linux>
also that's like a sample size of 2
<cr1901_modern>
ryoshu, ryo onedera, tsutsuii are three :P
<cr1901_modern>
There's a few more, since they seem to be the ppl interested in keeping NetBSD/68k and OpenBSD 88k alive
<TD-Linux>
>88k
<cr1901_modern>
not a typo :P
<TD-Linux>
I know, didn't realize that port was a thing and that's also well above my level of M
<cr1901_modern>
level of M?
<TD-Linux>
but about the openbsd level
<TD-Linux>
masochism
<cr1901_modern>
indeed
<cr1901_modern>
OpenBSD's gcc is so old it supports Motorola 88k still. So Kenji Aoyama (sp?) keeps the port alive...
<cr1901_modern>
okay I'm procrastinating from learning MML... time to at least TRY to make sounds
<cr1901_modern>
and by that I mean "Google translate"
andlabs has joined ##yamahasynths
<cr1901_modern>
mucom88 is consistently returning a nonzero error code when I run it, so now I have to deal with that before putting it into a Makefile... yay
<cr1901_modern>
whitequark: I used a python wrapper script to work around it. Noted tip for the future tho :D!
<cr1901_modern>
mucom is hardcoded to return "1" when compiling, there's a comment I can't read explaining why
<cr1901_modern>
so I look for either "1" or "0" and pass all other error codes unchanged
<cr1901_modern>
cursed, but it works
<whitequark>
cr1901_modern: i mean you could also use || true
<cr1901_modern>
true... (does that work from cmd.exe? I only went through all this trouble to make it so I could play MML files directly from IDE)
<whitequark>
cr1901_modern: yes
<whitequark>
Z:\home\whitequark>copy || type nul
<whitequark>
Argument missing
<whitequark>
Z:\home\whitequark>echo %errorlevel%
<whitequark>
0
<whitequark>
(that's wine's cmd but it's the same)
<Wohali>
cr1901_modern: i'd take and post a pcb photo for you but i have a cat on me :3
<Wohali>
i don't want to put a pic on social media until i have the store up, though
<cr1901_modern>
whitequark: Thx
<cr1901_modern>
wohali: The happiness of our fuzzy little overlords take priority :D
<Wohali>
yes, she does.
<Wohali>
they feel great though
<cr1901_modern>
Wohali: The PCBs or the cats feel great :D?
<Wohali>
both!
ej5 has quit [Read error: Connection reset by peer]
<cr1901_modern>
https://www.youtube.com/watch?v=drwX7MbB_IE VRC7 is OPL2 right... in "Theme of Iris/Isis" (first track on video), how did they manage to get an echo using only a single channel?
<cr1901_modern>
I understand that if you sum the operators up in OPL2 mode (and delay the attack on one of the operators), you can get two sinusoids where one is a delayed copy of the other
<cr1901_modern>
but the echo'd channel doesn't sound like a pure tone. This seems like you'd need 4 operators- 2 operators generate a complex tone. And the other 2 operators generate a time-delayed version of said tone
<whitequark>
okay, got ym2413bs
<cr1901_modern>
Guess I could cheat and look at the VGM file for Theme of Iris
<whitequark>
ah shit
<whitequark>
0116 datecode
<cr1901_modern>
def misread as ym2413 "bs"
<cr1901_modern>
which... might be apt here
<ValleyBell>
cr1901_modern: Easy - you mix the actual melody with the echo on the same channel.
<cr1901_modern>
I don't understand what you mean or how to do that :(
<ValleyBell>
I never bothered with YM2413 support in vgm2txt, because VGMTool always had superior output.
<cr1901_modern>
link to vgmtool2r5?
<ValleyBell>
just search for it on SMSPower
<cr1901_modern>
(Btw, I feel bad cheating, but I guess it's a testament to how I'm not really a good musician)
<ValleyBell>
I think that composing or arranging and "reverse-engineering" music are different skill.
<cr1901_modern>
perhaps, but analogous to how tracing an artists' work is extremely amoral, I feel the same when REing the actual writes sent to a chip
<cr1901_modern>
like I didn't go through the process/struggle of actually creating music, I just looked at how someone else did it to save me a bunch of pain to get to the same result
<ValleyBell>
Studying other people's styles may help you to do covers in that style.
<ValleyBell>
I don't think it's a bad thing.
<cr1901_modern>
I can't disable channels playing in vgmplay, correct?
<superctr__>
you can edit the config
<superctr__>
but it's more convenient if you use in_vgm or foo_input_vgm where you can disable channels during playback
<cr1901_modern>
YM21280 (OPS)/YM21290 (Envelope Generator)- Used in the DX7 synth. It predates single chip solutions.
<cr1901_modern>
YM2414 (OPZ)
<whitequark>
cr1901_modern: iirc not on ebay
<whitequark>
yeah
<cr1901_modern>
Ahhh okay... all of the chips in that spreadsheet have a link to where you can buy them
<whitequark>
yeah
<cr1901_modern>
It's a nicely organized spreadsheet- adds a modicum of sense to the hell that is Yamaha part numbering
<superctr__>
yamaha part numbering never made sense
<whitequark>
i've just slapped together something to not completely lose track of my yamaha chip "collection"
<cr1901_modern>
OPOMGWTFBBQ
<superctr__>
YM2602 is the master system video chip, YM7101 is the mega drive video chip, but the sound chip is YM2612
<whitequark>
quotes because i don't intend to collect them
<cr1901_modern>
Isn't the YM2602 just TI IP?
<superctr__>
no, it's different
<cr1901_modern>
or did they actually make changes to it compared to the TI VDP?
<superctr__>
it's based on the TMS9918, but they made changes to improve the sprite limit and colors etc
<cr1901_modern>
>because i don't intend to collect them <-- They're still going towards a greater cause :P
<superctr__>
also Yamaha didn't make the original Mark III/SMS chipset, but they got involved somewhere when Sega wanted to increase the amount of sources or something (i think the original SMS VDP was manufactured by NEC or Oki)
<whitequark>
cr1901_modern: i mean
<whitequark>
once i image them i am going to get rid of all the chips
<cr1901_modern>
ahhh
<whitequark>
with the exception of a board that has one of each with digital output
<whitequark>
i guess
<whitequark>
like i don't actually like them that much i guess?
<whitequark>
shrug
<Sarayan>
wq: LN made me remember that my sc01a probably went to dig and that's how we got the good die shots we have :/
<cr1901_modern>
From what I could gather, you would probably have the most fun implementing an FM synth without regard to the limited precision of the Yamaha chips
<cr1901_modern>
Still appreciate the work you've been doing regardless
<Sarayan>
also, ships to ca and us only, beautiful
<cr1901_modern>
And I thought SIDs were expensive
<cr1901_modern>
Trying to look for a link I pasted a few months ago... someone create a Lisp REPL for emitting sound. It would be fun to create an FM operator primitive in that REPL, which you could compose and add together to create algorithms.
<cr1901_modern>
You could even create algorithms that aren't possible on the Yamaha chips (or other physical silicon after Yamaha patents expired)
<cr1901_modern>
Sun Vox has this capability, but it's not FOSS anymore.
<cr1901_modern>
INV_FACTORIAL_*_2PIPOW* appear to be the first few entries of the sine Taylor series?
<cr1901_modern>
... ... ... yea, it's calculating sin(x) by using the Taylor approximation (perhaps it can be better optimized?)...
<superctr__>
you could always replace it with a lookup table + optional linear interpolation if you care
<cr1901_modern>
the library doesn't emulate a particular synth. I guess opting to use floating point directly makes the math easier.
<cr1901_modern>
Of course if you're emulating a particular synth, model everything you can :P.
<cr1901_modern>
It's clear over the years that floating point emu wasn't sufficient for the YM chips
<superctr__>
none of the synths use floating point math (except for the serial DAC output)
<cr1901_modern>
superctr__: No no no, I explained poorly
<cr1901_modern>
what I mean was: "people were able to tell the difference from silicon versus emulation of said chip using floating point"
<superctr__>
i understood already
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<superctr__>
you're saying this library doesn't emulate a particular chip, and thus is free to implement it in whatever way
<cr1901_modern>
right. Subtext: If I were doing a library in the same manner, I would most likely use a LUT
<cr1901_modern>
b/c it's what I'm used to and I don't feel like dealing w/ floating point
<superctr__>
yes, the YM chips were inaccurately emulated using FP and whatever, they weren't completely understood at the time anyway
l_oliveira has joined ##yamahasynths
<cr1901_modern>
Would be curious to hear a comparison video between "YM core emulated properly", and "the same thing, but using floating point to implement the operator instead of the provide sin LUT"
<cr1901_modern>
everything else stays the same, or "as close as possible" to the same
<superctr__>
it's going to be a lot cleaner
<superctr__>
some high feedback / modulation effects are going to sound different
<cr1901_modern>
Well at least it's a legitimate difference, compared to "CD vs analog vinyl" comparisons
<superctr__>
aliasing actually is quite important for some sounds, and effects of this are different even if you run the same chip at a different clock frequency (relative to the tone)
<cr1901_modern>
Not sure I follow... tones are typically represented as a divisor/f_num... wouldn't the normalized frequency (to 1.0 or pi, whatever you want) always be the same regardless of clock freq?
<superctr__>
the frequency adjusts the phase (and thus the index into the lookup table)
<superctr__>
since there is no interpolation between lookup entries, there will be aliasing
<superctr__>
and this is further amplified since operators modulate the phase of each other
<cr1901_modern>
... still not sure I follow. Can I take a rain check?
<cr1901_modern>
I can't give this convo the bandwidth it deserves. I haven't taken DSP in 8 years now lol
<cr1901_modern>
Remember most of it, but some of the finer points got lost over the years
<superctr__>
ok, it's just basic resampling stuff
<superctr__>
the size of the lookup table is effectively smaller when the operator frequency is higher relative to the chip frequency
<superctr__>
it must be resampled
<cr1901_modern>
the operator frequency can either be 0.5, 1, 2, 3, 4, etc times the chip_frequency/(f_num * constant factor)
<superctr__>
you also have the detune parameter
<superctr__>
and LFO
<cr1901_modern>
changing the chip frequency doesn't change the proportion of the frequency of the operators
<superctr__>
not the operators themselves
<superctr__>
but rather the size of the lookup table
<cr1901_modern>
but the number of LUT entries that are jumped over "per n clock ticks" is only dependent on the f_num
<cr1901_modern>
AFAICT, the chip doesn't give a shit which frequency it's run at
<cr1901_modern>
all it cares about is the f_num for the given channel to determine how to index into the LUT
<superctr__>
yeah, the chip doesn't care
<superctr__>
you care, if you want your notes to be tuned at a certain frequency
* cr1901_modern
nods
<cr1901_modern>
(Also, I can empirically prove the chip doesn't care what freq it's run... the OPL2/3 web gateway overclocks the chips when generating audio to send back to the client :P)
<cr1901_modern>
(but it still sounds correct when it comes back to the client)
<superctr__>
i can formulate it differently and say the effects of aliasing change for different tones for a constant clock frequency
<cr1901_modern>
that makes more sense
<superctr__>
if you program an FM chip to do a frequency sweep you'll notice it guaranteed
<superctr__>
And this is also something i test when i see a new "accurate FM emulator"
<cr1901_modern>
w/ floating point, there's probably some level of precision where the same issue applies. Because floating point is, well, discrete. And floating point numbers aren't evenly distributed (though I don't think that matters).
<cr1901_modern>
I doubt a floating point FM synth would ever reach those precision problems tho
<superctr__>
it depends on the precision yeah
<superctr__>
float vs double
<cr1901_modern>
The LUT is a quarter-sine wave, but the entire sine wave can be regenerated from that one quarter. So, aliasing effects start kicking in at the f_num that causes the operator to increment by 512 entries
<cr1901_modern>
256 entires in the LUT, 1024 entries in the full sine wave
<cr1901_modern>
512 entries would be equivalent to pi radians