I am trying to port my screensaver from windows to mac and one of its features was reacting on system sound output. On windows it was easy using Direct Sound, but I can't find any example of capturing sound output on mac. Is it possible even possible without writing something like kernel extension? Using flash it is also very easy — it even gives computeSpectrum method to get raw data or even fft transformed data.
All programs that I have already found use Soundflower or their own kernel extension. But I don't think that asking to install separate program or using kernel extension is a good way.
One thing you can do, considering that Soundflower is open source, is take a look at how they did it. You can't copy & paste GPL code, but you can surely study the techniques used and create your own solution (point you in the right direction).
You won't find Apple being very helpful here. Sound capturing, in this manner, can be used for all kinds of nefarious purposes. I'm not even sure if Core Audio lets you do this without hacks. In any case, you have a working implementation of what you're trying to accomplish. I'd take advantage of it.
I'm not on my Mac right now, but I'm pretty sure that Quartz Composer has a patch for just this thing. Depending on what language you're writing your screen saver in, it may be fairly easy for you to port your code into a QC patch. Well... it probably won't be easy, but it may be doable.
Related
I am interested in writing a small utility to modify all audio output on OS X. I essentially want to apply a certain effect to the sound systemwide and/or via individual applications (similar to how Prosoft Hear operates).
Where would I start digging in order to accomplish this? Is this done through CoreAudio or are there other more direct option?
Core Audio plugins can achieve all sorts of things, those are probably your best bet. I notice you used the kext tag - it's of course possible to do this in the kernel, but that seems overkill.
I'm wanting to port a windows program I'm working on to linux. It entirely uses d3d11 to draw it output so I'll need to write an opengl alternative. That's fine. But I need to create a window and a few basic operations like resizing, setting fullscreen, getting notified of user keyboard and mouse input, and close and resize notification.
I won't require any child windows, or controls as everything is drawn by opengl.
So what is an appropriate way to do this? I looked at raw Xlib but it seems quite low level. I'm prepared to learn it but all the examples seem really old so I'm not sure if it's still the best way, plus will doing that work with whatever environment the user had (kde, gnome etc...)?
I could use qt, kde etc, but they are far, far more sophisiticated than I need for this so introduce a large dependency that I'd rather avoid if possible.
So, is Xlib an appropriate technology for this, or is there some other lightweight library I'm not aware of?
Look at SDL. It's pretty much the standard choice for applications like yours.
It looks like GLUT could suit your needs.
Would be usefull to see how things work but not sure on the legality of it
Most Mac apps are written using Cocoa in Objective-C; which, while it is a compiled language, means that there is a fair bit of information left over that could be used by a decompiler.
I'm not sure if there are a lot of decompilers out there that leverages this information, at least I haven't heard of any.
However, there are also another option; F-Script.
F-Script can be used to attach to an executable and explore its interfaces, while not as good as source, it can give you a pretty clear idea of how the executable is built, and how it operates.
As for the legality issue:
IANAL, but as far as I know, reverse-engineering for the purposes of compatibility is legal in many jurisdictions, and I can't imagine that decompiling an executable to look at its code is illegal, unless the specific EULA specifically prohibits it.
Edit: WRT Steam specifically, it is probably NOT written in Cocoa, but C# with some manner of .NET compatibility layer; and it's probably not a good place to start if you want to learn how to make applications for Mac OS X.
By far, the best Mac OS X disassembler I've used is Hopper available here:
http://www.hopperapp.com/
It will also convert the assembly to C pseudo code as best it can. It will generate code flow diagrams with blue lines (true blue, love it) for true and red for false paths.
It's The Mac OS reverse engineering tool. There are even Youtube videos that will show you how to use it.
If it's an open-source app, yes. Otherwise it's possible through decompilation but the output will be a real pain in the ass to look at. If you just want the protocols and the interfaces of categories and classes, have a look at class-dump.
I'm not aware of a nib decompiler.
Whether decompilation is legal: ask a lawyer. This may (and probably does) differ per jurisdiction.
Is it possible to view the source of a mac app?
Realistically, no. Sure, you might be a able to use a decompiler to get a peek, but the kind of output you'll get won't be easy to read. If you're asking this question, this route probably isn't going to be helpful to you.
Specifically interested in GUI and how the steam app for mac works
It's a good bet that it works about the same way that most other applications work. It might use custom controls to look different from a typical application that mostly uses the standard Cocoa controls. But underneath, just about any GUI application written for MacOS X will use the run loops, responder chain, and view hierarchy that Cocoa provide. The main exceptions would be applications that are built mostly using an alternate framework like OpenGL or WebKit.
Figure out what, specifically, the Steam application does that you'd like to do. Take a look at the tools that Cocoa provides to see if you can figure it out yourself; if not, ask about it here.
So I'm looking to build an application that will be able to record the users screen and stream it at the same time. I would like the application to run on both Windows and OSX. I don't have a high level of programming experience in any language, just basic understanding in C, C++, JS, (funny how each class you take in college wants a different language). I'm also pretty well versed in HTML and CSS but that is kind of irrelevant for this topic.
I've been looking around and it looks like the best solution is going to be writing the core of the program in one language, and then developing the Interface side for each platform differently, using appropriate languages and bindings for the different platforms (Objective-C and Cocoa for OSX and so forth).
I'm open to all suggestions, this project doesn't have a deadline or anything, I'm really just intending it as a learning experience. I've never done anything with video capture and streaming before, so I'm looking for suggestions as to which road to go down language-wise for this project.
Thanks in advance :)
the simplest solution that comes to my mind is to use VLC.
this is obviously not a "language" but an application, but it supports screen-capture and streaming on all of your target platforms (and more).
if this is not an option (e.g. because you don't want a separate application), you could use VLC's C-api for acquiring screen capture and use whatever you like for streaming.
if you want to only rely on native functionality, i would use C/C++ for the application and write the OSX part in ObjC/ObjC++ and Cocoa.
Can anyone tell me about using (Steel Bank) Common Lisp for writing GUIs via system calls? I know there are some libraries out there but this is a language learning exercise, so I want to do it myself.
I'm developing on Kubuntu 8.10 and SBCL 1.0.18.
Thanks.
You can take a closer look at the sb-posix-package. But as the page sais "The functionality contained in the package SB-UNIX is for SBCL internal use only; its contents are likely to change from version to version."
Another Possibility - the one I would choose - is to include the C-syscall(2)-Instruction via CFFI, and then perform it.
To create a windowed GUI, you must use X11, at least to give you a Window to paint on. Therefore, you must know the X11-Specifications to create a window, and implement the Syscalls for accessing Unix Domain Sockets, or initiating shm-devices etc.
If you just want graphics on a console, you could think of using the framebuffer-device /dev/fb*. You need ioctl(2)'s and the syscalls for read(2)ing and write(2)ing to use it, but still, I think this would be a lot easier than using X11 for this (even though still a lot of work). Maybe you shoudld look at the sourcecode for libFB or something similar to see how to initialize it, etc.
Is this really what you want to do? This is a lot of work, you will learn a lot, but more about the linux system infrastructure, rather than about SBCL, I think. If you want to use Syscalls under SBCL, maybe its better to try to open TCP-Sockets only with Linux-Syscalls - alone this can take hours of frustration.
By writing GUI via system calls you mean not using any GUI toolkit such as Gtk+ or Qt? In such case, you should talk directly to the X-server via socket and implement all the X11 protocol (or use CLX) and GUI on top of it. But that is not an easisest task, because X11 is complex.
In case you decide to dig into X11, there are some links for specifications: http://www.xfree86.org/current/specindex.html
http://www.freedesktop.org/wiki/Specifications?action=show&redirect=Standards