We Keep Coding

What kind of timer is most suitable for MIDI timing?

I am writing a simple MIDI app for my own use, in C# and .NET 4.x.
I assume that commercial DAWs (on the Windows platform that is) use Windows Multimedia Timers for timing the playback of MIDI data. But I can't verify this, since commercial stuff is closed-source.
I'm hoping someone has knowledge in this area, and can tell me if my assumption is right. Or, are these DAWs using timers I'm not aware of? I want to make sure there isn't anything more suitable that I've overlooked.

Although I have not had the privilege of coding for commercial DAW projects specifically, I do have experience in coding for scenarios where the accurate timing of events is important, including MIDI processing/routing.
Your assumption is correct. Well-coded MIDI sequencers use the Windows Multimedia Timer to schedule the sending of MIDI messages to MIDI devices.
Microsoft's Multimedia Timer Reference actually mentions MIDI sequencing as an example use:
These timer services are useful for applications that demand high-resolution timing. For example, a MIDI sequencer requires a high-resolution timer because it must maintain the pace of MIDI events within a resolution of 1 millisecond.
How to use the timer is for another topic, I won't get into that here. But I'd like to point out a few things:
All modern hardware supports a timer resolution of 1 millisecond, it's basically a given, but you should still call timeGetDevCaps to make sure before calling timeBeginPeriod.
Using the multimedia timer, at 1 millisecond resolution, will have the effect of quantizing your MIDI messages to a 1 millisecond grid +/- some variance/jitter. In the vast majority of cases this is a non-issue because that is still a sufficiently fine resolution to provide reasonably nuanced timing, so far as musical timing goes anyway. If you absolutely need sub-millisecond timing, you will have to do as #iinspectable suggests - use the timer to get "close" and then spin to precisely time the sending of your MIDI messages. However, this approach comes at a cost. I don't know what your intentions are for the app, but should you have several simultaneous MIDI tracks playing, each with continuous controllers and pitch bend, you'll find your app spinning all the time and you'll peg a CPU core to 100% which is just plain bad.
Do look into Windows' Multimedia Class Scheduler Service to get prioritized access to CPU resources for your MIDI playback thread.
Don't be discouraged by comments from #iinspectable. You can absolutely do high-performance MIDI sequencing using C#/.NET. Your only concern needs to be that of the garbage collector unpredicatably pausing your app. You can always code in a way that minimizes GC (e.g. use structs not classes, don't create/destroy anything during playback). Also consider using GC.TryStartNoGCRegion to, for example, prevent GC pauses during playback.

WebCam: Switch on and of or or keep on

Good day,
I wasn't sure if I should post this on the software or hardware stack; I apologize in advance if this is an invalid question.
I wrote a little application that I am using to make time lapse videos - currently it only takes the pictures using a webcam. I know there are already a few available for download, but none of them did 100% what I wanted, and some of them were a little buggy, so I decided I'd rather create my own.
The interval at which the pictures are taken can be configured anywhere from 5 seconds up. Version 1.x would activate the camera and keep it on while in "Time Lapse Mode" and save images to disc at the specified intervals. This approach proved to be very memory intensive - understandably, in retrospect.
I decided to start from scratch - Version 2.x. This version would keep the camera off and only switch it on when it needed to take a picture, and switch it off again. This approach proved much more efficient. The reason for the minimum limit of 5 second intervals is because the camera takes about 1 second to switch on and then roughly the same amount of time to switch off. Perhaps in the future I could change it to keep the camera on when the interval < 5. For now, however, for what I actually want to use it, this will do perfectly.
When I was little we, as children, were told that switching an incandescent bulb on and off and on and off is not good for the bulb - according to a colleague of mine, reliable in that field, this is true.
This got me thinking. Could it be harmful to my webcam if I switch it on and off at, say, 10 second intervals for, let's say, a day or two? And how would switching on and off compare to keeping the device on for a few days? I don't understand what happens on a hardware level so I can't say.
I suppose I have a couple of options:
Switch the application on and off as required to take the pictures. This could result in the camera being switched a few thousand times a day.
Keep the camera on. This could mean the camera might be active for very long periods of time. What if I want to create a time lapse video over a month? Or even a year? Not to mention the memory problem.
Switch between the two modes. When interval < 2 minutes ? keep on : switch. This seems like the best of both worlds but now I'm faced with the memory problem when interval < 2 minutes
Thank you in advance for any and all comments and suggestions - much appreciated.
Kind regards,
me.

Could it be harmful to my webcam if I switch it on and off at, say, 10 second intervals for, let's say, a day or two?
Switching the camera on and off will have no affect on it's lifespan.
How about keeping it on for long periods of time?
Well that really depends on the camera but for something as low powered as a webcam you should be able to run it for many many years before it begins to fail.
Not sure how you are getting frames from your camera but it should not be extremely memory intensive. Using AForge.NET you can pretty simply grab frames from you camera. Tutorial If you could post your code I could better see how to point you in the direction of optimizing it.

How to play sound as soon as possible?

There are about 60 sound samples in my application. I have to play it with strong accuracy in time. 5ms will mater. Sound must play in response to user actions. So I do not know what sound'll play next. I thinked aboud precreating of SoundEffectInstance for all sounds. Does creating of SoundEffectInstance take any time and memory? Is it full copy of SoundEffect in memory or just some pointer information. Can I improve my application if I'll precreate SoundEffectInstances? Is there any other way to play sample as soon as possible in XNA?

A SoundEffect contains the actual waveform data. It uses up a large amount of memory (as much as the waveform data requires).
A SoundEffectInstance is a small object, containing data about playback (position, volume, etc) and a handle to the "voice" that has been allocated to do the playback.
When you use SoundEffect.Play, internally it creates a SoundEffectInstance. It can also pool these instances - so it does not need to recreate them on subsequent calls.
Creating a SoundEffectInstance takes some time and memory. For sound effects in a game running at 30FPS (33ms per frame) the latency involved should be imperceptible.
If you're trying to play back sequenced music by mixing together different sound effects, where even 5ms matters, you need to implement your own audio mixer using DynamicSoundEffectInstance. This will ensure that sounds are synchronised down to the sample.
If you're trying to create some kind of real-time playable "instrument", and you're trying to get your input-to-output latency down to 5ms - then give up now. 5ms is absurdly good and normally requires specialist equipment and software.
Still, if you need to reduce your input-to-output latency as best you can, you can poll input more frequently than once per frame. And you should still probably use DSEI. I am not sure if DSEI has a configurable playback buffer size, but if it does you should make it as small as possible without introducing audio glitching.

When a user chooses a set, you should load those sound effects into a dictionary, so accessing them will be faster later on.
However, you shouldn't load all the sound effects, especially those that you don't need in a certain screen or set. Additionnally, you should unload the sound effects you won't need anymore.
It does take time to load those sound effects, depending on the size and quantity you want to load. I'd recommend you make a basic loading screen for loading/unloading content in your game (most games do it that way). You will be loading the soundeffect (wav format I guess?) in memory, not just a pointer, so that's why sound effects need to be kept short.
An already loaded sound effect will play very fast (the delay is imperceptible). Preloading will increase the application's performance, at the cost of memory usage.

How can I compare two captures to see which one is louder?

Given two byte arrays of data captured from a microphone, how can I determine which one has more spikes in noise? I would assume there is an algorithm I can apply to the data, but I have no idea where to start.
Getting down to it, I need to be able to determine when a baby is crying vs ambient noise in the room.
If it helps, I am using the Microsoft.Xna.Framework.Audio.Microphone class to capture the sound.

you can convert each sample (normalised to a range 1.0 to -1.0) into a decibel rating by applying the formula
dB = 20 * log-base-10 (sample-value)
To be honest, so long as you don't mind the occasional false positive, and your microphone is set up OK, you should have no problem telling the difference between a baby crying and ambient background noise, without going through the hassle of doing an FFT.
I'd recommend you having a look at the source code for a noise gate, which does pretty much what you are after, with configurable attack times & thresholds.

First use a Fast Fourier Transform to transform the signal into the frequency domain.
Then check if the signal in the typical "cry-frequencies" is significantly higher than the other amplitudes.
The preprocessor of the speex codec supports noise vs signal detection, but I don't know if you can get it to work with XNA.
Or if you really want some kind of loudness calculate the sum of squares of the amplitudes from the frequencies you're interested in (for example 50-20000Hz) and if the average of that over the last 30 seconds is significantly higher than the average over the last 10 minutes or exceeds a certain absolute threshold sound the alarm.

Louder at what point? The signal's average amplitude will tell you which one is louder on average, but that is kind of a dumb, brute force way to go about it. It may work for you in practice though.
Getting down to it, I need to be able to determine when a baby is crying vs ambient noise in the room.
Ok, so, I'm just throwing out ideas here; I am by no means an expert on audio processing.
If you know your input, i.e., a baby crying (relatively loud with a high pitch) versus ambient noise (relatively quiet), you should be able to analyze the signal in terms of pitch (frequency) and amplitude (loudness). Of course, if during he recording someone drops some pots and pans onto the kitchen floor, that will be tough to discern.
As a first pass I would simply traverse the signal, maintaining a standard deviation of pitch and amplitude throughout, and then set a flag when those deviations jump beyond some threshold that you will have to define. When they come back down you may be able to safely assume that you captured the baby's cry.
Again, just throwing you an idea here. You will have to see how it works in practice with actual data.

I agree with #Ed Swangren, it will take a lot of playing with samples of data for a lot of sources. To me, it sounds like the trick will be to limit or hopefully eliminate false positives. My experience with babies is they are much louder crying than the environment. so, keeping track of the average measurements (freq/amp/??) of the normal environment and then classifying how well the changes match the characteristics of a crying baby which changes from kid to kid, so you'll probably want a system that 'learns'. Best of luck.
update: you might find this library useful http://naudio.codeplex.com/

Algorithm to flatten peak usage over time?

I have an environment that serves many devices spread across 3 time zones by receiving and sending data during the wee hours of the night. The distribution of these devices was determined pseudo-randomly based on an identification number and a simple calculation using a modulo operation. The result of such a calculation creates an unnecessary artificial peak which consumes more resources than I'd like during certain hours of the night.
As part of our protocol I can instruct devices when to connect to our system on subsequent nights.
I am seeking an algorithm which can generally distribute the peak into a more level line (albeit generally higher at most times) or at least a shove in the right direction - meaning what sort of terminology should I spend my time reading about. I have available to me identification numbers for devices, the current time, and the device's time zone as inputs for performing calculation. I can also perform some up front analytical calculations to create pools from which to draw slots from, though I feel this approach may be less elegant than I am hoping for (though a learning algorithm may not be a bad thing...).
(Ultimately and somewhat less relevant I will be implementing this algorithm using C#.)

If you want to avoid the spikes associated with using random times, look at the various hashing functions used for hashtables. Your reading might start at the wikipedia articles on the subject:
http://en.wikipedia.org/wiki/Hash_function
Basically, divide whatever you want your update window to be into the appropriate number of buckets. One option might be 3 hours * 60 minutes * 60 seconds = 10800 buckets. Then use that as your hashtable size, for the chosen hashing function. Your unique input might be device ID. Don't forget to use GMT for the chosen time. Your programming language of choice probably has a number of built in hashing functions, but the article should provide some links to get you started if you want to implement one from scratch.
This approach is superior to the earlier answer of random access times because it has much better evenness properties, and ensures that your access patterns will be approximately flat, as compared to the random function which is likely to sometimes exhibit spikes.
Here's some more specific information on how to implement various functions:
http://www.partow.net/programming/hashfunctions/index.html

You say that you can tell devices what time to connect, so I don't see why you need anything random or modulused. When each device connects, pick a time tomorrow which currently doesn't have many devices assigned to it, and assign the device to that time. If the devices all take about the same amount of resources to service, then a trivial greedy algorithm will produce a completely smooth distribution - assign each device to whatever time is currently least congested. If the server handles other work than just these devices, then you'd want to start with its typical load profile, then add the device load to that. I wouldn't really call this "analytical calculations", just storing a histogram of expected load against time for the next 24 hours.
Or do you have the problem that the device might not obey instructions (for example it might be offline at its assigned time, and then connect whenever it's next on)? Obviously if your users in a particular time zone all start work at the same time in the morning, then that would be a problematic strategy.

Simply take the number of devices and divide your time interval into n equal segments and allocate each segment to a device, informing them of when to connect when they next connect.
This will give you an optimally uniform distribution in all cases.
Normalize all times to GMT, what do you care about time zones or day light savings time or whatever? Now is now no matter what time zone you're in.
Adding a random distribution can lead to clumping (a uniform random distribution is only uniform in the limit, but not necessarily for any particular sample), and really should be used if there's no feedback mechanism. Since you can control to some extent when they connect a random component is not at all necessary and is not even remotely optimal.
If you're concerned about clock drift across devices consider even if you added randomness this wouldn't decrease the randomness of your clock drift in any way, and would only contribute to an even less optimal allocation.
If you want to ensure a stable distribution of devices by region, then compute the ratio of devices per region, and distribute the slot allocations appropriately. For instance, if you have 50/25/25 by time zone respectively, assign slots to the first time zone, then the next two slots to the remaining time zones, then repeat.