libv2 v1.5 IsPlaying bug
category: general [glöplog]
I was wondering if anyone has run into this problem before. Basically after a song is finished playing the variable m_state.state never gets set to OFF/STOPPED. Maybe this is intentional? Regardless, IsPlayer cannot be used to have a v2m file loop continuously. Perhaps this is an issue with a v2m v1.0 file being converted to work with v1.5?
The solution I came up with was to make a function GetTime inside v2mplayer that would return the time variable in player struct and then compare that to how long track goes for. Does anyone know how the time value is calculated? It's not ms because a 3:30 min track is ~71800.
The solution I came up with was to make a function GetTime inside v2mplayer that would return the time variable in player struct and then compare that to how long track goes for. Does anyone know how the time value is calculated? It's not ms because a 3:30 min track is ~71800.
There is a bug? Oops. Seems nobody else has tried that before... :)
No much time at the moment, but the internal player time is measured in the same units as in MIDI files, so look it up there somewhere (can't remember what it exactly was ;). Then agai I'd forget that plan anyway, because the player time doesn't take the sound card's (/directsound's) latency into account. If you look at the libv2.h file, you'll find a function called dsGetCurSmp() which will give you the sample-exact real-time playing position. Sampling rate is 44100 I think :)
No much time at the moment, but the internal player time is measured in the same units as in MIDI files, so look it up there somewhere (can't remember what it exactly was ;). Then agai I'd forget that plan anyway, because the player time doesn't take the sound card's (/directsound's) latency into account. If you look at the libv2.h file, you'll find a function called dsGetCurSmp() which will give you the sample-exact real-time playing position. Sampling rate is 44100 I think :)
Thanks for the info about time, I'll look into that.
As for the bug, I just tested with the v1.5 v2m file included in original package and it gets its state flag set properly. So this is definately an issue with v1.0 v2m files converted to v1.5.
As for the converted one that doesn't work, you can download it here. I also included the one converted with "conv2m.exe" so it would work with v1.5.
http://www.zshare.net/download/510751581c359e10/
As for the bug, I just tested with the v1.5 v2m file included in original package and it gets its state flag set properly. So this is definately an issue with v1.0 v2m files converted to v1.5.
As for the converted one that doesn't work, you can download it here. I also included the one converted with "conv2m.exe" so it would work with v1.5.
http://www.zshare.net/download/510751581c359e10/
current time in seconds: player.m_state.time*player.m_state.usecs/player.m_base.timediv/44100/10000
total time in seconds:
player.m_base.maxtime*player.m_state.usecs/player.m_base.timediv/44100/10000
total time in seconds:
player.m_base.maxtime*player.m_state.usecs/player.m_base.timediv/44100/10000
The above formula is only correct if the time base won't change during the song; if you made the V2M by pressing the "record" button instead of the other (non-public :) method you're safe tho.
.. and remember that the maxtime specifies when the last MIDI event is sent to the synth. It doesn't take into account for how long the sounds and eg. the reverb need to fade out after then. Add additional seconds at your own discretion.
.. and remember that the maxtime specifies when the last MIDI event is sent to the synth. It doesn't take into account for how long the sounds and eg. the reverb need to fade out after then. Add additional seconds at your own discretion.
side note: dsGetCurSmp() didn't work for me either. I tried to use it, but I noticed that it seems to have a contant offset applied to it. This wouldn't be a problem, but the offset is different for each system ... on one box, it was close to zero, on another, is was something like 400 ms.
The tens of intros released with libv2 1.0 that uses dsCurSmp for timing speak differently, you know...
Of course, if you initialize the dsio layer without having started a song first, the player will render a few zeroes which won't be accounted for.
Of course, if you initialize the dsio layer without having started a song first, the player will render a few zeroes which won't be accounted for.
OK, that might be the problem. I'll check that again, thanks :)