Page 1 of 1

Using the CPU clock for musical timing.

Posted: Mon Oct 13, 2014 5:03 am
by Count SymphoniC
Hey guys, the synth editor is done and works great! Now I had a talk with Delek the author of Deflemask about timing the playback engine, in frames or ticks. He told me that I could either use the Vertical Blank (sounds very easy to me) for each musical frame. Or I could use the CPU clock. Now since I'm planning to implement PCM sample playback in the tracker in the future, he also stated that using the Vertical Blank to time the music will not work.

So on a general level, how should I go about using the CPU clock to time musical playback? This is something I'm still not really certain about, but I really want to learn this. We're aiming for cross compatibility between YMDj and Deflemask so this is going to be a critical part to get right.

Posted: Mon Oct 13, 2014 8:09 am
by r57shell
Is it normal to make new topics for each new question you came up? :?
We already touch this topic in thread when we talk about region detection.

Also, there is already topic by YOU about same question. And there is all answers. Even with details. And advanced techniques. Did you read that answers?

Also you already have details about YM2612 timers here. And you can find this thread if you make search by keyword "timer".
I know that you bring some activity to this forum, but still, you being too lazy.

From another topic:
Count SymphoniC wrote:I google and search forums more than you might think.
No, you don't :lol:

Summary: there is four sources of time:
1) VBLANK
2) HBLANK
3) HV counter
4) YM2612
Nothing more. Also, Delek making traker based on emulation, and he has some mistakes in view. I don't know is he indeed said that you may access to internal CPU timer (M68k I mean, or Z80) but, anyway, you don't have access to it. Also, he using wrong formulae to change volume of YM2612 patch, and he claims that you can't achieve BPM based music timing on Sega Genesis/MegaDrive. Example of BPM on Sega Genesis/MegaDrive you can find in GEMS sound driver. Also you can check this demo where you can change BPM interactively.

Posted: Mon Oct 13, 2014 3:40 pm
by Count SymphoniC
I only ask questions when I'm very confused about something.

Once again I'm thankful that someone was able to clarify something for me. I was very confused by what Delek meant by using the CPU timer. I thought he was talking about the 68k clock so I was looking for the wrong information that didn't exist, that's my fault for not understanding that. I'm an absent minded scatter brain. Now you know what my fiancee' has to deal with every day, me forgetting so many things all the time. I can't help this, eventually I will forget something important it happens all the time and it frustrates me, while everyone else enjoys the privilege of having a sharp memory. Now with enough drilling it into my head and repetition, I can remember something. Now I'm more likely to remember all of these topics.

Posted: Mon Oct 13, 2014 4:27 pm
by Jazzmarazz
Would it be useful if the cartridge included an RTC which could be read through the cart edge? I could map it at 0x300000. It could be read, reset and written to ... but would increase costs. It would not drain the battery like pokemon though, because it would not be needed to connect to the battery; just vcc.

It would make testing in emulators impossible and we would actually need the cart to do any testing at all, but it makes sense to me.

EDIT: Honestly this thread is different from the other timers thread because this focuses on CPU as the source for time, not just to explore all of the options.

Posted: Mon Oct 13, 2014 4:55 pm
by Count SymphoniC
EDIT: I should probably clarify something. If I was to code my playback engine using the VBLANK as the core for timing. I would just read (using only FM channel 1 as an example): For each ROW - note, instrument number, velocity, parameters for that instrument, tracker command for that row and that takes place and is updated all in one frame... of course to slow it down I would update it every two frames or three, or for unusual timings every even row could be updated every frame with odd rows updated once every 3 frames. Using VBLANK as the core timer is really easy for me to understand.

EDIT:
I reread the message Delek sent me about this, and I'm formally confused. Does he mean that I can still use the vertical blank? As long as the PCM handling is done outside of that timing mechanism? Wtf.

Delek:
You could fix your update rate to the vertical blank or, instead, use the actual clock rate of the CPU.

If you will support PCM playback, fixing the entire engine around the vertical blank will make that task impossible: you have to be more fast than that to play realtime PCM stuff.

In pseudo-pseudo-pseudo code, the main core should be something like this:

while(true){
checkIfPlayPCMSample();
if( verticalBlank() ) updateNormalPlayback(); //60hz normally
}
If I can just understand this, so I can get to work on my playback engine, I will leave this forum alone for quite a while. Promise.

EDIT: http://modarchive.org/forums/index.php?topic=2709.0 this will help people understand the timing system used in a lot of trackers. It's helping me a bit. But I still need clarity on some of the above mentioned things.

FINAL EDIT: Ok, all I want to know now is, would using that psuedo code Delek showed me above as a template for the timing core work with PCM playback? That's all I want to know.

Posted: Tue Oct 14, 2014 3:33 am
by r57shell
Count SymphoniC wrote:Does he mean that I can still use the vertical blank? As long as the PCM handling is done outside of that timing mechanism? Wtf.
It seems like he does, but not clearly.
Delek wrote: If you will support PCM playback, fixing the entire engine around the vertical blank will make that task impossible: you have to be more fast than that to play realtime PCM stuff.
In other words: VBLANK for PCM is not enough, you need something better. Yes it's true :)

Code: Select all

while(true){
    checkIfPlayPCMSample();
    if( verticalBlank() ) updateNormalPlayback();    //60hz normally
}
Looks correct.
Delek wrote:You could fix your update rate to the vertical blank or, instead, use the actual clock rate of the CPU.
May be he talk about technique used in SGDK PCM-only sound drivers, where timing based on actual code execution time. It means that for all instructions of CPU was calculated time of execution, and periods, and its timing was manipulated to have fixed behavior. If you "programming prodigy" you may use it, but for me it's overkill.
Count SymphoniC wrote:FINAL EDIT: Ok, all I want to know now is, would using that psuedo code Delek showed me above as a template for the timing core work with PCM playback? That's all I want to know.
You may use it. Use it with care :D

Posted: Tue Oct 14, 2014 6:54 am
by Count SymphoniC
Thanks.

Well I got started on the playback engine and timing. It's basic, but currently playback will update FM channel 1 every 6 frames and works in harmony with the rest of the tracker without causing any major issues. So I go into my Note Entry+Synth Editor screens and can edit the FM parameters and then go into the Note entry screen and do some arpeggio and scale run tests, press start and listen to my fruits play before my ears. I'm very happy even though it's just basic stuff for now.

Before that I had yet another mysterious crash I'm sure everyone on this board will be glad to know that I solved without posting any threads. However I have a new problem related to timing with the rest of the program but I'll find a way to handle it. I wouldn't expect anymore questions from me until I get to work on the DAC itself, but that's a ways down the road. Other than that I think I understand enough now to be more independent with this project. Thanks everyone for putting up with my incessant questioning. I'll post occasional updates in the demo thread.

Posted: Mon Oct 20, 2014 8:28 am
by Oerg866
The most effective approach would indeed be the YM2612 timers. And the PCM playback should be on Z80 side... It's really not something you want to waste 68k cycles with.

Posted: Mon Oct 20, 2014 3:04 pm
by Charles MacDonald
I wonder if it would be better to have a sub-forum dedicated to music/YM2612 related issues?

Posted: Mon Oct 20, 2014 6:03 pm
by neologix
Charles MacDonald wrote:I wonder if it would be better to have a sub-forum dedicated to music/YM2612 related issues?
Seconded!

Posted: Tue Oct 21, 2014 4:36 am
by TmEE co.(TM)
That's actually a really good idea.

Posted: Tue Oct 21, 2014 12:22 pm
by MintyTheCat
Charles MacDonald wrote:I wonder if it would be better to have a sub-forum dedicated to music/YM2612 related issues?
I agree - it is a complete topic in itself. It that ok to add one, kaneda?