The feature that is missing is to play sound. I'm thinking of calling a system library or a terminal command that would accept the sound name as a parameter.
The goal is to get some sound from, for example, a button click.
PS. I'm using Rebol/view on an iBook G3 with Mac OS X Panther.
Unfortunately the Rebol sound port (sound://) isn't supported on MacOS / OSX.
Two workarounds that come to mind:
1) Basic terminal bell
prin #"^G"
2) call out to a sound tool like afplay
call [afplay %/System/Library/Sounds/Ping.aiff]
Related
I am using Mac OS X 10.11.2. Recently I connected it to another monitor using HDMI. Whenever I turn on my mac, it sounds out to the monitor. How can I fix it sounding out to a earphone? I know where I set the audio output in mac preference. But even if I choose the earphone output, it doesn't work at all. I want to know the permanent way to fix the output to the earphone.
System Preferences > Sound > Output is probably what you're looking for. Pretty sure the device you select here becomes default. You can always check the Show volume in menu bar to change it quickly.
I am using a MacBook Pro, Early 2011 running OS X El Capitan. They re-added the dictation feature which allows constant listening, which I have been using with Applescript (like "Computer, quit" and it runs the script). I would love to expand though.
My question: Where can I find what the computer is interpreting? I want to use the entire phrase, like "Computer, I want to listen to music" and have it search through that phrase for the keyword music (then open iTunes or something). This way, instead of having short commands like "quit" or "shut down" it can interpret sentences. Also, how would I create a program that continues to run in the background, searching for these keywords.
Thank you for the help (I am quite the novice),
rednaxelaf7
BACKGROUND INFORMATION:
I've been trying to detect a button click from Apple headphone. The headphone is connected to MacBook Pro that is running Windows. Its not virtual machine. It is running windows normally with a complete windows driver from Apple through Boot Camp.
The headphone is a standard Apple headphone consisted of three buttons: a volume up, volume down, middle buttons and a Mic.
When I am using Mac Os, If the volume up button is presses on the ear phone, Mac Os would increase its volume by one. It also decreases its volume when the voulume down button is pressed on the ear phone.
Standard ear/headphone uses three conductive pins to receive(L/R speakers only) signals while the apple version is using four conductive pins to receive(L/R speakers) and send(buttons) signals. This headphone was made for iPhone but I was surprised when it worked on Mac Os.
This made me believe that the MacBook Pro hardware is built to support this four conductive pins earphone. It works on Mac Os but NOT on Windows. My goal is to develop a tiny software that will allow the apple headphone to function on Windows running on Apple hardware.
I know how to increase Windows volume using C++ and Win32 API but I am stuck on the part where I actually have to detect the button click from the headphone.
QUESTION:
1) what ways can I detect the Input(button clicks) from the headphone?
It looks like this person here was able to read it. He only did it while running on Mac Os
Detect hardware headphone presses in mac
2) If I compile the code this person got working on Mac OS as a DLL file and then call the function while running Windows, will it work?
3) Do I need to make my own driver to get this to work?
4) The code below is from the link I posted above. What windows API function, class is equivelent to the follwoing Mac Os code below?
id array = [[DDHidDevice allDevices] filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:#"productName == \"Apple Mikey HID Driver\""]];
DDHidDevice *mic = [array count] ? [array objectAtIndex:0] : nil;
// it isn't a keyboard
NSLog(#"%#", mic.primaryUsage);
assert(mic.usage==1 && mic.usagePage==12);
THINGS I'VE TRIED:
1) I tried using GetLastInputInfo() with LASTINPUTINFO from Windows API to sniff any hardware input but failed miserably. It worked on keyboard and mouse but nothing else.
2) I also tried to use RAWINPUTDEVICE to read a low level input from hardware but it only worked on keyboards, mouse and joystick input. It didn't detect the headphone button press.
I am running out of ideas. Anyone got any solution?
NOTE: This is not a duplicate question as I am asking how to do this on Windows not Mac.
I'd like to take a screenshot of a background window given its title.
I know this can be made with screencapture -l idwindow output but unluckily I can't use this method because I'm on a Mac OS X 10.5.8 system so the command screencapture doesn't support the option -l.
Are there other ways to achieve this?
Thanks in advance.
GrabFS looks like a nifty tool that can solve your problem. It basically turns running programs into a file system like structure that lets you grab screenshots of those running programs.
Requires Mac OS X Leopard and MacFUSE. You are on 10.5.8 (Leopard?) so that should work out OK.
I want to be able to call the automator or unix commands like ls from a mono app and ge the results back.
This can be accomplished on windows easily. The question is how is this done on the mac??
caveat: I've never written a char of mono in my life.
I imagine it's a matter of redirecting stdout and firing up a process. this linux forum shows that you can do pretty much that - OSX will behave mostly as a UNIX-like system for you, I reckon.
Oh by the way, if you want to fire up an OSX application, have a dig around inside the ".app" bundle. OSX shows these as a file, but they're actually directories. In the finder you can right-mouse click and "show package contents", or you can open up a terminal / command prompt and cd into them. For instance, you can launch the Automator like this from the terminal:
/Applications/Automator.app/Contents/MacOS/Automator
I don't know if you would want to go down this route, but if you're going to be interfacing with OSX (gui) apps, you might want to look at using Applescript as some "glue" between Mono and the app.