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
<kode54>
well, yeah
<kode54>
sustained profit is not growth, it's failure
<kode54>
must grow every quarter, the largest unit of time that any corporation plans ahead these days
<kode54>
sounds like cancer to me
<cr1901_modern>
How apt
ej5 has quit [Read error: Connection reset by peer]
<andlabs>
∫growth dgrowth
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<cr1901_modern>
1/2*(growth)^2
ej5 has joined ##yamahasynths
<cr1901_modern>
I'm sorry, "1/2*(growth)^2 + C"
<cr1901_modern>
better include the constant before the calculus police come after me
andlabs has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined ##yamahasynths
<andlabs>
is there a good tool that will let me convert any 4-op FM voice from any FM voice file format to any other FM voice file format
<andlabs>
I can use vampirefrog's csv conversion tools but that doesn't get anything out
<andlabs>
I found OPN2BankEditor but it's really geared toward full banks
<andlabs>
and I can't import OPM files into BambooTracker
<cr1901_modern>
I'm not aware of any such tool
<cr1901_modern>
inb4 xkcd comic about 15 standards
<Lord_Nightmare>
there's like 15 different patch standards
<Lord_Nightmare>
for fm patches
<Lord_Nightmare>
some don't preserve the LFO (AMS/FMS), panning and per-operator key-on info, and some do
<Lord_Nightmare>
TFI, for instance, loses all that information
<Lord_Nightmare>
VGI (the followup to tfi also made by shiru) does preserve that
<Lord_Nightmare>
WOPN does preserve the global lfo info (like GEMS patches do) but doesn't preserve AMS/FMS for some reason (I suspect an accidental omission from the standard tbh)
<cr1901_modern>
I would "just" create a json or some other human-readable extensible serializable format, make a naive tool in Rust or Python, and then write converters, and warn about losses
<Lord_Nightmare>
GEMS patches ironically preserve everything EXCEPT for the SSG-EG settings per-operator
<Lord_Nightmare>
including the global LFO and ch3 mode state
<cr1901_modern>
extensible as in "just keep incrementing the version number everytime someone needs something else"
<Lord_Nightmare>
the fact that gems preserves the global lfo state actually was a PROBLEM
<Lord_Nightmare>
since the FMLIB patches that gems shipped with often have the global lfo timer set differently
<Lord_Nightmare>
and if you mix those patches at once, you get weird problems and cross-patch lfo screwyness
<cr1901_modern>
... huh
<cr1901_modern>
I imagine there's a "best-guess" calculator to get patches to play nice when LFO timer bases differ
<Lord_Nightmare>
this may explain some of the sometimes-undeserved but sometimes-deserved reputation that GEMS had for being a 'bad sound engine' for genesis games
<Lord_Nightmare>
if you used GEMS properly you could make very good stuff with it
<cr1901_modern>
I don't like the fact that to get 50/60Hz in GEMS you have to redo the whole track
<Lord_Nightmare>
GEMS had some design warts
<cr1901_modern>
other than that, most ppl didn't create good instruments w/ it
<Lord_Nightmare>
the FMLIB instruments it shipped with weren't that bad, barring the global lfo issue i mentioned
<Lord_Nightmare>
also gems has a known bug where the enable button for operators 2 and 3 are reversed
<Lord_Nightmare>
the fmlib patches were clearly created by someone who knew about that bug
<Lord_Nightmare>
since they work around it
<cr1901_modern>
TLDR: A universal patch format is going to be screwy b/c they tend to be tied to a driver, albiet unintentionally
<Lord_Nightmare>
i wish the GEMS source code for the dos client was around, since it should be possible to fix all the issues in it
<cr1901_modern>
Or at the very least, patches can't be converted into a universal format w/o loss of info
<cr1901_modern>
such as GEMS bugs
<cr1901_modern>
i.e. a round trip from GEMS->Universal->GEMS will lose that info
<superctr_>
and I can't import OPM files into BambooTracker <- OPM files are plain text, and the register order is basically the same as MML formats like PMD for example
<superctr_>
you just have to remove the "M1:" "C1:" etc
<andlabs>
oh I missed stuff
<andlabs>
uhh
<andlabs>
I thought the YM2612 only had one global LFO
<andlabs>
and I forget what chip the TFM module used
<andlabs>
GEMS is very strange because it tries to be clever
<andlabs>
superctr_: and which order is M1, C1, M2, and C2?
<andlabs>
1234? 1324?
<andlabs>
the OPM format also loses the SSG-EG setting because OPM doesn't have that
<superctr_>
it's in the regular 1234 order in the file
<andlabs>
hm
<andlabs>
ok
<andlabs>
[15:26:29] <Lord_Nightmare>also gems has a known bug where the enable button for operators 2 and 3 are reversed
<andlabs>
enable button?
<cr1901_modern>
Is the 1234/1324 thing a hardware bug or an official documentation bug?
<cr1901_modern>
The 1/3 format means "both modulators"
<superctr_>
it has to do with the chip's pipeline
<cr1901_modern>
and 2/4 is "both carriers"
<andlabs>
also I still need to sysex dump the FB-01 voice bank
<superctr_>
the chip fetches 1 and 3 first and then 2 and 4, i think
<cr1901_modern>
which makes sense to me, tbh
<cr1901_modern>
actually maybe not... hmmm
* cr1901_modern
is too fried to think about it
<cr1901_modern>
mod 3 will need the output of carrier 2 if algorithm 0 is chosen, for instance
<andlabs>
the naming is a holdover of the specific chips
<cr1901_modern>
and afaik, there is no interlock at all in these chips
<superctr_>
output of one of the operators are latched for some special cases yeah
<andlabs>
M1/C1/M2/C2, like calling FB FL and ALGO CONN, are all properties of the YM2151 manual
<cr1901_modern>
so if your current pipeline stage misses it's input data, you're SOL
<andlabs>
and is likely itself a holdover from the 4-op mode of the YM3528
<cr1901_modern>
unless like superctr_ just said, there is some op forwarding
<andlabs>
which is just tying two channels together somehow
<andlabs>
I hae yet to look into anything OPL
<andlabs>
I don't know how the 1/3/2/4 thing became part of sound drivers
<andlabs>
if it's just an implementation detail
<cr1901_modern>
the ym2608 docs definitely do the 1/3/2/4 thing
<andlabs>
'oh that explains it
<andlabs>
we do really need to dump all the voices from the keyboards and voice modules
<andlabs>
*MIDI modules
<andlabs>
I can't think of a better explanation of how people got good at making FM voices than that
<cr1901_modern>
Trial and error. And being naturally talented :P
<cr1901_modern>
No seriously, I think it was legit trial and error
<superctr_>
sound driver can take advantage of the 1/3/2/4 order when doing volume-TL conversions
<cr1901_modern>
I know of ppl who won't share their patches b/c the time commitment they had was too great to find them in the aether
<superctr_>
because the operators are always sorted with the carriers last, regardless of what algorithm you use
<cr1901_modern>
... huh
<superctr_>
so you just have a simple lookup to check how many carriers the specified algorithm has, and then you go backwards from op 4 when applying channel volume
<andlabs>
neat
<andlabs>
definitely an advantage with the z80
<andlabs>
oh yeah, also: the fact not one, not two, but four major Japanese home computers had OPM or OPN chips as either built-ins or almost universally ubiquitous addons
<andlabs>
compared to ... zero in the west
<superctr_>
sadly, the IBM music feature card was not "universally ubiquitous"
<superctr_>
if it was, we'd have at least OPM
<cr1901_modern>
if it werent for Genesis, OPL would be the only thing in the west
<superctr_>
(actually OPP but nobody cares)
<cr1901_modern>
wait, there was an OPM card for Western martkets?
<andlabs>
how arbitrary is yamaha's arbitrary codenames anyway
<andlabs>
yes, a PS/2 extension that lasted all of several months and is now ultra rare
<andlabs>
this was before Windows added multimedia stuff
<cr1901_modern>
wow
<superctr_>
at least a handful of games supported the MFC
<superctr_>
quite a few sierra games did, actually
<andlabs>
yeah but sierra games supported everything
<andlabs>
wouldn't be surprised if there was one that supported that not-SSI 2001 that came out three years before the SSI 2001
<cr1901_modern>
OPM, AFAIK, was the first single-chip Yamaha chip. It has 4 operators per channel. I LOVE OPL music when it's done right, but even before OPM you could find 4-op multi-chip solutions
<andlabs>
also, *five if you count the FM TOWNS which came later
<cr1901_modern>
were ppl really only creating instreuments using 2ops per channel even when the functionality to do 4 was avail?
<cr1901_modern>
Such that OPL was a good investment?
<andlabs>
I think the thing was that Adlib was both cheap and mostly off-the-shelf parts
<andlabs>
so it was super easy to be Adlib-compatible
<andlabs>
and you can bet your ass Creative was down for that shitw hile slowly building a sound monopolyu
<superctr_>
adlib actaully scratched out the part numbers from the chips
<cr1901_modern>
I meant what was going through Yamaha's mind at the time. Was OPL (the original) at late edition to the synth family?
<superctr_>
OPL came later yeah
<cr1901_modern>
Hmm, I guess 2-op music _did_ have a market then when 4-op was possible
<andlabs>
again, cost
<andlabs>
Yamaha's 2-op chips were used in their low-end keyboards
<superctr_>
OPM came first, it was yamaha's first single chip FM iirc and it was intended for consumer applications (MSX)
<andlabs>
that ended well
<superctr_>
OPN was sort of an upgrade for the YM2149/AY-3-8910 with FM tacked on, probably also intended for MSX
<cr1901_modern>
My theory is that while it's easier to create 2-op instruments, it's more difficult to create music that sounds good with solely 2-op instruments
<andlabs>
though keep in mind that Yamaha spent 10 years only ever shoving FM into their organs before realizing "ehy maybe everything else should use it"
<superctr_>
OPL was originally designed for a japanese teletext system called CAPTAIN
<Lord_Nightmare>
cr1901_modern: the 1234-1324 thing i suspect came about due to really bad translation/documentation in the yamaha docs sent to sega of america, the https://segaretro.org/images/a/a2/Genesis_Software_Manual.pdf document and "sega02.doc" which is based off of it or is the source of it
<Lord_Nightmare>
the real logical yamaha datasheet operator order is 1->2->3->4 for algorithm 0 I believe
<Lord_Nightmare>
sega docs say the order is 1->3->2->4 which is... well, if you call 2 "3" and call 3 "2" correct.
<superctr_>
the physical order is 1-3-2-4, it's the order the operators registers are stored
<cr1901_modern>
YM2608's official Yamaha docs use 1/3/2/4
<superctr_>
1-2-3-4 is the logical order
<Lord_Nightmare>
however the register order on the chip (as noted in the ym2608 datasheet) is 1/3/2/4 which is also the order that the operators are processed in
<Lord_Nightmare>
meaning 1 comes before 3 comes before 2 comes before 4 in incrementing register order
<superctr_>
sega2.doc should be burned in a fire
<cr1901_modern>
well, yes
<Lord_Nightmare>
and the chip internally processes the operators in that same order: 1 3 2 4
<cr1901_modern>
Surprised anyone could get anything even blitted to the screen w/ that shitty doc
<superctr_>
as i said, regarding the 1-3-2-4 order, you can take advantage of it when calculating volumes
<superctr_>
so it make sense to expose it
<Lord_Nightmare>
but logically in 'what modulates what' order, the order (assuming yamaha numbering in ym2608 sheet) is 1->2->3->4->output
<superctr_>
it's what i said, the carriers are always last no matter what algorithm you use
<Lord_Nightmare>
this is consistent with the M1/C1/M2/C2 numbering in the ym2151 datasheet
<superctr_>
the M1/C1/M2/C2 numbering is actually only relevant if you use alg 4
<superctr_>
though it makes sense considering the chip's pipeline
<cr1901_modern>
I do love how we can spend 45 minutes discussing the order of numbers in this channel :D
<Lord_Nightmare>
its like google wave except with permissions that make sense
<Lord_Nightmare>
and just as hard to archive
<superctr_>
it's like slack for gamers
<Lord_Nightmare>
and unlike google wave, it still exists
<superctr_>
most google products don't exist 5 years after they're made
<Lord_Nightmare>
well, the backend but not the presentation end of google wave is now apache wave, and is an archived/abandoned project
<superctr_>
apache is the open source graveyard
<cr1901_modern>
I hope Stadia burns in a year
<cr1901_modern>
tbqh
<cr1901_modern>
I want that waste of electronic bandwidth to fail so badly
<Lord_Nightmare>
the 2<->3 swap in GEMS is because that pdf file gets the key-on register enable order wrong assuming the other regs were swapped
<superctr_>
i can't see how stadia will ever take off unless google puts servers within 200 km of everyone's homes
<Lord_Nightmare>
that document is god awful, half of it follows the ym2608 numbering and half follows the stupid wrong gems order numbering
<Lord_Nightmare>
so no wonder gems got it wrong
<Lord_Nightmare>
and of course, .tfi follows the wrong numbering
<Lord_Nightmare>
oddly enough, gems' .pat file format stores the operators in the CORRECT order
<Lord_Nightmare>
its the gui which is wrong
<Lord_Nightmare>
well, it stores the operators in flow order
<Lord_Nightmare>
the .pat format
<Lord_Nightmare>
which is kinda weird since in reality they're stored in regs in flow order
<superctr_>
did GEMS users ever use the patch editor anyway :V
<cr1901_modern>
Was it a difficult reconciliation to realize that GEMS might be a decent driver even though almost every single soundtrack w/ it kinda sucks?
<superctr_>
i mean every single GEMS game uses the same patches...
<Lord_Nightmare>
i assume they did. i know at least one composer who did
<Lord_Nightmare>
incorrect
<cr1901_modern>
I confess: I can't get excited about GEMS
<Lord_Nightmare>
GEMS shipped with FMLIB and many GEMS games are based off of that
<Lord_Nightmare>
but not all of them
<Lord_Nightmare>
the copy of GEMS 2.0 that's floating around actually someone edited 3 of the patches in fmlib
<Lord_Nightmare>
so its a tainted copy
<Lord_Nightmare>
i was sent a raw untouched copy by a genesis sound developer person who worked on some games back in the day
<Lord_Nightmare>
afaik the copy of gems 2.0 floating around was from barry leitch, leaking along with a bunch of stuff he worked on
<Lord_Nightmare>
it has the subdirectories stored in .arj files
<superctr_>
you can also thank barry leitch for "leaking" the N-SPC driver source code, at least one of the variants of it
<cr1901_modern>
but it's clear that it wasn't optimized for any instrument set
<superctr_>
someone on assemblergames released another variant, that was used in a lot of games
<Lord_Nightmare>
n-spc? what's that?
<superctr_>
nintendo's standard SPC700 driver, used in a lot of first and third party games
<Lord_Nightmare>
i've been hunting for the SNES-EMULATOR-ICD disk for pc88
<Lord_Nightmare>
it had a dos and a pc88 floppy
<Lord_Nightmare>
someone dumped the dos disk but NOT the pc88 one
<Lord_Nightmare>
i believe the original sony spc700 brr encoder is on the pc88 disk
<Lord_Nightmare>
the one used for super early games like alttp
<Lord_Nightmare>
i really want a copy of that
<Lord_Nightmare>
and smw
<cr1901_modern>
why would the encoder be on the pc88 fdisk?
<Lord_Nightmare>
afaik nintendo never widely distributed the original sony encoder, which is mentioned in the sony patents
<Lord_Nightmare>
but they definitely had a copy of it
<Lord_Nightmare>
later devs wrote their own brr encoders
<Lord_Nightmare>
i know ea tiburon wrote their own from scratch, hell, i even know who wrote it
<cr1901_modern>
Or more specifically, why would there be a DOS disk (for US devs), and a pc88 disk (for JP devs), but not put the same freaking contents on both?
<Lord_Nightmare>
i think you were supposed to have both a pc88 and an ibmpc tehthered together for the snes emulator thing but i may be wrong
<cr1901_modern>
that's... weird
<Lord_Nightmare>
one for gfx/sound dev (pc88?) and one for code dev/debugging (ibmpc?)
<cr1901_modern>
DOS wasn't popular in JP AFAIk
<Lord_Nightmare>
pc88 had a version of msdos on it did it not?
<cr1901_modern>
Sure, but it wasn't popular.
<cr1901_modern>
err maybe pc98*
<cr1901_modern>
Idk about pc88
<Lord_Nightmare>
kode54 wrote his own brr encoder, and i believe most of the modern snes dev scene encoders are based on that
<superctr_>
some of the nintendo tools mention the Sony NEWS system
<Lord_Nightmare>
his used least-squared error, but i don't know how well it handled the case where a sample loops and propagates error/feedback past the loop point
<cr1901_modern>
AFAIK, BRR is a linear predictive filter. Does it optimize for least-squares minimization or
<Lord_Nightmare>
sony's system DID handle that
<superctr_>
it was a 68k unix system
<superctr_>
actually
<superctr_>
mips
<Lord_Nightmare>
BRR is a 2-memory-cell IIR filter with 4 fixed sets of coefficients
<Lord_Nightmare>
run against a 16.16 fixed point fractional value
<Lord_Nightmare>
the fact that it is fixed point is very important
<cr1901_modern>
ughhhh fixed point
<Lord_Nightmare>
otherwise it will decode completely wrong, particularly the 'tink' sound from alttp
<Lord_Nightmare>
and some sounds in star fox
<cr1901_modern>
Well floating point isn't great either, but... fixed point is something I need like, once per year.
<cr1901_modern>
And I _always_ manage to get some fine detail about using it wrong
<cr1901_modern>
it's supposed to get easier T_T
<Lord_Nightmare>
fatlxception/butcha figured out the decode exact bits by brute force using the echo buffer, only later did psxauthor point out 'oh yeah, that's fixed point math, its almost identical to CD-XA as used on the playstation APU'
<Lord_Nightmare>
and lo and behold it is, and its binary identical either way
<cr1901_modern>
decode exact bits?
<Lord_Nightmare>
fatlxception's way was really gross and involved a ton of shifts and dds
<cr1901_modern>
aren't they in the snes manual (as fractions)
<Lord_Nightmare>
adds
<Lord_Nightmare>
yes, those coefficients are in there
<Lord_Nightmare>
but you need to represent them as 16.16 fractions or else the math doesn't work right
<cr1901_modern>
so if you have the fractions, you have the fixed point numbers :P
<superctr_>
there's a program called "so2sol", which seems like it contains BRR encoder
<cr1901_modern>
oh FML
<Lord_Nightmare>
and the patent did not make that clear
<Lord_Nightmare>
superctr_: interesting! that might be it
<Lord_Nightmare>
there's two copies of the ICD diskette that were dumped
<superctr_>
i don't know if you already have it
<Lord_Nightmare>
the one on assembler, and another long time ago from the zsnes/snes9x dev channel
<Lord_Nightmare>
I have both of them SOMEWHERE but god knows where
<Lord_Nightmare>
BRR is effectively a 2-stage IIR filter with a side channel holding the shift and filter value stored alongside/interleaved with the adpcm data
<superctr_>
this is what the readme of that program says (machine translated)
<superctr_>
For the parameter, specify the “.SO” file. Then, the “.so” file is read, BRR processing is performed, and the “.SOL” file is created.
<superctr_>
Also, if there is a “.so +” file that has been BRR processed, that data will be used. However, in that case, the file name should be “.SOP”.
<superctr_>
[This is because MS-DOS does not accept “+” file names. ]
<Lord_Nightmare>
so its a dual data channel adpcm scheme where there's a dedicated side channel for metadata
<superctr_>
i like the compression used in the Zoom ZSG-2 chip
<Lord_Nightmare>
unlike most of the adpcm schemes like IMA/OKI and Yamaha, which use a single channel for 4 bit data
<superctr_>
it's like bootleg BRR
<Lord_Nightmare>
MSADPCM is a weirdass hybrid scheme: it has a fixed IIR filter, but its sent in the header at the very beginning of the stream block and that's it
<superctr_>
it has a similar sample compression scheme, but just a regular first order IIR filter as compression
<Lord_Nightmare>
the rest is a variant Jayant/Yamaha style adpcm
<Lord_Nightmare>
MSADPCM has like 7 or 8 'standard' filters it comes with built in, but you are allowed to supply your own set of 2 filter coefficents as a secondary header
<Lord_Nightmare>
however on xbla/xna apparently the xaudio library is buggy and doesn't honor this secondary header?
<Lord_Nightmare>
i'd need to ask flibitijibibo about that, since he wrote FAUDIO which is a reimplementation of XAUDIO
<Lord_Nightmare>
iirc when i asked a few years ago he said "nothing i know of uses the secondary header and microsoft docs say not to use it"
<Lord_Nightmare>
so faudio likely does not support it
<Lord_Nightmare>
as for other things that use BRR or derivatives of BRR/CD-XA: the gamecube sound format used for compressing the music in many games including paper mario: the thousand year door
<Lord_Nightmare>
is an expanded version of BRR which has 16 sets of filters, all defined at the beginning of each music file
<Lord_Nightmare>
and a very similar block scheme
<Lord_Nightmare>
there are other weirder adpcm variants than brr, like that one sun used, which is a ccitt standard, pre-GSM
<Lord_Nightmare>
which iirc uses two sets of predictors instead of just one, one for low frequency stuff and one for high
<Lord_Nightmare>
sort of related to sony's ATRAC format, which for a long time the snes dev community was convinced was somehow related to BRR (it isn't!)
<Lord_Nightmare>
ATRAC and ATRAC3 i think use two and three 'bands' of encoded data respectively?
<superctr_>
ATRAC i'm not very impressed with
<Lord_Nightmare>
adpcm in general if you try to cover every case is just fucking awful, look at the ffmpeg source code
<Lord_Nightmare>
its a gigantic clusterfuck
<Lord_Nightmare>
i was looking at it to try to make a consistent decoder engine which could do both OKI adpcm and IMA adpcm, which don't differ that much other than the Q table they use
<Lord_Nightmare>
but ... its a mess
<superctr_>
my small adpcm library doesn't even try to cover all of the formats, just a few ones that are used by yamaha chips
<superctr_>
and i think it's pretty neat, plus it doesn't have that stupid jedi table thing from MAME
<Lord_Nightmare>
"yamaha adpcm" as used on ym2610 ADPCM_B is pretty much a bog-standard implementation of Jayant's 1973 paper
<Lord_Nightmare>
ym2610 ADPCM_A on the other hand is a mildly tweaked version of OKI ADPCM from the msm5205 (including the wrapping behavior which exists in the msm5205 and NONE of the later oki chips, which MAME emulates WRONGLY for the 5205!)
<Lord_Nightmare>
where the q step table is for the OKI chips -1 -1 -1 -1 2 4 6 8
<superctr_>
i know
<Lord_Nightmare>
for ADPCM_A the q step table is -1 -1 -1 -1 2 5 7 9 instead
<superctr_>
don't worry, you don't have to rant about it, it's already documented now
<Lord_Nightmare>
I know but i'm ranting in case some people in here missed it the last two times i ranted about it
<Lord_Nightmare>
btw if you want to generate the q step table instead of storing it in the code itself, its something like step[n] = floor(16*pow(1.1f, n)) where n is 0 to 48
<Lord_Nightmare>
the IMA step table is generated similarly, but requires two values to be tweaked afterward because otherwise they'd be the same as values below them
<superctr_>
i really wonder why yamaha used the oki algorithm for the adpcm-a (and 2608 rhythm rom) anyway
<superctr_>
i'm not sure if doing a minor change to one of the tables would clear patent issues anyway...
<Lord_Nightmare>
my guess is because its really easy to encode in hardware
<Lord_Nightmare>
and on the ym2608 (and y8950) you had an encode mode i think
<superctr_>
they already have two adpcm decoder blocks on the chip...
<superctr_>
the 2608 can only encode adpcm-b samples
<superctr_>
oh you mean that yamaha adpcm is easy to encode, yeah
<superctr_>
one is easy to encode, another is easy to decode
<Lord_Nightmare>
er, no. i though yamaha adpcm is easy to decode, and oki is easy to encode?
<Lord_Nightmare>
yamaha adpcm doesn't need a lookup ROM but oki does
<Lord_Nightmare>
but yamaha adpcm requires two(?) multiplies, and oki requires just one?
<Lord_Nightmare>
which might be why its used for only one channel on the 2610, while oki is for like 8 channels