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
ej5 has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
rainwar has quit []
_whitelogger has joined ##yamahasynths
futarisIRCcloud has joined ##yamahasynths
ej5 has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<Lord_Nightmare>
nice!
<Lord_Nightmare>
cr1901_modern: you mentioned the graphical fm patch editor is not open source?
<cr1901_modern>
as far as I can tell it's not
<cr1901_modern>
but I found onitama's twitter acct, so I can ask them
<Lord_Nightmare>
I was hoping it was, since iirc mucom88's fm editor shows the attack phase of the envelope as being linear, and it definitely isn't; it is logarithmic
<Lord_Nightmare>
would be easy enough to fix on the editor
<cr1901_modern>
The YM* emulation is older... it comes from someone who goes by "cisc"
<cr1901_modern>
last update was like 2004 or so?
<cr1901_modern>
dunno if they emulate an exponential attack
<Lord_Nightmare>
if the funky emulator in mucom doesn't emulate the exponential attack, its emulating the ym2612 wrong
<Lord_Nightmare>
afaik all yamaha chips except maybe the opx and scsp (and aica?) have exp attack; the GEW8/OPL4 AWM sound doesn't (I think? Sarayan mentioned this, IIRC?)
<Sarayan>
LN: awm2 is linear, awm I'm not sure
<cr1901_modern>
Lord_Nightmare: onitama doesn't use IRC, but said I could DM them questions I had, so I asked about FMToneEditor while I had something else to ask about
<cr1901_modern>
Will let you know when I get a reply
<cr1901_modern>
(Apropos: Seeking an appropriate Japanese translation for the following I can copy-paste when required: "I apologize, I cannot speak Japanese. Your English is much better than my Japanese.")
l_oliveira has joined ##yamahasynths
<cr1901_modern>
Lord_Nightmare: The tone editor isn't quite as sophisticated as VGMMM's, but I'm not sure in practice this matters. In particular, you can vary operator parameters while a tone is playing.
<cr1901_modern>
In FmToneEditor, the parameters are fixed until the next note starts playing
<cr1901_modern>
or until the next driver command is parsed by the z80
<cr1901_modern>
(openmucom88 has hooks into the z80 emulation for this)
<cr1901_modern>
Lord_Nightmare: "Not available yet. Should be available in the future."
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Lord_Nightmare>
there's been some efforts to port elona from HSP to java (of all things) because there's an hsp binding for java which allows for functions to be rewritten piecemeal to replace the hsp code
<Lord_Nightmare>
the problem is the person doing this (who got a copy of the elona source code from noa) observed the code is absolutely mind-bendingly horrible, as previously mentioned
<Lord_Nightmare>
i suggested rewriting the whole damn thing from scratch using proper OOP, but the code is so bad it might have to be almost completely rewritten
<cr1901_modern>
Dunno if that can reflect on onitama
<cr1901_modern>
:P
<Lord_Nightmare>
not really, its just a sidestory about hsp
<Lord_Nightmare>
hsp, if you code it RIGHT and properly use functions instead of 500+ globals
<Lord_Nightmare>
is not terrible
<cr1901_modern>
so it's a level more tolerable than GOSUB and "using globals as locals"
<Lord_Nightmare>
hsp does support functions and not just subroutines, and i think later versions even support objects
<Lord_Nightmare>
its basically homebrew functions using gosub and copying variables
<Lord_Nightmare>
which is somehow even worse than just using gosub
<Lord_Nightmare>
that's what elona does
<cr1901_modern>
>its basically homebrew functions using gosub and copying variables <-- objects?
fseidel has quit [Ping timeout: 245 seconds]
<Lord_Nightmare>
since the elona dev didn't understand functions, so they hacked up some half-assed replacement by copying the variables to globals and using gosub
<cr1901_modern>
ahh
fseidel has joined ##yamahasynths
<Lord_Nightmare>
which is i guess technically more or less what functions do behind the scenes in some BASIC variants
<cr1901_modern>
Note I don't actually know basic... limited to looking at snippets of microsoft basic source code to understand it's memory allocation scheme
<Lord_Nightmare>
basic is like c--
<Lord_Nightmare>
it does have some functions like PLOT etc but they're implementation specific
<cr1901_modern>
well microsoft basic has essentially a monolithic chunk of memory for everything, divided into 5 or so sections. And it will happily memmove later sections when you allocate data in earlier sections
<cr1901_modern>
so that's fun
<cr1901_modern>
O(n) time worst case allocation
<cr1901_modern>
where "n" is "size of chunk for RAM storage"
<cr1901_modern>
At least Baker's Real Time GC gives you a constant time worst case, and that's been around since... the late 70s?
<Lord_Nightmare>
basic also has strings as first class objects, but in many basic implementations you have just 26 strings to work with, $A thru $Z
<Lord_Nightmare>
ms-basic's 6502 port at least has a very bad bug with garbage collection and strings, which is patched in later implementations
<Lord_Nightmare>
the OSI scientific version of ms basic (which was one of the first 6502 versions) has the bug
<Lord_Nightmare>
most people swapped one ROM for a patched version
<whitequark>
cr1901_modern: hbaker's realtime GC is very space inefficient
<whitequark>
it makes total sense to not use it for a BASIC impl on a 6502
<cr1901_modern>
yup, that's saying the quiet part out loud :P
<cr1901_modern>
So shhhh! :P
<whitequark>
i mean that's why no one uses it
<whitequark>
i've never seen it in the wild
<whitequark>
not even picobit iirc?
<whitequark>
yeah, picobit would have huge GC pauses
<cr1901_modern>
If I were doing a "for fun" Lisp, I would implement Baker's GC. B/c it's well, for fun :).
<l_oliveira>
cr1901: the windows version of openmucon88, the programs are HSP applets, they load a DLL which is the Z80 emulator and the real mucon88 core
<l_oliveira>
there are source code for some of the applets but not all of them
<cr1901_modern>
I've only looked at the windows part of the source code
<cr1901_modern>
the z80 assembly files are available but aren't formatted properly
<cr1901_modern>
and I haven't seen the rest
<l_oliveira>
for me that is a bit troublesome because I have a old VAIO subnotebook with a Crusoe CPU which has no SSE, I can't run some of the stuff (tone editor, for example) because it is compiled in a .exe format which is not compatible with windows xp
<l_oliveira>
the source for the DLL is full on the archive so I was able to rebuild it for Windows XP without SSE instructions
<l_oliveira>
the DLL is the actual core of the thing so it isn't too bad
<l_oliveira>
the applets that don't work make
<l_oliveira>
Windows XP output this message: "This is not a valid win32 application"
<l_oliveira>
I believe they're in a format that is valid only from Vista onwards
<l_oliveira>
I've been thinking of contacting Onitama about it with a query regarding that, there might be some sort of solution...
<l_oliveira>
Something that does not involve rebuilding the applets
<Sarayan>
what is this mucom thing?
<cr1901_modern>
Sarayan: It's Yuzo Koshiro's software to create music
<cr1901_modern>
he open sourced it recently and onitama of Hot Soup Processor fame (yea I'm in the know, right :P) made it run on Windows and *nix
<cr1901_modern>
by providing YM2608 and z80 emulators
<Sarayan>
fun
<cr1901_modern>
it's an MML compiler. Presumably the output is a list of music driver commands that Yuzo Koshiro's z80 music driver understands
<Sarayan>
MML?
<cr1901_modern>
Music Macro Language
<Sarayan>
interesting
<ValleyBell>
Lord_Nightmare: OPL4 uses the same formula as YM2612 for attack and decay.
<ValleyBell>
l_oliveira helped me to do quite a few tests with real HW some time ago.
<Lord_Nightmare>
ValleyBell: for the pcm part?
<Lord_Nightmare>
opl4's fm part should be literally identical to opl3
<Lord_Nightmare>
i'm talking about the pcm player part, which plays pcm data with a header, in "AWM" format
<superctr_>
<ValleyBell> Lord_Nightmare: OPL4 uses the same formula as YM2612 for attack and decay. <- MetalliC told me the envelope generator is shared between most if not all Yamaha chips
<superctr_>
Perhaps it could be used to fix the YMF271 (OPX) envelopes, which apparently are too fast compared with hardware recordings (Stefan L made some digital recordings, maybe they're still available)
Xyz_39808 has quit [Quit: Leaving]
Xyz_39808 has joined ##yamahasynths
Xyz39808 has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 240 seconds]
<Lord_Nightmare>
someone reported a bug/issue on MAME saying the ym2608 ssg-eg stuff is wrong in MAME
<Lord_Nightmare>
and supplied a vgm file demonstrating it supposedly
<Lord_Nightmare>
they may well be correct that it is wrong, but i'm not sure at the moment
<superctr_>
i saw the original issue in bambootracker
<superctr_>
They used a hacked NukedOPN2 core with ADPCM support and supposedly that's how the issue was found
<ValleyBell>
re: OPL4 - the bitshift used in the attack phase seems to differ between OPL4/YM2612 (>>4) and OPL2/3 (>>3)
<ValleyBell>
And the YM2608 and YM2612 is split in MAME, yes.
<ValleyBell>
and most of the fixes (and temporary breakings) only ended up in fm2612.c
Xyz39808 has quit [Read error: Connection reset by peer]
<cr1901_modern>
indeed... what's that a PCengine on a chip (I see the hudson bee)?
<TD-Linux>
a pcfx on many chips
<cr1901_modern>
on a card*
<TD-Linux>
it's a garbage system, don't get one. that's why I have two (the c-bus version as well)
<cr1901_modern>
I mean I have a Virtual Boy. Kinda too late for me to not like garbage
<TD-Linux>
it has the same cpu as the virtual boy so you're in luck
<cr1901_modern>
oh right... I keep forgetting about that
<cr1901_modern>
v810 is prob my fav risc cpu out of a sea of risc cpus- 16 bit insns WITHOUT the need for a literal pool (looking at you SuperH), no delay slots, little endian (Well the world decided this for me, I don't really care), bit string insns, none of that hi/lo crap (IIRC it only has MUL anyway)
<cr1901_modern>
riscv IMC w/ a bit string insn non-standard extension would be the next closest thing
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]