Is there any software to get BVH data directly from kinect? I searched on net and found Kinect BVH MoCap(http://tech.integrate.biz/kinect_mocap.htm) , but it is not working for me.
No. There is no built in mechanism to save Kinect data at all - no matter what format you want it in. The Kinect Studio does save off stream data, but I've not looked at the files to see what they look like internally.
You could look into the Kinect Toolbox, which provides functions to save off any of the 3 streams to a file. You can save the file and then manipulate it as necessary, perhaps write a parser to translate the data. Alternatively, you could manipulate the data before you save it off.
You could also write your own parser. The Skeleton objects are serializable, which means you could save them to a List (or some other array type object) along with a time stamp. When you are ready to save to the file, serialize the List and you will get a standard XML dump of the List and the Skeleton objects inside. Again, you could write a function that just translate it into the proper format before saving it as well.
Related
I just started to look into libGDX and I really enjoyed it. Loading a tile map I generated with an editor was really simple. But I have in mind to work on a game where the player can modify and extend the map.
So here is my question: Is it somehow possible to add/delete/change fields in a com.badlogic.gdx.maps.tiled.TiledMap and save the result to disc?
Unfortunately, right now there is no built-in feature to store TiledMaps.
I know only the .tmx format of TilEd, but this is a pretty easy and straight-forward XML format, which is very similar to the structure of a TiledMap. Check out how TmxMapLoader loads the TiledMap and then use an XmlWriter to write your altered maps to a file in a similar way.
Is there a library function to normalize a sound file? I have searched around but could not find any.
I would like to be able to normalize a sound file and setting that into the sound file so it only needs to be done once rather than on the fly.
Can this be done with Core-Audio?
Yes it can be done, but not with a single function call.
The functionality you want is not in fact CoreAudio, but rather in ExtendedAudioFile.h - part of the AudioToolbox framework. This is available for both iOS and MacOSX. I can attest for this being rather hard to find.
Functions of interest in this header are ExtAudioFileOpenURL(), ExtAudioFileRead() and ExtAudioFileWrite().
In outline what you do:
Use ExtAudioFileOpenURL() to open the input file
Use ExtAudioFileGetProperty() with propertyId kExtAudioFileProperty_FileDataFormat to obtain an AudioStreamBasicDescription describing the file.
Possibly set the ASBD to get the format you want. AudioToolBox on MacOSX seems rather more amenable to this than on iOS.
Calculate an allocate a buffer large enough to hold the entire audio file
Read the entire file with ExtAudioFileRead() - NB: this call might not read it all in one go - operating in much the same was as POSIX read()
Perform normalisation
Use ExtAudioFileCreateWithURL() to create the output file
Use ExtAudioFileWrite() to write the normalised samples out.
Dispose of both audio files.
The documentation links to several example projects that can act as donors of working code. You'll find doing normalisation much easier with the samples as floats, but in iOS, I could never get the conversion to work automatically, so you might have to format convert yourself.
I've seen some small examples posted by Shawn Hargreaves showing manually defining some xml content with the intent to create and populate instances of c# classes, which get loaded through the content pipeline.
I can see that this would be useful if you had an editor capable of writing the file, allowing you to load a level or whatever.
But, I'm curious... does it only do read operations? Can you use this concept to save game data?
What else might it be used for?
Automatic XNB Serialization (details) is simply the ability for the content pipeline to read/write data without needing a ContentTypeWriter or ContentTypeReader. It doesn't actually provide any new features, besides reducing the amount of code you have to write to use the content pipeline.
Loading from XML (using IntermediateSerializer or through the content pipeline using the XML importer) is a separate thing.
IntermediateSerializer automatically converts .NET object instances to/from XML using reflection.
The content pipeline (whether you are using automatic XNB serialization or not) converts .NET object instances to/from binary XNB files.
The content pipeline also provides an extensible importer/processor system, on the content-build side, for generating the .NET objects in the first place (and it includes various built-in importers/processors). The built-in XML importer just uses IntermediateSerializer to go from XML to a .NET object instance.
The reason why you can't use these in your game to perform write operation (eg: saving the game state, a built-in level editor, etc) is that IntermediateSerializer (both read and write) and the writing-XNB half of the content pipeline require XNA Game Studio to be installed.
XNA Game Studio is not a redistributable. (Only the XNA runtime is redistributable.)
In all samples I've seen so far, mapreduce apps take text files as input and write text as output.
I'd like my app to read objects from the binary file and write objects back to output file.
What is the best way to do that in MapReduce?
I'm writing the app in java
SequenceFile provides a persistent data structure for binary key-value pairs. You can find more information in the below URL.
http://wiki.apache.org/hadoop/SequenceFile
http://hadoop.apache.org/common/docs/current/api/org/apache/hadoop/io/SequenceFile.html
Long story, long:
I am adding a web interface (ASPX.NET: VB) to a data acquisition system developed with LabVIEW which outputs raw data files. These raw data files are the binary representation of a LabVIEW cluster (essentially a structure). LabVIEW provides functions to instantiate a class or structure or call a method defined in a .NET DLL file.
I plan to create a DLL file containing a structure definition and a class with methods to transfer the structure. When the webpage requests data, it would call a LabVIEW executable with a filename parameter. The LabVIEW code would instantiate the structure, populate the structure from the data file, then call the method to transfer the data back to the website.
Long story, short: How do you recommend I transfer (copy) an instance of a structure from one .NET program to the VB.NET program that executed it?
Ideas considered: sockets, temp file, xml file, console output, config file, web services, CSV, some type of serialization, shared memory
Serialized XML would be my first initial stab at it. (System.Xml.Serialization namespace).
It's Microsoft-specific but it's standard "enough" that you could probably get another program w/ another technology to read it with minimal finagling, compared to previous MS object serialization technologies I've heard horror stories about.
I would build the LabVIEW code (file->(XML)-string) into a DLL which you can call directly and would return the serialized string.
Or you could read the datafile 'as-is', the LabVIEW structs aren't that hard. and they are pretty good documented:
How LabVIEW stores data in memory
Flattened data