I have an Objective-C application that I'm trying to add a means to record output generated by the application to disk. I've added a Swift bridge to my app and have currently got the epic-looking AudioKit Framework hooked-up.
How might I capture my application's audio output and dump it to disk?
Solutions using AudioKit would be nice, but really anything Swift or Objective-C works.
Ideally, I'd mix different input sources (My app's output, plus default the default system input channel), but whatever.
I'm not convinced this is actually possible in AudioKit. I've searched for hours on this. A while ago, I did have a bit of Objective-C code that did manage to record to disk, but it was kind of laggy and seemed to only record the last few seconds before I closed the recording session.
Related
I'm working on a personal project and i decided to make some kind of theremin but instead of radio frequencies, i want to make it with code.
I found how to make sound with asm on thissite (very helpful).
And i do have a sensor that sends me a certain voltage depending on distance of my hand and i can read it with an application in vb.net(HID).
Now my question is that is it possible to manipulate an .asm file on the run time with vb.net so i can make a sound with asm depending of the value that my sensor is giving me?
i have been looking for some information with Google, but it seems that i'm not typing the right tags.
I am reading a file datafile at the launch of my application.This is just self learning drill.
On apple developers website under the heading Minimize File Access at Launch Time
it says
If you must read a file at launch time, do so only once.
So my question is that is there a standard or preferred way of doing this. At the moment I have an instance varible NSArray and I populate that in - (void)viewDidUnloadand never garbage collect it. Is that good enough ? or Should I be making use of application Object (I am not even sure if it is logical to say this.).
There is no standard way to optimize. But there are some guidelines.
One basic idea of optimization is to do less. E.g. as the advice you cited where the data of a file may be needed at multiple points in your code, it is better to read it from disk once and then distribute a data pointer within your program.
If the file is big enough to cause a stutter when you start your application, i.e. it takes more than 20ms to read and parse the file, you should consider reading the file in a background thread/task and adding a ‘loading…’-state to display to the user.
I'm having a strange issue with my application for Mac OS X. I have a process that runs in a secondary thread. The process repeats a certain action a user-specified number of times in a for loop.
With each iteration of the for loop, there is a string that is initialized with the contents of a strings file. If the content of the strings file equals "YES" then the loop breaks (the file is set to "NO" by default). When the user wants to stop the loop, they hit the "Stop" button which sets the contents of the file to "YES".
This actually works great when I run the application in Xcode and when I export the application as a .app. The problem occurs when I actually turn the application into a pkg and install it. The stop function no longer operates correctly. I'm pretty stumped as to what the issue is. I'm initializing all my references to my file using [NSBundle mainBundle] so I should be referencing the file in my application bundle.
EDIT: I actually decided to switch to checking an atomic BOOL value within the loop that I change when the stop button is pressed. This seems to be a simpler solution for me.
Regular users do not have permission to modify applications installed in the /Application folder for very good security reasons. Also, signed apps (ie, any app sold through the App Store) cannot be modified without invalidating your signed code.
Never, ever, ever rely on the application bundle being modifiable. It's never supposed to be. Always use standard user data folders like "~/Library/Application Support/" or "~/Library/Caches/" for app-related, non-document files.
As to your general approach, repeatedly polling a file - especially in a tight loop - is a lot of disk activity. "Laptop Killah" would be a good name for the app. :-) You should consider changing this approach altogether. If you provide more detail in another question (what you're doing and why) and ask for suggestions, I'm almost positive there'll be a number of better ways that don't chew through your users' battery charge like crack-addled rats in a grocery store.
Also, I'm guessing you never check to see if your file is written successfully. The standard -writeToURL/File:... methods return a BOOL to signal success or failure as well as set an NSError (if you pass a pointer to one) with further details. Get into the habit of not ignoring this. In this case, you might've found your own answer because you'd have known just where your code is breaking. From there, it wouldn't have been a huge leap to figure out why.
I am using visual basic .NET and I want to play a video from a byte array that I have, but without saving it first at the disk. Directly from that array. I tried the directshow lib for a while but didn't managed to find a way to play it. WMP didn't worked either.
Any ideas?
There is no stock component to stream from memory, however the task has more or less good generic solution. A number of files/formats are playable starting from so called File Source (Async) Filter, which is a generic file/data accessor. If you could provide a similar/compatible source filter which streams from memory, it would wokd great and cover a number of formats at a time.
Provided that you are going to have hard time doing it in VB.NET, and in managed code in general, you will perhaps need a third party solution for this. So you might eventually end up with a much easier workaround to save data into temporary file and play it from there.
I have an ANSI C code that is about 10,000 lines long that I am trying to use in an iPhone project. When I compile the code with gcc on the command line, I type the following:
gcc -o myprog -O3 myprog.c
This program reads in large jpeg files and does some fancy processing on them, so I call it with the following
./myprog mypic.jpg
and from the command line, this takes take about 0.1 seconds.
I'm trying to import this code into an iPhone project but I'm not entirely sure how. I was able to get it to compile and run successfully by renaming myprog.c to myprog.h and then calling the functions in the C code from within a generic NSObject class. I added the O3 optimization to the project's Other C Flags. However, when I do this, the code on the simulator takes about 2 seconds to run and on the iPhone about 7 seconds to run which renders an unacceptable user experience.
Any tips on on hoe to get this going would be much appreciated.
It's hard to say for sure where the slowness comes from, or if there is any way around it, but right off the bat you've done something wrong.
You shouldn't have renamed a .c file to a .h file and included it. You should have written a .h (header) file that had the function, variable, and type declarations declared:
myprog.h:
#ifndef MYPROG_H_
#define MYPROG_H_
struct thing {
int a;
int b;
};
extern int woof;
int foo(void * buf, int size);
#endif /* MYPROG_H_ */
Then you should compile the .c file to an object file (or library) and link the main program against that. If you were to have included the .h file that was really just a renamed .c file into more than one source code files it may have resulted in having multiple versions of some data and code in your program.
You'll probably also want to go through and separate out any code in myprog.c that you won't be using in your iPhone program. I'll bet that there is plenty.
As far as why the program is slowing down, this could have to do with myprog being written to make use of some resources that aren't available on the iPhone. The first thing that comes to mind is large amounts of RAM, since many desktop applications are written as though available RAM is infinite, and I could see how some .jpg manipulation code could be written this way. The way to get around this would be to try to rework the algorithm so that it did not load as much of the picture at one time while working on it.
The second thing that come is floating point code. Floating point operations are common in image manipulation code, but often either not available or severely limited in embedded systems. In the case of iPhones they are available, but according to something I heard, their performance is noticeably hampered if you compile your code to thumb rather than regular ARM code. (I've never developed for an iPhone or its particular processor so I don't know for sure, but it is worth looking into).
Another place where things could be slowing down would be if there were some sort of translation between Objective C objects and C structures that you have somehow introduced and is happening a lot more often than it should need to. There are probably other slow downs that could happen because of this, but you might be able to test this theory out by creating a objective C program for your desktop that uses the myprog.c code in a manner similar to the iPhone program's use of it.
Another thing you probably should look into is profiling your iPhone program. Profiling determines (or only helps to determine, in some cases) where the program is spending its time. Knowing this doesn't necessarily tell you that the code that runs the most is bad or that anything about it could be improved, but it does tell you where to look. And sometimes you may look at the results and immediately know that some function that you thought was only going to be called once at the beginning of the program is actually being called repeatedly, which highly suggests that some improvement can be made.
I'm sure that a little searching will turn up how to go about this.