0 0

2 Pages V   1 2 >  
Reply to this topicStart new topic
> Gmc Metronome - Flash Coding Help Needed!
Kristofer Dahl
post Jul 2 2007, 10:06 AM
Post #1


GMC Founder & Rocker
Group Icon

Group: GMC Instructor
Posts: 12.977
Joined: 15-August 05
From: Stockholm, Sweden
Member No.: 2



Hey there,

We have a very helpful user named Marraboy, who is a flash programer (check his site here) and who has decided to donate a flash metronome to GMC. He has insisted to do it for free so be sure to help him out in the forum as much as you can! smile.gif

Either way - there seems to be a slight bug, we have agreed to ask openly about it. So if anyone has a suggestion how to solve this, please let us know here.

Check out the metronome in Wallimann's most recent lesson (found here).

You might notice that the metronome clicks unevenly at higher speeds - which is what we would like to fix. This is only a problem when the flash video player is open simultaneously.

Kris


--------------------
It's all about the journey, not the destination.

Check out my video lessons + my collabs KMC Metal & Shadow Of The Ninja. And my latest progress report!
Go to the top of the page
 
+Quote Post
MickeM
post Jul 2 2007, 10:33 AM
Post #2


Born of NWOBHM, Moderation Team Leader
*

Group: Members
Posts: 8.562
Joined: 9-January 07
From: Stockholm, Sweden
Member No.: 1.062



There must be Flash forums where people can help. I don't know if these are any good, just googled a couple.

Flashsupport
Flashguru


And the metronome see uneven at any speed and it's not up to tempo, it falls behind my Guitarport metronome in speed. Or it's my metronome that is not perfect.

Thanks Marraboy for helping smile.gif

EDIT:
And the "falling behing in speed" happens also when flashplayer is closed. I'm curious to know if it's this or my metronome that's got the wrong tempo.

This post has been edited by MickeM: Jul 2 2007, 10:37 AM


--------------------
Go to the top of the page
 
+Quote Post
Resurrection
post Jul 2 2007, 10:49 AM
Post #3


GMC:er
*

Group: Members
Posts: 202
Joined: 22-May 07
Member No.: 1.906



QUOTE (Kristofer Dahl @ Jul 2 2007, 10:06 AM) *
Hey there,

We have a very helpful user named Marraboy, who is a flash programer (check his site here) and who has decided to donate a flash metronome to GMC. He has insisted to do it for free so be sure to help him out in the forum as much as you can! smile.gif

Either way - there seems to be a slight bug, we have agreed to ask openly about it. So if anyone has a suggestion how to solve this, please let us know here.

Check out the metronome in Wallimann's most recent lesson (found here).

You might notice that the metronome clicks unevenly at higher speeds - which is what we would like to fix. This is only a problem when the flash video player is open simultaneously.

Kris



I don't have experience of flash programming, but I do have quite a lot of experience in developing software generally. My question would be how is the timing of the metronome ticks generated? Is it from a hardware timer? When the time expires and a new tick is needed, how is this event serviced? The problem sounds like the flash player sometimes has to do a higher-priority thing rather than play the tick when requested, resulting in uneven ticking at higher speeds. The fact that the problem is worse when the flash video player is active would also indicate this. Can the metronome 'tick' routine be put on a higher priority? The only other explanation I can come up with is that the timer is very inaccurate in counting out the required delay.

Not much of a solution I'm afraid, but maybe it will give Marraboy a few ideas about how to tackle the problem.


--------------------
QUOTE
If you think you can, you can. And if you think you can't, you're right.
Go to the top of the page
 
+Quote Post
Andrew Cockburn
post Jul 2 2007, 02:00 PM
Post #4


Moderation Policy Director
Group Icon

Group: GMC Instructor
Posts: 10.452
Joined: 6-February 07
From: CT, USA
Member No.: 1.167



I would echo what Ressurection says,

but wanted to add, thanks Marraboy for helping to make GMC even better !


--------------------
Check out my Instructor profile
Live long and prosper ...

My Stuff:

Electric Guitars : Ibanez Jem7v, Line6 Variax 700, Fender Plus Strat with 57/62 Pickups, Line6 Variax 705 Bass
Acoustic Guitars : Taylor 816ce, Martin D-15, Line6 Variax Acoustic 300 Nylon
Effects : Line6 Pod HD Pro, Keeley Modded Boss DS1, Keeley Modded Boss BD2, Keeley 4 knob compressor, Ibanez Weeping Demon Wah
Amps : Epiphone Valve Jnr & Head, Cockburn A.C.1, Cockburn A.C.2, Blackstar Club 50 Head & 4x12 Cab
Go to the top of the page
 
+Quote Post
Kaneda
post Jul 2 2007, 02:03 PM
Post #5


Other side of the coin
*

Group: Members
Posts: 266
Joined: 3-May 07
From: CPH, Denmark
Member No.: 1.754



I'll have a go, although I gave up on the Flash timing accuracy issue a loooong time ago wink.gif

Flash's standard timing functions (setInterval, setTimeout, mx.utils.Timer etc.) are nowhere near accurate enough for millisecond timing, no matter what you do. Javascript's similar functions are much more accurate, but still not really good enough for a "professional accuracy" metronome (and then you'd have to do Flash calls from Javascript).

One thing that might help (haven't tested the metronome, and obviously haven't looked at the code, so I have no idea how you actually did it) is to remember, that if you set a Timer (or use setInterval) with an interval of 1000, it's not called every 1000 milliseconds (even if that was the idea of the Timer in the first place). What the interval really is depends on how long it takes to execute the function (event handler) that handles your timer event.

In other words, if you set a Timer with an interval of 1000, and your TimerEvent.TIMER event handler takes 300 ms to execute, the timer will actually be called at an interval of 1300 milliseconds... tongue.gif

I.e.:

We start the timer: 0 ms have elapsed.
The timer "fires" 1: 1000 ms have elapsed.
The timer event handler is called 1: approximately 1000 ms have elapsed.
The timer event handler has done its job 1: 1300 ms have elapsed.
The timer is reset: approximately 1300 ms have elapsed.
The timer "fires" 2: 2300 ms have elapsed. (1300 + the 1000 we wanted)
The timer event handler is called 2: approximately 2300 ms have elapsed.
The timer event handler has done its job 2: 2600 ms have elapsed.
etc.

In other words, the timer reset is not done asynchronously.

Note: This goes for setInterval too.

You can get around it somewhat, by using getTimer() to get the actual time when your handler starts, and when it ends, and adjust the interval until the next time the timer fires by the difference in getTimer().

Note, though, that I emphasized approximately, because even the internal handling (going over the event handlers you have defined) takes time, so it won't be 1000 ms the first time your event handler is called either - probably more like 1020 - 1030, depending on what computer you run it on.

When the videoplayer is playing in the background, Flash is even more "busy", hence the timer is thrown even more off.

It's a recursive, and platform-dependant, nightmare of inaccuracy, it never ends, and it sucks. smile.gif

Note that the frame/timeline animation of Flash is much more accurate, so you might want to look into doing the metronome sound based on the timeline, and use ActionScript 3's methods for adjusting framerate dynamically.

This post has been edited by Kaneda: Jul 2 2007, 02:04 PM
Go to the top of the page
 
+Quote Post
Andrew Cockburn
post Jul 2 2007, 02:46 PM
Post #6


Moderation Policy Director
Group Icon

Group: GMC Instructor
Posts: 10.452
Joined: 6-February 07
From: CT, USA
Member No.: 1.167



As ever, Kaneda gives a complete and well resoned response smile.gif

I'm guessing you can't reset the timer right at the beginning of the handler like you can in some languages.

Maybe this would work better in a Javascript + DHTML format?

Might even try that if I ever get a spare moment ...


--------------------
Check out my Instructor profile
Live long and prosper ...

My Stuff:

Electric Guitars : Ibanez Jem7v, Line6 Variax 700, Fender Plus Strat with 57/62 Pickups, Line6 Variax 705 Bass
Acoustic Guitars : Taylor 816ce, Martin D-15, Line6 Variax Acoustic 300 Nylon
Effects : Line6 Pod HD Pro, Keeley Modded Boss DS1, Keeley Modded Boss BD2, Keeley 4 knob compressor, Ibanez Weeping Demon Wah
Amps : Epiphone Valve Jnr & Head, Cockburn A.C.1, Cockburn A.C.2, Blackstar Club 50 Head & 4x12 Cab
Go to the top of the page
 
+Quote Post
Kaneda
post Jul 2 2007, 03:14 PM
Post #7


Other side of the coin
*

Group: Members
Posts: 266
Joined: 3-May 07
From: CPH, Denmark
Member No.: 1.754



QUOTE (Andrew Cockburn @ Jul 2 2007, 03:46 PM) *
As ever, Kaneda gives a complete and well resoned response smile.gif

I'm guessing you can't reset the timer right at the beginning of the handler like you can in some languages.

Maybe this would work better in a Javascript + DHTML format?

Might even try that if I ever get a spare moment ...


Because JS does setInterval etc. asynchronously, it is much more accurate - the inaccuracy can be adjusted with the various time functions (like Yahoo do for their animation libraries). For some reason, ActionScript just doesn't handle time asynchronously, so it has to wait for the execution of other code.

I've yet to find a way that makes it accurate enough to do real audio work - the mx.utils.Timer object could be reset, but that's just going to do the same as letting it run - it won't start (again) until you're done doing whatever you want to do in response to the timer event - and by then, you can't be absolutely sure what amount of time you should set for the interval to compensate for the time spent in the event handler. It's infinitely stupid handling of time in something that's supposed to be a multimedia/audio/video/animation tool... smile.gif

The first step to see how accurate Flash could be on its own, would be to call getTimer() at the start of the event handler. Call it again at the end, and set the interval until the next event handler call to [the-interval-you-want] minus the time spent in the function (the difference between the two getTimer calls). Of course, if Flash is busy enough, that difference would end up being larger than the wanted interval (say, if Flash spent 600 ms in a function, and there was only 500 seconds until it should be called again. Then you'll end up with -100, which means "skip the next beat" wink.gif

Then, as I suggested, there's the hybrid approach, where JS keeps track of the time, and calls a function in the Flash plugin (through Flash's ExternalInterface or the earlier TCallFrame stuff), which then takes care of playing back the sound etc. (since there's no better cross browser/cross platform audio/video playback these days than what Flash provides). Not sure, however, how fixed the latency from calling a JS function until Flash handles it would be. If that varies with CPU load, it's all hell again. smile.gif

The other way might be to use variable framerates combined with a simple "animation" that plays the sound - but I haven't tried that approach - should be more accurate, since the timeline in Flash is more accurate than AS timers by design.

This post has been edited by Kaneda: Jul 2 2007, 03:20 PM
Go to the top of the page
 
+Quote Post
Resurrection
post Jul 2 2007, 03:35 PM
Post #8


GMC:er
*

Group: Members
Posts: 202
Joined: 22-May 07
Member No.: 1.906



QUOTE (Kaneda @ Jul 2 2007, 02:03 PM) *
I'll have a go, although I gave up on the Flash timing accuracy issue a loooong time ago wink.gif


Great explanation Kaneda! There's little doubt that an environment like flash will find it extremely difficult to generate audio-accurate timings. I write a fair amount of audio coding software, but it's within embedded devices, where you generally have access to very accurate timers within the processor that can fire interrupts at pretty precise times. If you throw in a multi-tasking OS and web-based applications, then it's not hard to see how inaccuracies can creep in, although the timing tolerances for a metronome are obviously a bit wider than for audio generally! I agree that a timer generating asynchronous events should give much better performance, provided the signals/interrupts are serviced with a fairly high priority.

Can't comment on your suggestion about using the frame/timeline in flash, as I don't really know anything about it. However, I wonder is it feasible to set up feedback control on the framerate by counting ticks over a longer period (averaging) and making small adjustments to the framerate, just to avoid continual accumulation of timing error in either direction? Just a thought, not sure if it's feasible or relevant.


--------------------
QUOTE
If you think you can, you can. And if you think you can't, you're right.
Go to the top of the page
 
+Quote Post
fkalich
post Jul 2 2007, 03:46 PM
Post #9


GMC:er
*

Group: Members
Posts: 2.581
Joined: 12-February 07
From: People's Republic of Lawrence Kansas
Member No.: 1.189



QUOTE (Resurrection @ Jul 2 2007, 09:35 AM) *
Can't comment on your suggestion about using the frame/timeline in flash, as I don't really know anything about it. However, I wonder is it feasible to set up feedback control on the framerate by counting ticks over a longer period (averaging) and making small adjustments to the framerate, just to avoid continual accumulation of timing error in either direction? Just a thought, not sure if it's feasible or relevant.


I was thinking about that, not the timeline, just a subroutine that makes adjustments. problem seems to be though, that when he is using flashplayer, a very large delay can be introduced when flash gets busy, and even though it could be corrected after the fact, the cow already got out of the barn. am i wrong?

but then again, perhaps whatever the timing interval was, the routine could divide that interval by some factor, say by 4, so make the check more often, see if it is time to act, if not make a correction. i expect some scheme to make running corrections would work tolerably. it might screw up once in awhile, but it might still be accurate enough to be acceptable.

This post has been edited by fkalich: Jul 2 2007, 04:04 PM


--------------------
Go to the top of the page
 
+Quote Post
Kristofer Dahl
post Jul 2 2007, 04:24 PM
Post #10


GMC Founder & Rocker
Group Icon

Group: GMC Instructor
Posts: 12.977
Joined: 15-August 05
From: Stockholm, Sweden
Member No.: 2



Thanks Kaneda - even though this obviously is way beyon my level of understanding - it's seems you know what you are talking about. smile.gif

If anyone wants to have a go at the swf file - pm me and we can try it live!


--------------------
It's all about the journey, not the destination.

Check out my video lessons + my collabs KMC Metal & Shadow Of The Ninja. And my latest progress report!
Go to the top of the page
 
+Quote Post
Eat-Sleep-andJam
post Jul 2 2007, 05:03 PM
Post #11


GMC:er
*

Group: Members
Posts: 2.412
Joined: 23-February 07
From: New york
Member No.: 1.243



Thats strange that it does that unsure.gif .. Have you asked Marraboy himself about the bug? Him being the flash programmer he might know how to fix it ?
But as for now it seems we can at least practice up to where it starts making it mistakes. Does anyone have an exact Bpm of when this occurs ? Thanks-John


--------------------
Join Me On the Lyrics Board !


"Find something worth dying for...



...And live for it"
-The Uncreator
Go to the top of the page
 
+Quote Post
fkalich
post Jul 2 2007, 05:34 PM
Post #12


GMC:er
*

Group: Members
Posts: 2.581
Joined: 12-February 07
From: People's Republic of Lawrence Kansas
Member No.: 1.189



QUOTE (Eat-Sleep-andJam @ Jul 2 2007, 11:03 AM) *
Thats strange that it does that unsure.gif .. Have you asked Marraboy himself about the bug? Him being the flash programmer he might know how to fix it ?
But as for now it seems we can at least practice up to where it starts making it mistakes. Does anyone have an exact Bpm of when this occurs ? Thanks-John


it is not a bug, not really. the logic of what he did is there. however flash is a very high level language, that is, a very busy one. a lot goes on, and subroutines have to wait their turn to be served. normally these slight delays (fractions of a second) have no bearing in any practical sense, and are not noticed. for applications that require precise timings, a language closer to the machine is more appropriate. however, for such languages, building a gui is a major task. in flash building a gui such as for this metronome is trivial.

i will play around with this, see if i can come up with something, in the next couple days (unless somebody takes on the challenge and beats me to it). there is almost always a solution to these things, not always, but most of the time. basically what has been stated above is what needs to be done, a scheme to correct the inevitable delays in response.

edit: here is a link, where the guy says pretty much the same thing.

http://www.bit-101.com/blog/?p=910

I am hoping somebody takes up the challenge so i don't have to, being a very lazy person, who does not have a lot of ego, or at least a person who tries to keep his ego in check, i would be very happy with that outcome. I don't think it would be very difficult, it does not have to be perfect, just close enough from the user's perspective.

This post has been edited by fkalich: Jul 2 2007, 05:56 PM


--------------------
Go to the top of the page
 
+Quote Post
Kaneda
post Jul 2 2007, 06:03 PM
Post #13


Other side of the coin
*

Group: Members
Posts: 266
Joined: 3-May 07
From: CPH, Denmark
Member No.: 1.754



QUOTE (fkalich @ Jul 2 2007, 06:34 PM) *
I am hoping somebody takes up the challenge so i don't have to, being a very lazy person, who does not have a lot of ego, or at least a person who tries to keep his ego in check, i would be very happy with that outcome. I don't think it would be very difficult, it does not have to be perfect, just close enough from the user's perspective.


Same thing here, fkalich smile.gif Except I wouldn't ever take up the challenge, since a project I'm already doing for GMC is on hold while I find a new job etc. and get over Summer. I, on the contrary, hope that someone else doesn't take that project over before then wink.gif

EDIT: Might add, if you do look into this, Flash may actually "freeze" completely for up to 500 ms, mostly in order to garbage collect - there wouldn't be much garbage collection done in the metronome itself, but unfortunately, only one instance of the FlashPlayer is used across each browser - for all Flash content, and since it's used so much for streaming video these days, this freezing might also become an issue (although you'd deal with it the same way as the other timer lagging).

This post has been edited by Kaneda: Jul 2 2007, 06:06 PM
Go to the top of the page
 
+Quote Post
Marraboy
post Jul 2 2007, 07:02 PM
Post #14


GMC:er
*

Group: Members
Posts: 25
Joined: 11-June 07
From: Carlisle, UK
Member No.: 2.067



Blimey!!! A few posts here then!!!


The metronome does indeed use setInterval()

I'm a little unconvinced that the problem is simply Flash itself. There is a very minimal amount of code in the program. Not sure about garbage collection in Flash, but I guess there wouldn't be much garbage to collect as there is not many variables.

One thing I can confirm is that when the SWF file runs independant of the browser, in a .exe projector it seems to perform better (much better in fact). Not sure if this has something to do with it being compiled into a binary executable?

Flash is a bit poor when it comes to 'realtime' stuff when in a browser, especially with graphics.

Maybe Flash isn't cut out to be a metronome!!!

Marraboy
Go to the top of the page
 
+Quote Post
Kaneda
post Jul 2 2007, 07:25 PM
Post #15


Other side of the coin
*

Group: Members
Posts: 266
Joined: 3-May 07
From: CPH, Denmark
Member No.: 1.754



QUOTE (Marraboy @ Jul 2 2007, 08:02 PM) *
Blimey!!! A few posts here then!!!
The metronome does indeed use setInterval()

I'm a little unconvinced that the problem is simply Flash itself. There is a very minimal amount of code in the program. Not sure about garbage collection in Flash, but I guess there wouldn't be much garbage to collect as there is not many variables.

One thing I can confirm is that when the SWF file runs independant of the browser, in a .exe projector it seems to perform better (much better in fact). Not sure if this has something to do with it being compiled into a binary executable?

Flash is a bit poor when it comes to 'realtime' stuff when in a browser, especially with graphics.

Maybe Flash isn't cut out to be a metronome!!!

Marraboy


The problem with graphics performance is often due to the FlashPlayer having to cooperate with the browser (even if it doesn't cooperate much - Flash content is by default simply drawn on top of the browser window - disregarding whether any HTML is supposed to be above parts of it wink.gif). But since there's not any animation in the metronome, that's not it.

The problem with performance in general, is that the moment you have FlashPlayer in a browser, two things are crippling it:

1. The browser has to allocate time to FlashPlayer out of the time the OS has allocated to the browser (i.e., a fraction of a fraction), while in standalone, the OS allocates time directly to FlashPlayer.

2. The FlashPlayer experience will often degrade over time, until the browser is closed, because as soon as a page uses Flash, the FlashPlayer is loaded, and then that same instance will be used for the rest of the browser's "lifetime".

Actually, if you don't clear a setInterval on unload, you may actually see the interval being fired twice as often each time you press refresh - simply because the interval keeps running in FlashPlayer after the swf has been unloaded tongue.gif It's a leak going back to FlashPlayer 4 or so, and I don't believe they've fixed it to this day (they hadn't in FlashPlayer 7). This may also hamper performance in your metronome for each reload (rather than playing the tick twice per interval), depending on how the interval handler is written.

There are other leaks like that, including a fair amount of memory leaks. Garbage collection is handled globally across swf's in the browser (and "absolutely", as in, garbage collection starts when the total allocated memory gets to a certain threshold), and thus while your swf doesn't need much garbage collection, remains of some other swf (like YouTube) may - even if the swf is not playing anymore

The .exe standalone file is really no different from the .swf - it's the same .swf appended to a static version of the FlashPlayer, which plays back the file in pretty much exactly the same way as the browser plugin - with the added benefits described above.

Have you tried doing it in AS3/Flash CS3? While setInterval and Timer are apparently still as inaccurate as always, AS3 does have an immense performance increase when it comes to running code, so the lag may not be as big.
Go to the top of the page
 
+Quote Post
fkalich
post Jul 2 2007, 07:55 PM
Post #16


GMC:er
*

Group: Members
Posts: 2.581
Joined: 12-February 07
From: People's Republic of Lawrence Kansas
Member No.: 1.189



have you played with the AS3 Timer class? My download substription of AS3 just expired, gettting it on another computer (at some point I am going to have to fork out the $500 for the Web premium upgrade). I will play with the Timer class in a bit, do some testing. I don't think that was in 2.0, correct?

edit: correct, new to AS3, worth a try.

This post has been edited by fkalich: Jul 2 2007, 08:11 PM


--------------------
Go to the top of the page
 
+Quote Post
Marraboy
post Jul 2 2007, 09:08 PM
Post #17


GMC:er
*

Group: Members
Posts: 25
Joined: 11-June 07
From: Carlisle, UK
Member No.: 2.067



I haven't even looked at AS3 yet, as I have too much onoing AS2 stuff!!!

It's simple don't look at Youtube before you use the metronome!!! smile.gif

I guess that if the user closes the browser completely and reopens this will destroy the initial instance of the flash player?

As you know your flash stuff, have a look at this and see what you think: http://www.electro-server.com/forum/?f=2&m=3743 - it's baffling me?!?!?!

This post has been edited by Marraboy: Jul 2 2007, 09:10 PM
Go to the top of the page
 
+Quote Post
fkalich
post Jul 3 2007, 12:42 AM
Post #18


GMC:er
*

Group: Members
Posts: 2.581
Joined: 12-February 07
From: People's Republic of Lawrence Kansas
Member No.: 1.189



QUOTE (Marraboy @ Jul 2 2007, 02:08 PM) *
I haven't even looked at AS3 yet, as I have too much onoing AS2 stuff!!!

It's simple don't look at Youtube before you use the metronome!!! smile.gif

I guess that if the user closes the browser completely and reopens this will destroy the initial instance of the flash player?

As you know your flash stuff, have a look at this and see what you think: http://www.electro-server.com/forum/?f=2&m=3743 - it's baffling me?!?!?!


I will look later at that link. BTW, Moock's 3.0 book just came out, I ordered it today. As you may agree, nobody writes on Actionscript better than Moock.

I am surprised that you got the metronome to work at all with Flash, in any steady beat. I ran some tests using 3.0, and to me it does not seem possible, just too much going on. Below is an example where i check every 5 milliseconds, at 240bps. Seems like it is impossible to avoid delays, based on my readouts. Weird thing is that even when the readouts are pretty steady, I can hear an unsteady pattern to the beat. Perhaps the routine passes the command to the mp3 players asynchronously, but there is a delay in the player module, would not surprise me. You are saying you got this to go steady?

Based on what i have seen, i have concluded that our friend from Holland is right, just no way with flash to get that kind of accuracy. I read where that is the case in another source, seems that delays of up to 100 ms can occur at times, and smaller ones quite frequently.

I realize only half our audience will understand this, not the half working in the food service industry.


package {
import flash.display.Sprite;
import flash.utils.*;
import flash.events.TimerEvent;
import flash.media.Sound;
import flash.media.SoundChannel;
import flash.net.URLRequest;

public class MyTest extends Sprite
{
// The time of the last beep
var lastBeepTime:Date;
// 4 bps so 240 bpms
var INTENDEDINTERVAL:Number = 250;

var _sound:Sound = null;
private var url:String = "beep_1.mp3";
var myBeep:Sound;

public function MyTest()
{
// Timer will go off every 5 ms
var myTimer:Timer = new Timer(5);
myTimer.addEventListener(TimerEvent.TIMER, onTimer);
lastBeepTime = new Date();

var request:URLRequest = new URLRequest(url);
myBeep = new Sound();
myBeep.load(request);

myTimer.start();
}

function onTimer(event:TimerEvent):void
{
var sampleTime:Date = new Date();
var msPassed:Number = sampleTime.getTime() - lastBeepTime.getTime();
// if time passed is at least the interval - 5ms
if( msPassed > (INTENDEDINTERVAL-5) ) {
trace("Time elapsed Before BEEP at "+msPassed+" MS");
myBeep.play();
lastBeepTime = sampleTime;
}

}
}
}

This post has been edited by fkalich: Jul 3 2007, 12:47 AM


--------------------
Go to the top of the page
 
+Quote Post
Kaneda
post Jul 3 2007, 08:11 AM
Post #19


Other side of the coin
*

Group: Members
Posts: 266
Joined: 3-May 07
From: CPH, Denmark
Member No.: 1.754



Instantiating a Date object every 5 ms at least won't make it more accurate smile.gif And since all of FlashPlayer's timing is based on SetTimer (in the Windows API), rather than multimedia timers, and SetTimer/WM_TIMER has an accuracy around 10-15 milliseconds, setting intervals at 5 ms will do no good smile.gif

And since the Timer class was already discussed earlier in the thread, I guess my job here is done. cool.gif

This post has been edited by Kaneda: Jul 3 2007, 08:11 AM
Go to the top of the page
 
+Quote Post
fkalich
post Jul 3 2007, 08:41 AM
Post #20


GMC:er
*

Group: Members
Posts: 2.581
Joined: 12-February 07
From: People's Republic of Lawrence Kansas
Member No.: 1.189



QUOTE (Kaneda @ Jul 3 2007, 02:11 AM) *
Instantiating a Date object every 5 ms at least won't make it more accurate smile.gif And since all of FlashPlayer's timing is based on SetTimer (in the Windows API), rather than multimedia timers, and SetTimer/WM_TIMER has an accuracy around 10-15 milliseconds, setting intervals at 5 ms will do no good smile.gif


That is not consistent with my test results. Below I show readouts with sampling every 250ms for that example (240bps), and then with 5ms sampling. You can see the 5ms are dramatically more accurate. I ran some further tests. The average error size grows as the sleep interval that you use increases. With frequent sampling (< 25 ms) timing error is generally single digit. With 250ms in the teens. With 1000ms sampling the errors tend to run closer to 50ms. Clearly we have cumulative damage to the calculation, the longer the interval between the sampling of the time.

However, if I move my mouse around while doing the test, the numbers blow up. That is why I don't think this will help. Also I think the mp3 player itself will have some unpredictable response delays using Flash, so even if the call is accurately timed, it may be off beat due to delayed response of the player. metronomes are probably not practical using Flash. As you said earlier.


250MS SAMPLING:

Time elapsed Before BEEP at 328 MS
Time elapsed Before BEEP at 281 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 297 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 265 MS
Time elapsed Before BEEP at 266 MS


5 MS SAMPLING:

Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 266 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS
Time elapsed Before BEEP at 250 MS

This post has been edited by fkalich: Jul 3 2007, 09:16 AM


--------------------
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Fast ReplyReply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 


RSS Lo-Fi Version Time is now: 3rd September 2014 - 05:41 AM