HowTo: Upgrade Kinect Audio Positioning code from older Beta SDK

Exploring the Kinect SDK v1.8 Developer Toolkit Browser application, I noticed some audio positioning visualizations at various samples (specifically at Audio Basics, Audio Explorer and Kinect Explorer samples), but I kept on looking for some simpler/cleaner sample code to return audio positioning info that would be easier to reuse.

So I can across http://kinectaudioposition.codeplex.com that looked like a good candidate, since it was defining a reusable KinectMicArray class to return the BeamAngle and SoundSourceAngle’s of a KinectAudioSource. There was also some sample code on how to use that KinectMicArray class at http://channel9.msdn.com/coding4fun/kinect/Kinect-Audio-Positioning

However, after downloading it, I realized it was written (hadn’t seen the notice it had on its page) for an older Kinect Beta SDK version. So I decided to port that code to Kinect SDK v1.8 (which is the latest Kinect SDK version to support Kinect for Windows v1.0 and Kinect for Xbox 360 sensors, since the newer Kinect SDK supports KfW v2.0 and Kinect for Xbox One – in fact KfW v2.0 is now “merged” with the Kinect for Xbox One product via the use of an external adapter with the later to connect to a PC).

During that code porting to Kinect SDK v1.8 I noticed the following issues that had to be addressed. At the older Kinect Beta SDK:

• one could instantiate a KinectAudioSource class directly instead of having to get it from a started KinectSensor, plus the object was disposable so one could place it in "using" clause
• one could do audioSource.SystemMode = SystemMode.OptibeamArrayOnly (that property doesn’t seem to be available anymore to set)
• audioSource.BeamAngleChanged was called BeamChanged
• audioSource.SoundSourceAngleChanged probably didn’t exist (have seen older code use a BackgroundWorker and do polling)
• audioSource.SoundSourceAngleConfidence was called SoundSourcePositionConfidence
• audioSource.SoundSourceAngle was called SoundSourcePosition
• audioSource.BeamAngle and audioSource.SoundSourceAngle (then called SoundSourcePosition) were returning radians instead of degrees (so one usually had to convert to degrees using 180.0 * rad / Math.PI)

I took the chance to cleanup and refactor the original code and XAML and since the original codeplex site just had a single download and not any source code in the repository to fork, I uploaded the whole thing ZIPed under their source code / patches area.

Structuring (physical) source and (virtual) solution folders for portability

Copying here those comments of mine at a discussion on the GraphX project:

https://github.com/panthernet/GraphX/issues/21

describing the source code (physical) folder structure and the Visual Studio solution (virtual) folder structure I’ve been using at ClipFlair and other multi-platform projects.

——

looking at the folders/projects/libraries/namespaces naming, I think it would be more appropriate to add the platform at the end of the name, say GraphX.somePart.PCL, GraphX.somePart.UWA (=Universal Windows Application model [aka Win10]) etc. Not sure how easy it will be though for contributors to merge pending changes via GitHub if you do such drastic changes (I’m still struggling with Git myself, prefer Mercurial)

…

Speaking of moving the platform to the end of the name (e.g. GraphX.Controls.WPF, GraphX.Controls.SL5 etc.), to do it on the folder names (apart from doing at the source code for packages, target assemblies etc.), I think one has to use some Version Control command to "move" (Git should have something like that) the files to the new folder, else other contributors may have issue merging their changes.

Despite the trouble to do it, I think it is better for the long run. Also, all GraphX.SomePart.* subfolders could then be grouped in a GraphX.SomePart folder as subfolders where a Source or Common subfolder would also exists that has all the common code those platform-specific versions of GraphX.SomePart share (via linked files to ..\Common\SomeFile, ..\Common\SomeFolder\SomeFile and ..\Common\SomeOtherFolder\SomeFile etc.)

This is the scheme I’ve been using (and I’m very satisfied with) at http://clipflair.codeplex.com and other projects (e.g. at the AmnesiaOfWho game [http://facebook.com/AmnesiaOfWho] that has separate versions for SL5, WP7 and WP8 and WPF version on the works, plus WRT (WinRT) and UWA [Universal Windows App] too coming in the near future, with all code and most XAML shared via linked files and UserControl[s])

…

I meant I’d expect GraphX.Common folder with GraphX.Common.PCL in it and GraphX.Common.WP7 etc. versions for example also in that folder since PCL is usually set at WP8 level. This is just an example.

What I’m saying is that the platform name is the last part of the specialization chain, so logically GraphX comes first then say comes Controls then comes WPF, SL5, WP8 etc. in the folder name.

Also would have 3 parent folders Controls, Common and Logic. The last two would just contain the respective .PCL subfolder for now, but I can contribute subfolders for specific platforms too, esp for those the common PCL profile doesn’t cover. Source would be at Controls\Source, Common\Source, Logic\Source and respective platform specific projects (even the pcl projects) would use linked files

aka

GraphX (contains GraphX.sln)

–\Controls
—-\Source
—-\GraphX.Controls.WP7
—-\GraphX.Controls.WP8
—-\GraphX.Controls.SL5 (contains GraphX.Controls.SL5.csproj)
—-\GraphX.Controls.WPF (contains GraphX.Controls.WPF.csproj)
—-\GraphX.Controls.WIN8
—-\GraphX.Controls.UWA
—- … (more platform specific versions)

–\Common
—-\Source
—-\GraphX.Common.PCL
—- … (platform specific versions, esp. those not covered by the settings chosen at the PCL)

–\Logic
—-\Source
—-\GraphX.Logic.PCL
—- … (platform specific versions, esp. those not covered by the settings chosen at the PCL)

The same structure would also be used at examples to cover the potential of porting some of them to more platforms:

–\Examples
—-\SomeExample
——\Source
——\SomeExample.WPF
——\SomeExample.SL5
—-\SomeOtherExample
——\Source
——\SomeOtherExample.WIN8
——\SomeOtherExample.UWA
etc.

Of course common code at each folder is at the Source subfolder of that folder, shared using linked files (e.g. at \Examples\SomeExample\Source) and platform specific code is inside the respective projects (e.g. at \Examples\SomeExample\SomeExample.WPF)

Similarly the GraphX.sln would contain solution folders "Controls", "Common" and "Examples", though it could also contain separate solution (virtual) folders per platform that have each one of them "Controls", "Common" and "Examples" in them. That is the solution’s folder structure is organized per-platform in such a case. This is mostly useful if you want to focus on a specific platform each time when developing. However since the solution folders are virtual, one could even go as far as having two solutions, one with the same structure as the filesystem folders I suggest and one with a per-platform/target structure.

I follow the per-platform virtual solution folders style at ClipFlair.sln in http://clipflair.codeplex.com, while the real folders are structured as I describe above (where each module has its own physical subfolders for the various platforms). In fact some module subfolders there (say Client\ZUI\ColorChooser) contain their own extra solution file when I want to be able to focus just on a certain module. That solution just includes the respective ColorChooser.WPF, ColorChooser.SL5 etc. subprojects from respective subfolders). Such solutions also contain virtual WPF, Silverlight etc. subfolders that has as children apart from the respective platform-specific project (say ColorChooser.WPF) any other platform-specific projects needed (e.g. ….\Helpers\Utils\Utils.WPF\Utils.WPF.csproj etc.) by that module to compile.

…

Speaking of Xamarin, adding support for that too could follow the same pattern as described above (PCL where possible and platform-specific versions for .XamarinIOS, .XamarinAndroid etc. where needed)

Source code analyzers for .NET porting & Portable Class Libraries (PCL)

• .NET Portability Analyzer extension
  https://visualstudiogallery.msdn.microsoft.com/1177943e-cfb7-4822-a8a6-e56c7905292b
• API Portability Analyzer – Alpha (command-line version)
  http://www.microsoft.com/en-us/download/details.aspx?id=42678
• PLIB API XLS
  https://onedrive.live.com/view.aspx?resid=8A7FB4A4B32FB2C9!180&app=Excel&authkey=!AHaBmLAhQ49YCI0
• Xamarin Scanner (How Mobile is your .NET code?)
  http://scan.xamarin.com/

Converting C structs and unions to Pascal (or Object Pascal / Delphi) records

I’ve been recently adding support for QuickTime TimeCode tracks to the JEDI QuickTime library’s “qt_QuickTimeComponents.pas” file and I thought I should share a quick reminder on how we convert C structs (records) and unions (sets) into Pascal (Delphi / Object Pascal in this case) records:

Structs:

struct TimeCodeCounter {
long counter;
};
typedef struct TimeCodeCounter TimeCodeCounter;

type
long=integer; //in JEDI QuickTime I opted to create aliases for common C types to avoid converting them to Pascal equivalents everywhere
TimeCodeCounter = record
counter:long;
end;

Unions:

union TimeCodeRecord {
TimeCodeTime t;
TimeCodeCounter c;
};

type TimeCodeRecord = record
case integer of //C’s union
0: (t: TimeCodeTime);
1: (c: TimeCodeCounter);
end;

Do note that you should use “packed record” in Pascal if the C code uses respective #pragma command to define 0-packing gap between record fields (the default for C and Pascal compilers is to do field alignment to word [16-bit] boundaries for optimization purposes)