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
Xyz_39808 has joined ##yamahasynths
<protosphere>
hooray, i finally have something with a real opna to play around with
<cr1901_modern>
protosphere: I see... I'm happy for you :D
<ValleyBell>
(looping is a bit off, which is why the square at the end doesn't sound clean)
<cr1901_modern>
Congrats ValleyBell
<ValleyBell>
thanks
<ValleyBell>
now I just need to come up with a better name than "Roland PCM" for the thing that the CM-32P uses for sound generation
<ValleyBell>
According to the service manual, it consists of two chips - "LP Chip A" (generates PCM address signals) and "LP Chip B" (PCM data decoding)
Xyz_39808 has quit [Ping timeout: 250 seconds]
Xyz_39808 has joined ##yamahasynths
<KitsuWhooa>
neat
* kode54
installs Movist to decode that obscure format video
<andlabs>
not in ffmpeg?
<kode54>
I have that installed, but it's not a video player
<kode54>
whee, H.264 and MP3 in an AVI container
<kode54>
H.264 doesn't really like AVI
<kode54>
then again, neither does MPEG-4
<kode54>
anything that uses out-of-order frame encoding
<kode54>
because those formats that use IBBBPBBBPBBBPBBBPBBBPBBBI.... type arrangements
<kode54>
the way they're arranged in the stream is first the I frame, then all the P frames in that batch, then all the B frames
<kode54>
or at least, it'll be IPBBBPBBBPBBBPBBBPBBBI
<kode54>
the first P will be decoded against the I, then the three B frames will be decoded from that pair
<kode54>
then the next P frame will be decoded from the last full frame out of the BBB set
<kode54>
they're encoded in dependency order, while they're displayed in the correct temporal order
<kode54>
this is a problem for AVI because AVI has no such concept as frame timestamps
<kode54>
so basically, H.264 just "works" in AVI because software knows how to decode typical streams and rearrange them
<kode54>
sorry for the rant
<kode54>
it's a neat work you did there, ValleyBell
<kode54>
looks like you have an off-by-one error on the loop
<kode54>
that tends to have no noticeable effect on most "natural" samples, but causes obvious tuning problems on short chip samples
<kode54>
or brass instruments
Xyz_39808 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 250 seconds]
_whitelogger has joined ##yamahasynths
Xyz_39808 has joined ##yamahasynths
<kode54>
andlabs: for macOS?
<kode54>
aha, ffmpeg does have ffplay
_whitelogger has joined ##yamahasynths
<ValleyBell>
Ah, sorry for the AVI then. I kept tweaking the code until 1:30 AM and just quickly reencoded the AVI that MAME dumped.
<ValleyBell>
I usually use MKV for everything.
<kode54>
sorry for complaining too much
<kode54>
it was a neat video
<ValleyBell>
thanks
<ValleyBell>
some details about the looping bug:
<ValleyBell>
You have a "loop offset" and an "end offset"
<kode54>
huh
<ValleyBell>
the "end offset" is the last sample to be played
<ValleyBell>
so the loop length is (end + 1 - loop)
<ValleyBell>
I think I loop back once sample early (condition "address >= end), because I was trying to generalize the code so that it works for ping-pong mode as well.
<ValleyBell>
Development would also go a lot faster if MAME wouldn't take like 40-50 seconds to link here.
<ValleyBell>
even with only 2 drivers compiled in
_whitelogger has joined ##yamahasynths
<ValleyBell>
... yeah, it took exactly 62 seconds to link now despite everything being on a RAM disk
<cr1901_modern>
On Windoze? Using ld and a debug build?
<ValleyBell>
Windows, yeah
<ValleyBell>
I didn't specify any special parameters when running Make except for "SOURCES="
<ValleyBell>
hmm... maybe using OPTIMIZE=0 would improve it
<cr1901_modern>
are you using ld and a debug build?
<ValleyBell>
I did not explicitly specify any debug flags.
<ValleyBell>
so the answer is "whatever is the default with MAME's build system"
<cr1901_modern>
ahh's what you meant by special parameters. If it was gnu ld and a debug build... ld can sometimes have pathological link times during debug builds on Windoze
<cr1901_modern>
opened an issue for it a long time ago but never heard back
<ValleyBell>
I'm getting a 80 MB .exe file.
<ValleyBell>
There is a large symbol table at the end of it, but IIRC that's the GCC default and you have to explicitly tell GCC to not include that table.
<cr1901_modern>
I'm not sure if it's a large number of symbols period that cause the pathological link times or large number of symbols plus debug info
<cr1901_modern>
Anyways my point is that this doesn't seem too abnormal based on my experiences :P
<ValleyBell>
I'll try OPTIMIZE=0 SYMBOLS=0
<ValleyBell>
... OPTIMIZE=0 makes it worse
<ValleyBell>
makes sense though, so it doesn't remove unused functions and all the code is larger
<ValleyBell>
okay, I cancalled it after 1 minutes of linking
<ValleyBell>
*12 minutes
andlabs has quit [Ping timeout: 252 seconds]
andlabs has joined ##yamahasynths
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…]