So far, I've used many different Audio Production software on Mac and Windows platforms. Often times, I ponder on the idea of creating my own DAW, but I realize that would be an extremely difficult challenge for a single person to undertake (especially if only knowledgeable in one particular area / language of programming).
There's a flood of ideas / features that comes to my mind just by the thought of some of the other DAWs I've used. From implementing MIDI in/out, Audio Routing, Mix Buses, VST support, User Interface for a Piano Roll and Song view, etc...
So my question is...
Which roles would be required in a team of developers to create a complete Digital Audio Workstation (DAW) Software?
I think the right answer is several good developers (you don't need so many, perhaps 3) a good product manager, an ui designer/graphist a lot of testers. And a good coffee machine.
The real problem is what kind of DAW do you want, portable on mac and windows, which OSs, which formats (vst 2, 3, AU, RTAS, AAX, rack extension, DX), do you want only MIDI and adio tracks, which external MIDI devices you want to support, do you support OSC, other protocols?
What will be the features of you mixer, integrated effects? What support of audio API on windows (wasapi, asio ...) do you want some cloud feature ? community or online store integration?
What kind of breakthrough would you have compared to cubase, live, PT, DP, Logic, garage band, bitwig, studio one, sonar, fl studio ...? Do you want modular patches or just tracks? Will you have advanced integrated controls or midi modifiers?
All that is the problem...
This is a very complex question!
Related
An article on Hackaday piqued my curiosity, and I see Kinect + Linux questions being asked here (mostly about configuration), so I'll venture this question:
It is clear to me that Kinect can be used together with Linux on a "regular pc" -- but I can't help wondering why, that is, what might you actually use this for?
I don't suppose people really like the human/computer interface presented in movies such as "Minority Report" -- surely, nobody is actually doing text editing, coding, or business data processing by "hand-waving". So besides just games & exercises, what are examples of actual, real-world, useful (ie. 'professional') applications of such a setup?
For instance, can it be used for 3D scanning of real-world objects to obtain digital models? What sort of accuracy would such a scan yield?
The Kinect can be used for a wide variety of useful applications. I'm not sure if you are asking specifically about Linux or if Windows ("regular PC") is acceptable, but I'll provide you with some examples that come to mind.
For Linux specifically, it is likely that applications on Linux are using the sensor's raw sensor data only, rather the skeletal tracking feature. Many Kinect applications are on Windows because Microsoft's Kinect SDK is available only on Windows, and it provides the best skeletal tracking accuracy to-date.
You are right that the Kinect is rarely used where a keyboard & mouse would be faster and more accurate, but note that it is potentially relevant for accessibility.
And yes, it can be used for 3D scanning of real-world objects. I'm not sure about the exact accuracy, but I think it is acceptable for many applications. The main benefits are its low cost and speed.
For examples of 3D scanning, check out:
KinectFusion, a Microsoft Research project
Occipital Structure sensor for 3D scanning. (This is not the Kinect sensor, but provides an example application for 3D scanning. The company has a Kinect-related history as well.)
Styku - 3D body scanning for clothes fitting
Aside from 3D scanning, here are some other examples of applications:
Atlas5D - at-home patient monitoring
GestSure - 'Minority Report' interface for surgical rooms
Jintronix - games, exercises, assessments for physical therapy
There are many depth sensors like the Kinect3D on the market. The latest notable application would be iPhone X's depth sensor and FaceID. Many companies in the space are working actively in FaceID now, which would also be useful on Linux. Check out Microsoft's Window Hello biometric facial ID system - see Microsoft's official website:
Manufacturing of the Kinect sensor and adapter has been discontinued,
but the Kinect technology continues to live on in products like the
HoloLens, Cortana voice assistant, the Windows Hello biometric facial
ID system, and a context-aware user interface.
Kinect has applications in the robotics community as well, though I don't know the specifics. I assume many in robotics community use Linux when working with the Kinect. The depth and color cameras can be used to provide vision and the microphone array for audio input.
Generally, the Kinect had a big impact when it was released not just because of its technology but also because of its low price point, even if it's not the most accurate for every application. As this technology improves, I hope many other applications will emerge and become mainstream.
EDIT: also, check out this Hacker News discussion: "Microsoft Has Stopped Manufacturing The Kinect"
I am aware of two cross-platform audio libraries that cover OS X, Windows and Linux: RTAudio and PortAudio
I'm aware of a couple that support OS X and iOS: Novocaine and TAAE
However, I can't find anything that supports OS X, Windows and Linux and also iOS, Android
Does such a technology exist?
Un4seen's BASS audio library claims to do what you want. I've only used it on Windows, but there is a lot of chatter about it for Android an iOS, as well as the desktop platforms.
http://www.un4seen.com/
It's free for non-commercial use, otherwise the licensing is pretty decently priced in my opinion.
(https://www.juce.com/)(JUCE) was my choice in the end.
It is a C++ platform with a focus on real-time audio. I don't know how I missed it in the original question.
JUCE has gone from strength to strength over the past few years. Recently they have reorganised the licensing model so as to encourage independent/indie developers.
Don't want to sound too much like an advert, but I'm very happy with this technology stack.
I wonder; does audio software like Cubase and Audacity use PlaySound calls??
Where can I learn about low level audio programming? As far as I've found information on the web, MCI seems to be the lowest level audio API in Windows...
Thanks
Edit: I don't ask for information specific for Windows only.
There's several audio APIs to choose from. The oldest and most widely supported is the waveOut API - look for functions starting with waveOut in MSDN. A slightly newer one is DirectSound which is geared more towards games, but it's main feature over waveOut is positional 3D sound which professional audio software doesn't use (it was also supposed to have lower latency than waveOut, but that never really materialized). For low latency audio, there is ASIO. Professional audio apps support this API, but not all drivers do (it's a standard feature in professional sound cards, but not gaming or on-board hardware). ASIO can provide much lower latency than waveOut or DirectSound. Finally, there's the kernel streaming interface, which is the lowest-level audio interface still accessible from user-mode code. This is a direct pipe into Windows's internal mixer which combines output from all apps that are currently playing sound into the signal that gets sent to the sound card. It's scarcely documented though. There's a driver called ASIO4ALL (just google it) that provides ASIO support on soundcards without ASIO drivers by implementing the ASIO API on top of the kernel streaming interface.
I'm a little late to the game here, but I posted a Windows API history last week that might add a little more context. The choice of API really depends on your needs. If you want to avoid 3rd party libraries, it really only comes down to MME, XAudio2, and Core Audio (WASAPI).
A Brief History of Windows Audio APIs
Hope this helps!
Actually, if you are looking for more than Windows-only output support, then the best way to start is to review Phil Burk's PortAudio, available as of this writing at http://www.portaudio.com/ .
ASIO is a good quality interface, but it's proprietary and owned by Steinberg.
There are many lower-level interfaces to audio output than MCI in modern Windows. These include, at least, DirectSound, XAudio and WASAPI.
I recommend avoiding the Windows APIs as much as possible, and learning PortAudio instead.
I have very easy question, but I simply have any idea of the answer.
I have developed a small mobile-application using java, for my nokia.
The problem is that when installed on my samsung the application simply crashed.
Then I tried on my other nokia but different model, and I didn't got the normal behavior.
So my question is, does anyone have any idea how companies that develop mobiles applications/games test their software.
Does they have to have all models for all mobiles phones??
Companies that target many phones in many countries usually only let you install the application on your phone if they recognise your handset User Agent in the HTTP headers of the request to download the .jad or .jar file.
There are multiple ways to test an application on many handsets for many mobile network operators.
From simply buying the phones, to establishing commercial parternships with handset manufacturers and mobile network operators, to having a Device Anywhere account.
I don't know if you need all models of all phones. But you will definitely need separate test (and probably different builds) for different phones regarding:
MIDP version
Screen Size
Input Devices
Speed & Memory
Java, in this case is, WOTA (Write Once Test Anywhere) instead of WORA (Write Once Run Anywhere). :-)
Phone specs and Java implementations vary a lot, but within each manufacturers range there will be groups of phones that share the same specs and implementation.
I used to work at a company making J2ME games, what we did there was test on every handset we released the game on, but we had 2 types of test - Complete and Compatability.
We would adapt a version of the game for a specific phone, eg Sony Erricson K800i, and have it thoroughly tested according to the Complete Test spec.
Once that had passed, we then used that build on phone known to have similar specs and good previous compatability with other games (we kept a database of specs and compatability records), eg Sony Erricson W910i, and submit it for a compatability test, which was a bit less thorough and a bit quicker.
Once you've been doing it a while you get to know the capabilities of phones and which phones you could use the same build on, but there is often a bit of guesswork involved :) Sometimes you get matches you wouldn't expect, and sometimes a match you would expect to work doesn't.
Edit: I was going to post this as a comment, but I can't (because i'm an SO noob :), out of interest, what phones are your Nokia's and Samsung?
I can't remember many specific handset names, but here is a quick rundown of compatability across manufacturers:
Sony Erricsons are generally excellent - if it works on one, it will likely work on all SE handsets with the same resolution.
Nokia's are generally good within a certain smaller group eg N95 builds work well on most nokias with the same res that were released after the N95, but some handsets are a bit of a pain.
Samsungs are pretty bad - the J2ME implementation on most is flawed (Hide/Show Notify methods not being called is an example), and the memory and speed are typicly a bit crap.
Motorola phones are not great, but are generally quite compatable with oneanother. Same goes for LG, although their more recent models are much better.
Testing is one of the most labour intensive part of mobile phone development. Typically a company might simply buy a lot of different phones to test on for real, or target a particular subset such only as Series 40 Nokia phones.
But alternatives exist out there where you can remotely deploy your app to phones, such as Nokia's Remote Device Access Services.
One way that might limit the problems is to target J2ME MSA (Mobile Service Architecture) compliant phones, where MSA attempts to reduce variations in vendor implementations of J2ME.
which API or library on which mobile OS is to be used when one needs to write a code to use the phone's IrDA to create the necessary impulses to remote control consumer electronics e.g. a HDD media player?
Is maybe a certain mobile OS better suited for that kind of application than others?
First you need to know that IrDA is not the best choice for remote control. It can be done, but IrDA is by design high speed/low range, you can emulate low speeds but ranges (IMO) are far from practical usage (Nokia e50 is able to control digital camera shutter from 2-3m... with very, very careful aiming). The amount of hacking needed to achieve this is shown here, you basically need to trick IrDA to send correct impulses with correct frequency.
The second thing is that CIR remote control is not as simple as you might think. There are countless standards that differ in used frequency, modulation, wavelength, command codes and so on. You need to know what you want to support. LIRC site can be very helpful in determining that http://lirc.sourceforge.net/remotes/. Approachable explanation of what it all means is available here: http://www.sbprojects.com/knowledge/ir/ir.htm
As for ready made libraries and platforms... I honestly don't know. I've seen it done on PocketPC (nevo among others) and Symbian S60 (irRemote). Haven't seen working J2ME app yet.
Last time I needed the IR remote I hacked it together using IR diode, AVR ATTiny and surprisingly short piece of assembly :)