In my keyboard I have some keys to play, pause, play next.... to control the music. I would like to know how this is done under the hood. Is it some sort of API in the operating system that passes the information on to the music player? Is the player reading for pressed keys and reacting to them?
Is there a unified way to control music players?
I will try to stay platform independent where I can, however, at some point I will have to strive to Windows.
First it is important that you understand what happens when you press a key; this page from Microsoft describes exactly the information I am about to summarize in this section. When you press a key, your keyboard generates a scan-code which uniquely identifies your pressed key. However, these scan-codes are keyboard-dependent and you will as good as never work directly with them. Windows, the OS, will translate the scan-codes to virtual-key-codes. Virtual-key-codes are OS-specific codes which resemble their respective scan-codes; virtual-key-codes are what you will usually, in the lowest level, be working with. I should also note that some virtual-key-codes are usually irrelevant to the programmer - such would be keys like "ctrl" which are used for OS commands.
The API for windows can be found in the above link, too, but as far as I know it is for C++; I do not know about Ruby itself.
Now, to your second question, whether the players reads for pressed keys and reacts to them. I am about to present a common principal that is used with keys, buttons, etc., in software design - the actual implementation of the Media Player is a different question. User inputs, which fully require user interaction, are usually implemented with the Oberserver-Oberservable pattern in object-oriented design; the following link explains this pattern for ruby.
In our case, we would have a KeyboardListener acting as Oberservable; it will 'request' from the OS that it would like to be informed when a key is pressed. As well, let us have a MusicManager which is capable of causing music to be player, paused, etc - it acts as Overserver. When a key is pressed the KeyboardListener instantiates an object containing information about what type of key was pressed and passes it to the MusicManager. This would be what happend under the hood, according to this implementation:
Press pause button
The OS informs the KeyboardListener that pause button was pressed
KeyboardListener creates an event containing what button was pressed and passes it to the MusicManager
MusicManager determines the cause of action
So why don't we just skip step 2 and go directly to 3? There are several reasons to do so but I will only provide one - it allows the software to be designed in a platform independent, maintainable way. The only code that has to be adopted will be the KeyboardListeners'; it will only need to alter its code on how it 'requests' the OS to be informed. Thus we will have a WindowsKeyboardListener, LinuxKeyboardListener, etc. Which particular Listener will actually be used is dependent upon the runtime environment.
Related
As soon as you hit "Play" what happens in the background of the software? The code is already compiled and ready at this point. So when I press "Play" the code gets executed. What other things occur along with this?
I have this question as an assignment and would really like to know. Thanks. :)
Actually everything is loaded by script. This graph explains the process. Also the links below can be useful for you to understand all the background process.
Execution Order of Event Functions
Overview: Script compilation
Asking what happens when you press Play is like asking Coke to reveal the drink recipe. This is what they sell. You got that as assignment, fact is you can say anything and your teacher would lie to tell you wrong, since he does not know either (except if he works for a company that bought the source code of the engine).
What you can say, is that the OpenGl/DirectX API is initialised, registration of all event to the OS like Input, application data and so on, then all the Engine functioning, registering of the needed classes in memory, init of the physics, parsing of the opening scene YAML file, creation of the content and placement in space, for each item, if a MonoBehaviour, registration of all callbacks, all the debug code related to profiler and stack tracing, crash reports and many more...
Those are the obvious ones and I cannot have any clue of what is going on without using a tool to decompose the code. Problem, it is against the EULA and then illegal.
I have been attempting to change which audio device my computer sends sound to. My end goal is to create a program that can make my laptop output to its built-in speakers even when headphones are plugged into the headphone jack.
I stumbled across this project, but the methods it uses (specifically AudioHardwareSetProperty) are deprecated. It also just doesn't work (it will say it changed the output device, but sound will still go to my headphones).
CoreAudio seems very poorly documented and I could not find ANY code online that did not use that function. I would go with the deprecated function if it did what I wanted, but it doesn't. I'm unsure weather it's broken or just doesn't do what I think it does, but that really doesn't matter in the end.
I attempted to look at the comments on AudioHardwareSetProperty but all I found was this in the discussion section:
Note that the value of the property should not be considered changed until the
HAL has called the listeners as many properties values are changed
asynchronously. Also note that the same functionality is provided by the
function AudioObjectGetPropertyData().
This is obviously not true, since I know for a fact that AudioObjectGetPropertyData is used for getting information about one specific audio device.
Is what I am trying to do possible with CoreAudio?
I'm writing an OS X launch agent (which watches, as it happens, for FSEvents);
it therefore has no UI and is not started from a bundle – it's just a program.
The relevant documentation and sample
code
illustrates persisting FS event IDs between invocations, and does so using
NSUserDefaults. This is clear the Right Thing To Do(TM).
The documentation for NSUserDefaults in the
Preferences and Settings Programming Guide
would appear to be the appropriate thing to read.
This shows only the Application and Global domains as being persistent, but (fairly
obviously) only the Application domain is writable for an application. However
the preferences in the application domain are keyed on the
ApplicationBundleIdentifier, which a launch agent won't have. So I'm at a loss
how such an agent should persist state.
All I can think of is that the Label in the launchd job can act as the
ApplicationBundleIdentifier – it at least has the correct form. But I can't see any
hint that that's correct, in the documentation.
The obvious (unix-normal) thing to do would be to write to a dot-file
in $HOME, but that's presumably not the Cocoa Way. Google searches
on 'osx daemon preferences', and the like, don't show up anything useful,
or else my google-fu is sadly lacking today. Googling for 'set application
bundle identifier' doesn't turn up anything likely, either.
NSUserDefaults:persistentDomainForName looks like it should be relevant,
but I can't work out its intentions from its method documentation.
I've found one question here which seems relevant, but while it's tantalisingly close, it doesn't say where the daemon gets its identifier from.
I've limited experience with Objective-C and Cocoa, which means that by
now I rather suspect I'm barking up the wrong tree, but don't really know where
to look next.
You can (and imo should) have an Info.plist even in a single-file executable.(see http://www.red-sweater.com/blog/2083/the-power-of-plist)
However, NSUserDefaults is a little more questionable. Conceptually, it's intended for user settings, rather than internal state. However, there's no real reason it wouldn't be suited to this, so I'd probably go ahead and do so.
Sometimes when looking at someone else's large Objective-C program, it is hard to know where to begin.
In such situations, I think it would be helpful to log every call to every non-Apple method.
Is there a way to do that? Basically, make one change in some central place, and log every method that is called. Preferably limited to non-Apple methods.
You can set the environment variable NSObjCMessageLoggingEnabled to YES. This will write a log of all message sends in the folder /tmp/msgSends-xxx.
You could add a symbolic breakpoint to objc_msgSend(), and have it log the second parameter without stopping.
How to do it for your own methods only though is a toucher task. Maybe if you could inspect the class name being called and do some magic to have a conditional breakpoint for only calls where the class' prefix matches your own?
I don't think logging every single call is practical enough to be useful, but here's a suggestion in that direction.
On a side note, if it's a large program, it better have some kind of documentation or an intro comment for people to get started with the code.
In any case, every Cocoa application has an applicationDidFinishLaunching... method. It's a good place to start from. Some apps also have their principal (or 'main window') class defined in the Info.plist file. Both these things might give you a hint as to what classes (specifically, view controllers) are the most prominent ones and what methods are likely to have long stack-traces while the program is running. Like a game-loop in a game engine, or some other frequently called method. By placing a breakpoint inside such a method and looking at the stack-trace in the debugger, you can get a general idea of what's going on.
If it's a UI-heavy app, looking at its NIB files and classes used in them may also help identify parts of app's functionality you might be looking for.
Another option is to fire up the Time Profiler instrument and check both Hide missing symbols and Hide system libraries checkboxes. This will give you not only a bird's eye view on the methods being called inside the program, but also will pin-point the most often called ones.
By interacting with your program with the Time Profiler recording on, you could also identify different parts of the program's functionality and correlate them with your actions pretty easily.
Instruments allows you to build your own "instruments", which are really just DTrace scripts in disguise. Use the menu option Instrument >> Build New Instrument and select options like which library you'd like to trace, what you'd like to record when you hit particular functions, etc. Go wild!
That's an interesting question. The answer would be more interesting if the solution supported multiple execution threads and there were some sort of call timeline that could report the activity over time (maybe especially with user events plotted in somehow).
I usually fire up the debugger, set a breakpoint at the main entry point (e.g. - applicationDidFinishLaunching:withOptions:) and walk it in the debugger.
On OSX, there are also some command-line tools (e.g. sample and heap) that can provide some insight.
It seems like some kind of integration with instruments could be really cool, but I am not aware of something that does exactly what you're wanting (and I want it now too after thinking about it).
If one were to log a thread number, and call address, and some frame details, it seems like the pieces would be there to plot the call timeline. The logic for figuring out the appropriate library (Apple-provided or third party) should exist in Apple's symbolicatecrash script.
I was wondering if there were equivalents of the above mentioned functions for Linux (X11) - I can't seem to find them.
The Xlib functions you want are XQueryPointer() and XWarpPointer().
I've had issues with these not always returning what one would expect. The XTest extension as mentioned above was able to suit my needs. In particular the library function XTestFakeRelativeMotionEvent() worked well for what I was doing. YMMV.
Letting GetCursorPos apart, what you essentially want to do here is to emulate user input, like motion of the mouse pointer to a given location, or mouse button/keyboard input.
This is not part of the standard X11 API. However, the XTest extension provides this functionality and it should come with every decent X11 implementation out there. Another possibility may be the XTrap extension.
Here is the reference of XTest:
X11 XTEST EXTENSION (PDF)
For GetCursorPos, I don't know of a simple equivalent right now (although I assume it is there). What you can always do, however, is to process motion events, which will tell you where the pointer was moved to, whenever it is moved.