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
_whitelogger has joined ##yamahasynths
<cr1901_modern>
You two have soooo much more patience than I
<andlabs>
fseidel: okay so I've now gone through each connector
<andlabs>
I don't see any HDD connectors, and the two FDD connectors have four wires (black white red blue)
<andlabs>
so IDK
<andlabs>
oooh, it looks like the two FDD cables do not actually connect partway
<andlabs>
I'll join efnet
<cr1901_modern>
Feel free to report back w/ results... I'm kinda curious :P
futarisIRCcloud has joined ##yamahasynths
andlabs has quit [Ping timeout: 240 seconds]
andlabs has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<protosphere>
re: not seeing any HDD connectors, I don’t think there’s any internal HDD connectors in the original model, power or otherwise?
<protosphere>
would be interesting if there is though
<andlabs>
probably yeah
<andlabs>
but yeah at this point I need to figure out what's going on witht he FDD connectors
<andlabs>
both the extra wire and the fact they're not tied together
<protosphere>
hmm, I can open mine to check (it's been converted to ATX) but i won't be back home for a few days
<protosphere>
i wonder if it's just 12v/5v + a ground for each
<protosphere>
my guess would be that white is another ground
<protosphere>
but that doesn't make sense with the white wire going into that other connector
<fseidel>
white is usually standby power on the first gen units, I suspect they may have routed it to the FDDs for some thing that ended up getting axed down the line.
<protosphere>
if all the white wires are connected to a common point that would suggest it's 5vsb, yeah
<protosphere>
maybe to allow for ejecting the drives while the main system was powered off or something
<protosphere>
the original ones do have another disk eject button on the rear which all the later models seem to lack
<fseidel>
well, that would explain it...
<fseidel>
my XVI only has +5/+12/GND going to the FDDs, and no rear disk eject button
<fseidel>
so it seems this may just be a CZ-600C-specific quirk
<fseidel>
err XVI HD, although I think the only difference is that the HDs have the HDD power connector and the non-HDs don't
<andlabs>
ah
<andlabs>
hmmm
<andlabs>
interesting
<andlabs>
would it be safe to wire those all to the same +5vs then?
<andlabs>
+5vsb
<andlabs>
like I'm wondering if I'll need to double up the two FDD wires on the molex too
<fseidel>
I suspect yes, as I can't imagine the eject motors draw all that much power
<fseidel>
my biggest concern would be ATX 5VSB not supplying enough current
<protosphere>
worst case you can probably just leave it disconnected
<fseidel>
I was considering that, but maybe the OG model _always_ uses that rail for eject power?
<protosphere>
i have a regular small form factor atx psu in mine and it works fine, however that is wired up
<andlabs>
well someone in #x68000 said the original PSU was way less than 90W so IDK
<andlabs>
yes my kit is 90W
<fseidel>
yes, that was me
<fseidel>
alt handle.
<andlabs>
oh
<andlabs>
that' shwy I didn't see you heh
<fseidel>
I probably should have clarified, my bad
<andlabs>
what does sb stand for anyway
<protosphere>
standby
<fseidel>
it's usually just there for the soft power switch and power LED
<andlabs>
oh
<fseidel>
but it seems like on CZ-600C, it might be for a power-off disk eject
<andlabs>
I wonder if I can call the hot lines in the double throw power switch of the commodore 128 that =P since I'll be reparing both tomorrow
<andlabs>
and yeah there are disk eject buttons on the CZ-600C
<andlabs>
I should probably take pictures of my units hwen I put them back together
<fseidel>
right, they all have that, but protosphere says there's one on the back of the original model? Mine certainly doesn't have it.
<protosphere>
on mine it's above the sasi port
<andlabs>
yeah
<andlabs>
I thought that was something for SASI but now I know
<andlabs>
anyway putting this thing back together will be the scary part
<andlabs>
because this thing is constructed *very differently* from the XVI/Expert
<protosphere>
i'm just speculating though, i've never actually tried pressing it :p
<fseidel>
yeah, I can confirm CMUCC's Expert HD that the button isn't there on the later SASI models
<andlabs>
our strategy was "remove every screw we can find"
<protosphere>
seems entirely different to the ACE, even
<protosphere>
the PSU is mounted where the HDD would normally be in ACE and later
<andlabs>
the RF shield on the CPU half is just one big slab of sheet metal
<andlabs>
not that cool perforated thing you see on later models
<andlabs>
and no the motherboard does not slide out
<andlabs>
can't wait to put all this back together 🙃
<protosphere>
i'm curious how much memory yours has too
<protosphere>
mine was set to 2mb in the config and passed a 2mb memory test, but i get weird crashes with certain things
<andlabs>
hmm
<andlabs>
good question
<protosphere>
wikipedia says they have 1mb as stock which is useless for most things
<andlabs>
if the memoryt est isn't reliable like that
<fseidel>
if said certain things include "Final Fight" and other Capcom games, those use TVRAM to store code and data
<andlabs>
then who'll really know unless there's a better diagnostic somewhere
<fseidel>
so you might want to test that
<protosphere>
it was uhhh that FM music player thing
<KitsuWhooa>
<protosphere> mine was set to 2mb in the config and passed a 2mb memory test <-- sounds like something that would happen if it wraps around and all the test does is check for sequential patterns :p
<protosphere>
i can't play most of the songs without it crashing
<protosphere>
but 2mb games work fine
<andlabs>
what I have:
<protosphere>
KitsuWhooa:yeah, I was thinking of that
<andlabs>
- cameltry (this is the only one I physically have right now)
<andlabs>
- thunder force 2
<andlabs>
- twinbee (arguably the most common game on the system, if yja is anything to go by lol this was included with thunder force 2)
<andlabs>
- granada
<andlabs>
- the pack-in disks
<protosphere>
MMDSP is the thing that crashes all the time for me
<protosphere>
i suppose i should just set it to 4mb and see if that passes, because i know it definitely doesn't have that much
<andlabs>
and yes I bought cameltry just for the ridiculous peripheral it comes with
<TD-Linux>
SWITCH.X does have an option for eject on power off, but it's implemented in software at least for the XVI IPL
kode54 has quit [Quit: Ping timeout (120 seconds)]
kode54 has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<andlabs>
ah yes TD-Linux I'm still interested in buying the midiori direct from you =P
<fseidel>
TD-Linux: the switch on the back of the CZ-600C seems like it's probably entirely separate from that SW solution
<TD-Linux>
andlabs, cool send me a pm or email
<TD-Linux>
fseidel, yeah I think the SW solution was come up with to replace it
<fseidel>
my guess is it's really only for emergency eject and might just tie both eject motor power lines to 5VSB as long as it's held
<TD-Linux>
yeah I guess the x68k is a rare example of a drive without any emergency eject provision
<andlabs>
oooh
<andlabs>
that makes the plot thicken then
<andlabs>
if I wire things together will it still work
<fseidel>
might be a way to check this, let me see if the drives are included in the schematic
<andlabs>
if you can read the schematic that is
<andlabs>
it's hilariously dense
<fseidel>
doesn't look like it's on there, at any rate
<fseidel>
nothing power/FDD related, excepting the drive controller
<TD-Linux>
btw I went nuts recently and imported a x68k monitor from japan
<fseidel>
how's that working with the shipping issues from Japan?
<TD-Linux>
fedex still ships to the US. given that it would be my preferred shipping method for a bulky item anyway it turned out fine
<andlabs>
oh the X68000 I bought came with its monitor
<andlabs>
the monitor worked fine
<andlabs>
shipped via DHL so it seems to be intact though I haven't unwrapped it *completely* yet
<andlabs>
the X68000 also worked fine... until the PSU kicked it while the seller was testing lol
<fseidel>
it'll be an OSSC+LCD for a long time, no space for CRTs in my tiny apartment :-(
<andlabs>
oh yeah that's another thing I'll need to set up at some point
<fseidel>
yep, that's definitely an X68K PSU alright
<TD-Linux>
I have a tiny apt too, just a broken sense of priorities
<andlabs>
if I could OSSC a commodore 128 that would also be neat
<andlabs>
*in 80-column mode with color
<andlabs>
since I'm this close to just buying a commodore 1902a or equivalent
<fseidel>
my GF's are slightly less broken than mine, and it's probably for the better I don't have _another_ monitor on the desk...
<andlabs>
(I have the weird custom cable for it)
<TD-Linux>
if you can get analog rgb from it there is no reason it shouldn't work
<protosphere>
I think c128 is a cga-like?
<andlabs>
yes
<protosphere>
ie ttl rgb
<protosphere>
should work so long as you have a cga2rgb type thing
<andlabs>
anyway I overspent so much this past year that I starte dusing our basement as storage space
<andlabs>
so
<andlabs>
:D
<andlabs>
but I wasn't going to pass up $750 for an X68000
<protosphere>
fseidal: How does yours work with the OSSC? On mine the text is blurry and barely readable
<protosphere>
As if the sample rate is way off or something
<fseidel>
looks fantastic, needs a few timing tweaks
<andlabs>
not when next least expensive is $3000
<TD-Linux>
one obnoxious thing about ossc + x68k is that if you want pixel perfect sampling, you have to make several presets
<TD-Linux>
as there are a variety of modes used by different games, plus some set the registers directly
<protosphere>
i tried tweaking the timing for 512x512 but couldn’t get it to look even remotely good
<protosphere>
I feel like it’s probably just coincidence?
<TD-Linux>
no idea what would kill it on a LCD vs a CRT
<protosphere>
i don’t really get what would be so different about modern lcds so long as they conform to the vga spec properly
<protosphere>
The x68000 doesn’t seem much different to anything else in that respect
<TD-Linux>
probably. you could always run it through a vga distribution amplifier/splitter if you were concerned
<protosphere>
People have had similar issues with the gbs scalers as well
<TD-Linux>
only thing I've noticed is that the x68k outputs are open collector with weak pull ups, too weak to drive low impedance sync inputs
<TD-Linux>
I suppose you could potentially kill it eventually if running it into a 75 ohm sync load
<fseidel>
FWIW, the XPC-4 does a pretty good job scaling X68K video too, although it's pricey, mode switching is slow, and a few games have weird jittering
<fseidel>
Y2 shifts up and down every few seconds, no idea why
<protosphere>
my machine has other weird issues too, the video is pretty noisy and it changes brightness when the floppy driver motors spin
<protosphere>
my vga monitor won’t properly sync so it is a bit wavy horizontally
<andlabs>
the specific CRT they used in arcade games =P
<sorear>
yeah I misinterpreted "tube"
<andlabs>
see the thing TD-Linux linked
_whitelogger has joined ##yamahasynths
<ValleyBell>
cr1901_modern: My suggestion would be: start 100743, loop 458448, end 1892309
<ValleyBell>
That's what I would usually do in order to re-sync the tracks when looping back.
<ValleyBell>
I have an alternative as well though: 100743, 101361, 1534611
<ValleyBell>
(I took the sample of the "frame begin" at spots 00:02.28 (start/loop) and 00:34.78 (end) and added one frame of 612 samples to ensure a perfectly timed loop. But I consider this overkill, actually.)
andlabs|2 has joined ##yamahasynths
andlabs has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 260 seconds]
emily has joined ##yamahasynths
futarisIRCcloud has joined ##yamahasynths
<cr1901_modern>
ValleyBell: Could I see the numbers that vgmlpfind returns? In either of the cases (start 100743, loop 458448, end 1892309 and 100743, 101361, 1534611) I don't understand how you got those numbers: http://ix.io/2JBk
emeb has joined ##yamahasynths
<ValleyBell>
cr1901_modern: I determined the loop points manually.
<ValleyBell>
using Audacity
<ValleyBell>
and then I used vgm2txt to make sure I align the sample values to the spots where the commands happen
<cr1901_modern>
What do you mean by using vgm2txt to align the samples? Since vgm writes happen instantaneously, shouldn't the loop point and the sample you trim at match up?
<cr1901_modern>
ValleyBell: Additionally, the manual looping tutorial only mentions vgm2txt once.
<cr1901_modern>
Regardless of the settings I send to vgmtrim, the resultant VGM will repeat a few times before getting to the actual VGM loop?
<ValleyBell>
I used vgm2txt to generate a txt file that lists all the VGM commands.
<ValleyBell>
let's take the first loop I suggested as an example.
<ValleyBell>
1. dump the VGM to WAV and open it with Audacity
<cr1901_modern>
I have to install audacity, but I'll dump to txt rn
<ValleyBell>
main_009.wav
<ValleyBell>
in for this case
<ValleyBell>
Any other WAV editor works as well.
<ValleyBell>
Especially in this case, you see repeating patterns.
<cr1901_modern>
not found... upload to imgur or something?
<ValleyBell>
uhhh...... why does it not work
<cr1901_modern>
(thank you for your help, btw)
<cr1901_modern>
file permissions
<cr1901_modern>
?*
<ValleyBell>
...this is definitely some sort of permission issue
<ValleyBell>
oh...wait
<ValleyBell>
OHHH
<ValleyBell>
vampi moved the site to a new server
<ValleyBell>
I'm probably accessing the *old* site.
<cr1901_modern>
huh
<ValleyBell>
imgur doesn't work either: "Something went wrong with CREATE_ALBUM_FAIL. Please try later"
<cr1901_modern>
Murphy's Law
<cr1901_modern>
anyways, I created a wav and a txt file. I don't expect to get the _exact_ same results as you depending on whether fast-math/floating point was being used, but your example will be illustrative
<ValleyBell>
I highlighted an area that looks like it's repeating.
<ValleyBell>
It begins at 10.356 seconds and ends at 42.889 seconds.
<cr1901_modern>
I've installed audacity as well
<ValleyBell>
I now open the txt and search for "10.4" (or "00:10.4", if I want to be sure)
<ValleyBell>
There I see: 0x00000786: 61 81 15 Wait:5505 samples ( 124.83 ms)(total458448 (00:10.40))
<cr1901_modern>
yup I see it too
<ValleyBell>
It is a larger "wait" command (> 500 samples) so it's likely the beginning of a "frame".
<ValleyBell>
which is what I use to synchronize loop start and end
<ValleyBell>
It's just a habit of me that I want to trim at the beginning of a "processing frame" instead of somewhere in the middle.
<ValleyBell>
(It's me being a perfectionist.)
<cr1901_modern>
right fair
<ValleyBell>
Anyway, 1458448 is the "loop start sample".
<ValleyBell>
erm, 458448
<ValleyBell>
I do the same thing for the "end" sample: search for 42.9, find: 0x000024B0: 61 78 21 Wait: 8568 samples ( 194.29 ms) (total 1892309 (00:42.91))
<ValleyBell>
For me, this is a quick and easy way to turn the approximate loop points I find in Audacity into exact VGM sample values.
<ValleyBell>
This is probably a bit different from what most tutorials tell you to do.
<cr1901_modern>
Okay, and I see now based on the numbers you gave me that the track plays less than 2 full loops before the end of the loop point
<cr1901_modern>
a single "initial" section, then it enters the loop, plays the rest of the track, begins the "initial section" again, and loops back to the loop point
<ValleyBell>
yes, because the VGM loop begins 10 seconds later than the actual song's loop.
<ValleyBell>
The song's loop is about 32.5 seconds long.
<cr1901_modern>
The way I interpreted vgmlpfind was that based on the optimal loop location, a VGM file could play multiple actual loops of the song before entering the VGM loop
<ValleyBell>
But in order to make the re-synchronizing less noticeable I moved it a bit.
<ValleyBell>
What you usually want is, that the VGM loop matches the actual song's loop.
<cr1901_modern>
a bit == 10 seconds :P?
<ValleyBell>
if the song loops twice during a single VGM loop according to vgmlpfnd, something is throwing it off
<ValleyBell>
like software volume envelopes or vibrato
<ValleyBell>
In most cases, the VGM loop will start beween 1 frame and 1 second after the actual song's loop
<ValleyBell>
Oh, right, vgmlpfnd completely ignores any timing.
<cr1901_modern>
(What about these numbers == "I don't think vgmlpfnd thinks the song loops twice in a single VGM loop")
<cr1901_modern>
Rather, it just thinks there are multiple possible starting positions for a looop
<ValleyBell>
So if your song plays 1/8th notes only and your echo is 1/32 later during loop 1 and 1/16 later during loop 2, it will be considered "the same".
<ValleyBell>
So in this case, those blocks are exact copies.
<cr1901_modern>
Well, it's not wrong
<cr1901_modern>
for some value of "wrong"
<ValleyBell>
If you discard any timing information and consider only the order of the commands, the part at 02:10..02:42 indeed repeats at 02:42.
<cr1901_modern>
Notably, vgmlpfind did NOT find a loop starting at 02:42
<ValleyBell>
vgmlpfnd is very far from perfect and takes a lot of shortcuts in order to be able to just work as it is.
<ValleyBell>
yes, because the block that plays at 03:15 has the commands in a different order than at 02:42
<ValleyBell>
Imagine that the main melody plays at t=0, t=10, t=20, t=30, ...
<ValleyBell>
at 02:10 the echo plays at t=17, t=27, t=37, ...
<ValleyBell>
at 02:42 the echo plays at t=12, t=22, t=32, ...
<ValleyBell>
at 03:15 the echo plays at t=7, t=17, t=27, ...
<ValleyBell>
When sorting the notes of "main melody" and "echo" by time, you get the same order for 02:10 and 02:42
<cr1901_modern>
ahhh
<ValleyBell>
i.e. m0 [t=0], m1 [t=10], e0 [t=12 or 17], m2 [t=20], e1 [t=22 or 27], ...
<cr1901_modern>
then in this example 2:10 would and 2:42 would both be seen as "the same" set of commands
<cr1901_modern>
thus a loop
<cr1901_modern>
?*
<ValleyBell>
yes
<cr1901_modern>
(thus a loop at 2:10, 2:42, but not 3:15)
<ValleyBell>
The table explicitly says "source block" and "block copy"
<ValleyBell>
and the letter is just there to help you decide what to do with the line
<ValleyBell>
f = full copy
<ValleyBell>
thus, effectively a loop
<cr1901_modern>
Ooooooh
<ValleyBell>
This totally fails for songs that plays patterns like "A A B A C A A B A C"
<ValleyBell>
because you may end up looping just "A" if you are not careful
<cr1901_modern>
Uhhh, "f" means "the block copy immediately follows the source block"?
<ValleyBell>
yes
<cr1901_modern>
and "!" is used if only one "f" exists?
<ValleyBell>
"!" is used is there is an "f" that goes until EOF
<ValleyBell>
"e" = there is a copy, but it's incomplete due to EOF terminating it early
<cr1901_modern>
I've seen "!" before during this project, but I'm not sure how I ever got "!" because I have to manually stop these loops
<cr1901_modern>
sorry, I have to manually stop the tunes from playing by exiting DOSBox
<cr1901_modern>
and I think it is exceedingly unlikely that I stop DOSBox at the exact point a block copy matches a source block
<ValleyBell>
You get "!" when you stop the log *before* you stop the actual song.
<ValleyBell>
also ... "by exiting DOSBox"?
<cr1901_modern>
CTRL+9
<cr1901_modern>
err CTRL+F9
<ValleyBell>
okay, that's fine
<ValleyBell>
The "block copy" may overlap with the source block.
<ValleyBell>
so it doesn't matter when you stop logging, as long as you let it play twice before stopping the log.
<ValleyBell>
Basically: A B C D A B C --> you get "e", as there is a copy of "A B C"
<ValleyBell>
A B A B D -> you get "f" (for A B)
<ValleyBell>
The "D" happens when you stop the player first then then the log. (The player will send key offs to all channels, which is the "D".)
<ValleyBell>
A B C A B C A B -> you get "!" due to A B C repeating at least once in full + it repeats until EOF
<cr1901_modern>
Okay, that's helpful
<cr1901_modern>
Last 2 qs (I hope): >The "block copy" may overlap with the source block. <-- what do you mean by this? It sounds reasonable, but that sounds like in some cases you can get away w/ less than two full loops
<ValleyBell>
no
<ValleyBell>
I meant the opposite.
<ValleyBell>
A B C A B C A B -> means the "source block" is "A B C A B" (starting at position 0)
<ValleyBell>
and the "block copy" starts with the second A
<ValleyBell>
which means that there is an overlap of "A B" in the middle
<ValleyBell>
This, in turn, means that it can accept that you loop it 2.5 times (instead of exactly 2 times) and will be fine with thta.
<ValleyBell>
*that
<cr1901_modern>
Ahhh... what a wonderful visualization
<cr1901_modern>
:D
<cr1901_modern>
And my other q... >In most cases, the VGM loop will start beween 1 frame and 1 second after the actual song's loop
<cr1901_modern>
What is a "frame" in this context?
<cr1901_modern>
The smallest unit of time the actual sound driver perceives?
<ValleyBell>
I think of "frame" as one unit of the sound driver processing stuff.
<cr1901_modern>
basically everything up until a manual wait command?
<ValleyBell>
yes
<cr1901_modern>
(Ignoring the fact that a real sound driver will have to wait for the chip to process the previous write)
<cr1901_modern>
(Those waits don't count)
<ValleyBell>
In many cases, the VGM loops start 1 frame later than the song's loop, because you don't have to include the "load instruments" commands again.
<ValleyBell>
or rather, the sound engine doesn't include them the second time
<cr1901_modern>
But the VGM doesn't need to include them a second time either?
<ValleyBell>
yes
<cr1901_modern>
So that sounds like the VGM loop starts at the same frame the song does
* cr1901_modern
thinks he;s misunderstanding
<ValleyBell>
and it's preferred to not include them the second time in order to make loops slightly more fluid
<ValleyBell>
and it matches the sound driver behaviour more accurately anyway
<ValleyBell>
>cr1901_modern: So that sounds like the VGM loop starts at the same frame the song does
<ValleyBell>
yes
<ValleyBell>
From experience, loading instruments takes looooong. Especially on 4op chips.
<ValleyBell>
I think I've seen games spending about 10 ms just for that.
<ValleyBell>
(at 60 Hz / 16ms per frame)
<cr1901_modern>
I don't think I understand how you could get into a position where the VGM loop starts one frame _later_. Either the sound driver doesn't load the instruments twice, in which the VGM loop starts at the same frame as the song loop
<cr1901_modern>
or the sound driver loads the instruments twice, but the VGM loop doesn't, so the VGM loop begins one frame _earlier_ than the song loop
<ValleyBell>
If the sound driver reloads the instruments, then you just loop from [song start, song end)
<ValleyBell>
If it doesn't, then you loop [song start + 1 frame, loop end + 1 frame)
<ValleyBell>
umm...how do I explain that better ....
<cr1901_modern>
yes, sorry I don't see it >>
<cr1901_modern>
(But fwiw, this has been extremely helpful overall)
<ValleyBell>
You have a song with sequence data: (load instrument) (set volume) [ (note 1) (note 2) (note 3) ]
<ValleyBell>
There is time passing between the notes, but not before the first note.
<cr1901_modern>
presumably (load instrument) (set volume) happen in the same frame
<cr1901_modern>
right
<cr1901_modern>
oh... (load instrument) (set volume) [ (note 1) are _all_ in the same frame
<ValleyBell>
If you now add high-precision timestamps: t=0 ins, t=1 vol, t=2 n1, t=10 n2, t=20 n3, t=30 n1, t=40 n2, ...
* cr1901_modern
shuts up
<ValleyBell>
You can now either loop [t=0 ...t=30), then you would include the instrument loading twice.
<ValleyBell>
Or you loop [t=2 ... t=30), which matches the sequence's loop, but the loop time is shorter (28 "ticks" instead of 30 due to instrument loading)
<ValleyBell>
Or you loop [t=10 ... t=40]
<ValleyBell>
which gets you the exact 30 ticks your loop is supposed to have, but the VGM's loop begins at the second note (n2 at t=10) instead of the first one.
<cr1901_modern>
And the loop time being shorter would only manifest itself over time
<cr1901_modern>
err, become apparent*
<cr1901_modern>
Or is it more "having the sound driver and VGM's precise timing is more morally correct but unlikely to be heard"?
<cr1901_modern>
but differences are unlikely*
<cr1901_modern>
ANyways, I see what you're getting at now. And good thing this channel is logged :D. Because it means I can reference it and maybe make a wiki page out of it later (credit given :P)
<ValleyBell>
Yes, the loop time being slightly short will become apparent over time.
<ValleyBell>
In the worst case, it might even sound a bit jittery.
<ValleyBell>
I'm really going into the details here though.
<cr1901_modern>
To sum up: Starting the loop one frame later avoids a subtle off-by-one error in the VGM's perception of loop timing.
<ValleyBell>
Most people would probably just take the vgmlpfnd loops and use that.
<ValleyBell>
Yes
<ValleyBell>
vgmlpfnd actually encourages the use of [t=2..t=30) loops though.
<cr1901_modern>
That was my follow up q
<ValleyBell>
I unfortunately never ended up making it round time up to the next frame.
<cr1901_modern>
I imagine it would be difficult to code it to encourage a [t=10...t=40] loop
<ValleyBell>
As soon as an echo channel comes into function, you'll go this route anyway.
<cr1901_modern>
Btw, just to be clear ")" means "include the delay up to t=whatever, but not the commands at t=whatever)", correct?
<ValleyBell>
yes
<ValleyBell>
This is how vgm_trim behaves as well, btw.
<cr1901_modern>
See, all of this is good info. I admit I have a bit of an "accelerated" tutorial b/c I get to ask you q's, but this seems like all good "advanced" stuff for the wiki
<ValleyBell>
If you set end = 30, it will include all events from 0..29 and the delay until t=30, but not the events happening at t=30.
<cr1901_modern>
ahhh
<ValleyBell>
... *unless* you have a non-looping song
<ValleyBell>
then it includes those the events at t=30
<ValleyBell>
because else you would constantly trim off the final KeyOff event
<ValleyBell>
causing hanging notes in VGMPlay
<cr1901_modern>
I mean, plenty of period-correct software does that too :P
<cr1901_modern>
Dark Tower for Sega Genesis
<cr1901_modern>
Dark Castle*
<cr1901_modern>
The way I had interpreted vgmlpfind _before this convo_ was that you were supposed to put the loop with "f" or "!" as parameters into vgm_trim, even if previous loops w/o the "f" had been found.
<cr1901_modern>
this would lead to vgms that play the song for multiple loops before going into the vgm loop
<cr1901_modern>
But also, I think if I were to capture that VGM for an hour, eventually the song would go so out of sync it would resynce
<cr1901_modern>
that could also be a single VGM loop that encompasses lots of song loops :D
<ValleyBell>
We have a few VGM packs that do this, actually.
<ValleyBell>
Especially the Puyo Puyo games have tunes that transpose up infinitely.
<ValleyBell>
and after a few hours they arrive back at their initial pitch.
<cr1901_modern>
Sword of Vermilion is my favorite example
<cr1901_modern>
it takes 40 minutes for a full loop
<cr1901_modern>
and the song doesn't come out unscathed
<ValleyBell>
The "full loop" versions are usually included as bonus tracks and omitted in the playlist.
<ValleyBell>
and a shorter version (either cut or looped in a way that's nice to listen) is often included in the pack.
<ValleyBell>
which is then part of the playlist
<cr1901_modern>
Maybe I'll include the going out of sync version as a bonus track
<cr1901_modern>
Uhhh, for a loop whose source/copy distance is within a specific threshold, would vgmlpfind be able to tell me the offset of the cmds which are _not_ part of the loop
<cr1901_modern>
so I can analyze what's causing the source/copy to not be adjacent?
<ValleyBell>
Well... you get the time offset of the source block.
<ValleyBell>
but that only helps you to analyse why the loop begins there and not earlier.
<cr1901_modern>
hold that thought... meatspace thing right now
<cr1901_modern>
whoops :P
<ValleyBell>
I'm afraid it doesn't tell you the time offset for the end directly.