I'm working on a project that requires real time tracking of vocal formants using Digital Signal Processing of live mic input.
My environment is Microsoft VC++ 2010 Express, the target platform is Windows. It seems extremely difficult to find a good DSP SDK that isn't built to develop for unix/linux or depend on cygwin for windows support. Most of the DSP stuff I was able to find for windows are pipe and box environments, where you make boxes that stand for DSP functions and pipe around live audio between them to make some result.
Is there either a good DSP SDK that works well with MSVC++ 2010 for windows development?
While there aren't many good dedicated DSP Libraries and SDK's available for C++ on Windows, there are alternatives that are capable of DSP and accessible through C++ on windows.
Matlab apparently has an API for controlling an instance via C++, however matlab is extremely expensive for this application. I've found evidence that Octave, the free open source matlab compatible environment, has some C++ api for direct access to it's functions. However I am having trouble finding exactly where this API is hidden, but I'll spawn another question considering that if I don't find some answers among the materials available to me.
Try Intel's IPP for Signal Processing.
There are some Intel's DSP libraries for windows within their set of so called "Integrated Performance Primitives", IPP
: https://software.intel.com/en-us/get-started-with-ipp-for-windows. They are advertising that they support Windows, Linux and MacOS as well.
Search for document Architecture Developer Reference. Volume 1. Signal and Data Processing for a list of already available functions.
I believe that there is a possibility that the libraries are free, except for encryption portion of it.
Related
I have an embedded device with WinCE 6.0 as OS. The manufacturer provides an IDE for 3rd party development to it. The IDE pretty much allows nothing else than
.NET 3.5 Compact Framework scripting that's invoked from various events from the main application
Adding files to the device.
The included mediaplayer seems to be using DirectShow and the OS has media codec only for mpeg-1 encoded video playback. My goal is to to be able to play media encoded with some other codecs as well inside that main application.
I've already managed to use DirectShowNETCF (DirectShow wrapper for .NET Compact Framework) and successfully playback mpeg-1 encoded video.
I'm totally new with this stuff and I have tons of (stupid) questions. I'll try to narrow them down:
The OS is based on WinCE, but as far as I've understood, it's actually always some customized version of it (via Platform Builder). Only "correct way" of developing anything for it afterwards is to use the SDK the manufacturer usually provides. Right? In my case, the SDK is extremely limited and tightly integrated into IDE as noted above. However, .NET CF 3.5 is capable for interop so its possible to call native libraries -as long as they are compiled for correct platform.
Compiled code is pretty much just instructions for the processor (assembler code) and the compiler chooses the correct instructions based on the target processor setting. Also there's the PE-header that defines under which platform the program is meant to be run. If I target my "helloworld.exe" (does nothing but returns specific exit code) to x86 and compile it with VC, should it work?
If the PE-header is in fact the problem, is it possible to setup for WINCE without the SDK? Do I REALLY need the whole SDK for creating a simple executable that uses only base types? I'm using VS2010, which doesn't even support smart device dev anymore and I'd hate to downgrade just for testing purposes.
Above questions are prequel to my actual idea: Porting ffmpeg/ffdshow for WinCE. This actually already exists, but not targeted nor built for Intel Atom. Comments?
If the native implementation is not possible and I would end up implementing some specific codec with C#...well that would probably be quite a massive task. But having to choose C# over native, could I run into problems with codec performance? I mean.. is C# THAT much slower?
Thank you.
I've not seen an OEM that shipped their own IDE, but it's certainly possible. That shouldn't change how apps can created, however. It's possible that they've done a lot of work to make sure only things from their IDE work, but that would be a serious amount of work for not that much benefit, so I'd think it's unlikely.
As for your specific questions:
The OS is Windows CE, not "based on" it. The OS is, however, componentized, so not all pieces are going to be available. An SDK generally provides a mechanism to filter out what isn't available. You can actually use any SDK that targets the right processor architecture, but if your app calls into a library for something that isn't in the OS, then you'll get at the very least an error. For managed code this is all not relevant because the CF isn't componentized. If it's there, and CF app can run (and if it's not, you can often install it after the fact). This means that if the platform supports the CF, then you can write a CF app and run it. That app can then call native stuff via P/Invoke (unless, of course, the OS creator decided to add security to prevent that. This is possible in the OS, though I've never seen it implemented).
Yes, compiled code is just "instructions". For native, yes, they are processor instructions. For managed, they are MSIL instructions that the managed runtime in turn converts to processor instructions at JIT time. If your target is an ARM platform, you cannot use an x86 compiler. Broadly speaking, you need to use the correct Microsoft compiler that support Windows CE, and call that compiler with the proper switches to tell it not only the processor architecture, but also the target OS because the linking that needs to be done will be different for OS-level APIs and even the C runtimes. The short of this is that for your platform, you need to use Visual Studio 2008 Pro.
For native apps, you need some SDK that targets the same OS version (CE 6.0) and processor architecture (e.g. ARMv4I). Having it match the OS feature set is also useful but not a requirement. For managed code, you can just use the SDKs that ship with Studio because managed code is not processor-dependent. Still, you have to go back to Studio 2008 because 2010 doesn't have any WinCE compilers.
If you've found an existing library, then you can try to use it. Things that might impede your progress are A) it's unlikely to use an SDK you have so you probably have to create new project files (painful, but workable) and B) if it uses features not available in your OS, then you'd have to work around those. If you're missing OS features, you're probably out of luck but if it already has a media player and codec, I suspect you'll be ok.
Don't implement this in managed code. Seriously, just don't do it. Could you? Yes. Performance could probably be made to be nearly the same except to avoid GC stuttering you're going to have to basically create your own memory manager. The amount of work involved in this path is very, very large.
As SO returns "4,476 search results for posts containing "win32 gui applications""... I'll have to ask a question that has probably been asked before but is lost in the midst of all those questions.
Currently, what are the options to write GUI applications for Win32, that have a big-enough following so that the environment offers enough and well-supported third-party tools?
I could come up with:
C++
Delphi, and possibly
RealBasic (although the fact that it's originally a Macintosh tool could result in small but noticeable issues in look 'n feel).
Besides their relative lack of well-supported third-party tools, solutions like Python + wxWidgets, or [Power|Pure|Free]Basic aren't good options: The former has too many 1.0 widgets (couldn't find a business-grade grid, for instance), and the latter are procedural languages so requires writing apps like Petzold's book with the lower productivity it entails.
Are there other solutions available?
Thank you.
Edit: Sorry for not having been precise enough: Big tools like .Net and Java are not options. I'm looking for tools that can either build a whole EXE statically (eg. Delphi) or provide a light enough runtime (VBClassic).
If you are new to programming I would suggest C# as well if you are only looking to make this app for the Windows Platform however with tools like Mono it can be ported to OS X and Linux Platforms.
Windows has their own IDE just for this called Visual Studio Express C#
Visual Studio's C#
As well as a version for C++ if you are wanting to say in that programming language.
The Mono project allows you to use C# in Linux and Mac as well as port the apps to iOS and Android
http://www.mono-project.com/Main_Page
You Can use C++ or You can even use the .net framework to develop your windows applications. .Net framework have lots of opensource contributed modules and paid modules and well as number of resources all over the internet to speed up the development compare to other options you have mentioned.
If you are going for a windows 32 gui application, I would prefer to go with .net framework, C++.
Java Swings also another best options which is platform independent as well.
You can use Lazarus as a free alternative to Delphi. Potentially you will have a very high possibility to check its "write once, compile anywhere" motto if you later decide to port your Win32 application to Linux or MacOS. In ideal case it will just work, but in reality you would probably need some conditional defines sections.
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
I have a few years of experience writing Unix command line tools (no GUI experience) in python, C and C++, and only recently crossed into the GUI world (Cocoa and IOS only). I've learned quite a bit of objective-C and am getting to understand how cocoa MVC works. However, one of the apps I am developing needs a Windows version and I was wondering what a good place to start would be given that I have absolutely no Windows development experience.
I was thinking about using Visual C++ 2010 Express as my development platform (because it's free and because I don't need to learn C++). My application is relatively simple, it will have only two windows and spend most of the time running in the background. It will however need to communicate with the OS (load dll's etc) and an online server (HTTP methods) and I'm not sure whether Visual C++ Express edition gives me access to the required API's. Would a Windows Forms application suffice? Am I going about this the wrong way? Do I need to learn C#? Any advice will be appreciated.
If you are already happy with proper c++, visual Studio C++ express should suit you fine. Given that you are not making a complicated GUI, you don't even need to dip into the managed code - C++ express allows you to create proper c++ console and GUI apps. You also don't need to install the platform SDK - it is part of VS C++ express.
Not being managed C++, you will be able to share source files between your various projects. managed c++, despite the c++ in the name, really is a different enough language that it will be annoying to work with if you simultaneously have to deal with iso C++.
--
Note: The native windows API is a C api, not a C++ framework. So it does not provide a rich set of classes in a coherent framework to deal with. On the other hand, while, large, it is actually quite simple to work with.
Also: Given that you are already familiar with Mac development, there is a LGPL (iirc) package called CFLite that builds on windows and that implements the C api that underlays the Objective-C Cocoa API.
If you use its abstratcions you can share a greater part of code between windows and Mac (and other platforms).
Other C++ IDE's you might want to consider:
Code::Blocks
QT Creator
both of which can be configured to use the MINGW port of GCC to windows.
you'll be better off with c++ than c# if you need more "low-level" stuff. Loading dlls (that is, libs) is simple (pragma comment lib...), as is pure HTTP transfer and communication.
So, VC++ with windows form will suffice, and it is "very c++".
You have access to all global APIs, and loading specific apis like http requires only two lines: one to include wininet header, and other lib (libs are actually "references" to dlls).
If you go the C++ Express way then you need to install Windows SDK separately, and set it up for Visual Studio to use it. And you can't use MFC.
I would however, suggest C#, because it feels like putting little toy bricks together. Easier to debug and maintain. Problem with C# is that it has so many library functions that you can not possibly know if what you want is already made to a function. But that's why we are here :-) If you feel that something you want to do should already exist then ask a question about it. One notable feature that C# lacks is zip archives (it has something similar, but not quite). For zips you can use public libraries, like SharpZipLib or DotNetZip.
If I were you, I wouldn't jump into a whole new API so quickly. Have you considered using Python on Windows? Most of the Python packages I've seen are also available for Windows, so you'll feel at home. And if you need some GUI, you can opt for wxPython, pyGTK or something similar.
For Windows specific things, you can always use ctypes. Especially if they're as simple as loading a DLL.
have you considered approaching Adobe AIR? it allows you to deploy on Mac, Linux, Windows, iOS, etc. communicating with and launching native processes has been possible since 2.0 and the the latest 2.5 SDK can target Android OS and TVs. with your experience you should be able to pick up ActionScript3 / MXML in no time.
additionally, there are a handful of free IDEs you can use with the Flex and AIR SDKs. or, if you're a student or low-income developer, you can get a free copy of Flash Builder 4 from Adobe: http://www.adobe.com/devnet-archive/flex/free/
edit: i believe deploying AIR applications on iPhone requires Flash Professional CS5, which includes the packager for iPhone options. at the same time, i've read that AIR and other cross-compilers for iOS are painfully slow, so it's perhaps best to develop natively in Objective-C for iOS.
What is the best programming language for writing MIDI-interactive musical application that would be run on MAC and on Windows?
I've written cross platform (Mac OS X and Windows) MIDI applications using C++. I used the RtMidi for MIDI I/O which was incredibly easy to get going (on every platform just it just worked out of the box). The advantage of C++ is that you can use native GUIs on each platform, but if you're not already into C++ I'd say a cross platform project is a pretty ambitious first project.
One possibility is .NET (C# or VB.Net), which runs on Windows (of course) and Mac (thanks to Mono). The downside is that .NET does not have any native support for MIDI, so you'd have to tap into two different native APIs for MIDI.
Java is another possibility, since it has a number of MIDI-supporting libraries available. Your UI is bound to look pretty terrible, though.
Python has substantial support for MIDI and runs on Mac and Win.
pygame.midi
PyPortMidi
PythonMIDI
pyrtmidi
For both mac and windows I would suggest Java. Midi is just a protocol so any language can do it. A good framework will speed things up a lot. Java has frameworks to work with Midi and other multimedia sources.
PortMidi is another popular cross-platform MIDI library. Qt is a nice cross-platform Framework, GUI and utility library.
It's an old thread, but nowdays you can use .NET. I mean official cross-platform .NET from Microsoft, not Mono. In this case I can recommend my library – DryWetMIDI. Its core part (working with MIDI files, processing MIDI data and so on) is cross-platform for any OS supported by .NET.
As for working with MIDI devices, this API supports Windows and macOS (that's what you need). Full documentation of the library availabale here: https://melanchall.github.io/drywetmidi. There you can find full API reference and help articles. For example, overview article on working with MIDI devices.
The library is distributed via NuGet package and can be installed via NuGet on both Windows and macOS.