I am successfully using an MTAudioProcessingTap in Swift on MacOS to manipulate my audio routing for both live playback and export. However, the specific routing that should occur at runtime depends on the user's choices. What I would like to be able to do is pass in a pair of Ints to the MTAudioProcessingTapProcessCallback when I create the tap so that I can use a single callback definition that can use those Ints to determine how to do the routing. The problem is that the callback is a C function pointer that can't capture context.
I thought maybe I could use the clientInfo parameter of the MTAudioProcessingTapCallbacks to hold the values I need, but I can't find any documentation on how I can access this parameter from within the MTAudioProcessingTapProcessCallback.
I have 32 possible routing combinations, and unfortunately the only other option I see at this point is declaring 32 separate MTAudioProcessingTapProcessCallbacks, and then selecting which to use when I create the tap. But it would be so much easier for me if I could just have a single MTAudioProcessingTapProcessCallback that makes a simple decision based on passed-in data.
I figured out how it works. In order to access the data inside the clientInfo from within the Process callback:
Inside the MTAudioProcessingTapInitCallback you have to initialize the tapStorageOut with the clientInfo pointer
Inside the Process callback use MTAudioProcessingTapGetStorage(tap) to get that pointer and access the data.
Related
Hey im trying to get an object which is referenced in another script (dictionary).
But when i try to get the object in the start method it seems like the dictionary isnt populated jet.
Error: NullReferenceException: Object reference not set to an instance of an object
If I run this line of code in the update method it works completely fine.
Is there an easy way to let this line run after the dictionary is populated?
Grid Manager Script
Camera Movement Script
Both your code snippets run in Start.
There is no way to predict in which order these two Start messages will be invoked (at least not from the user perspective).
To solve this kind of race conditions (see Order of execution for event functions).
The Awake function is called on all objects in the Scene before any object's Start function is called.
my general thumb-rule is:
Use Awake
to initialize the component itself where it doesn't depend on values
from other components.
E.g. initializing your fields, filling your collections, using GetComponent etc to initialize references (but stop there)
Use Start to then initialize things where you do depend on other components being already initialized.
Like in your case access the collections of the other component
This usually covers most of the cases.
In your case simply converting GridManager.Start to GridManager.Awake should already solve the issue.
Where this is not enough you either can start and tweak the Script Execution Order and basically enforce a certain order in which the event methods get invoked or implement a more complex event based initialization system
Populate the dictionary in Awake() method instead of Start(), then it would be ready by the time you need it in Start() of another script.
I was wondering,
Is there anyway to force writing on a 'Read-Only' Modbus Register?
Does defining a Register as a 'Read-Only' is secure enough or can be bypassed??
Thanks for the answers!
The correct way to define a "read-only" analog variable in Modbus is to map it as an input register. There is no function code defined in Modbus to write to an input register.
For historical reasons, several vendors maps all their variables as holding registers, which are theoretically read/write, i.e, there's a Write Multiple Registers function. Whenever they map a read only variable as a holding register, they must assert that the write functions fail. However, there's no standard exception code for this, as a holding register should be read/write. This is only one of Modbus' idiosyncrasies.
Getting back to your question, if you map your variable as an input register, you can be sure that the protocol will not allow a master to write to it. If, for interoperability issues you map it as a holding register, the protocol will allow the master to use a write funcion to change its value, and it is up to you to block in your device implementation.
I made a question that looked like this before and people didn't understand. I'll try to be more concise and will use a comparison with Ajax used in web applications.
I have the main form. There I have one button that will extract data from a field and send to a second form, a window that will pop up and display the data in a more organized way (A TListBox).
I would like to know if there is a way to on SecondForm.Show to send this data as parameters, like SecondForm.Show(data).
The comparison to Ajax is that when you make an Ajax Call from a html page to the server, you send encapsulated data, the server receives it and works with it.
I want my main form to send the data, the second form to receive the data and use it.
Is it possible? How?
If I were you, I'd add parameters to the form's constructor so that it has all the information it needs from the moment it exists.
constructor TSecondFrom.Create(AOwner: TComponent; AParam1: Integer; const AParam2: string);
begin
inherited Create(AOwner);
// Use or store parameters here
end;
You're welcome to write some other method instead, though, and you can call it Show, if you want. Define it to accept whatever parameters you need, and when you're ready, you can call the inherited zero-argument Show method to make the form appear.
procedure TSecondForm.Show(AParam1: Integer; const AParam2: string);
begin
// Use parameters here.
inherited Show;
end;
Decide in what form to send the data from Main to SecondFrom. For instance in a TStringList. Fill the striglist on the mainform, use it as parameter in SecondForm.Show.
This is the answer from your other question that you deleted. It still applies I believe.
Always prefer passing state in the constructor if that is viable.
Problems with state occur when it changes. Multi-threading is confounded by mutating state. Code that makes copies of state become out of sync if the state changes later.
Objects cannot be used while the constructor is executing. That's the time to mutate state since no other party can see the effects of that mutation. Once the constructor returns the newly minted object to its new owner, it is fully initialized.
It's hard with an OOP style to limit all mutation to constructors. Few, if any, libraries admit that style of coding. However, the more mutation you push into the constructor, the lower the risk of being caught out later.
In reality, for your scenario, I suspect that these risks are minimal. However, as a general principle, initialization during construction is sound and it makes sense to adhere to the principle uniformly.
I know that a block is a reusable chunk of executable code in Objective-C. Is there a reason I shouldn't put that same chunk of code in a function and just called the function when I need that code to run?
It depends on what you're trying to accomplish. One of the cool things about blocks is that they capture local scope. You can achieve the same end result with a function, but you end up having to do something like pass around a context object full of relevant values. With a block, you can do this:
int num1 = 42;
void (^myBlock)(void) = ^{
NSLog(#"num1 is %d", num1);
};
num1 = 0; // Changed after block is created
// Sometime later, in a different scope
myBlock(); // num1 is 42
So simply by using the variable num1, its value at the time myBlock was defined is captured.
From Apple's documentation:
Blocks are a useful alternative to traditional callback functions for
two main reasons:
They allow you to write code at the point of invocation that is
executed later in the context of the method implementation. Blocks are
thus often parameters of framework methods.
They allow access to local variables. Rather than using callbacks
requiring a data structure that embodies all the contextual
information you need to perform an operation, you simply access local
variables directly.
As Brad Larson comments in response to this answer:
Blocks will let you define actions that take place in response to an
event, but rather than have you write a separate method or function,
they allow you to write the handling code right where you set up the
listener for that event. This can save a mess of code and make your
application much more organized.
A good example of which i can give you is of alert view, it will be good if i decided at time of creation of alert view what will happen when i dismiss that instead i write the delegate method and wait for that to call. So it will be much easier to understand and implement and also it provides fast processing.
I want to modify the apple's sample code of auriotouch to generate the waveform from and audio file instead of rendering the waveform from the mic input. I tried to do it, but i am not able to understand where and what changes to make. Can anyone guide me on how it can be achieved.
Thanks,
Look inside the render callback for a function named AudioUnitRender
The render callback happens whenever the speakers are hungry for data.
IIRC A.T. simply grabs however many samples are required from the microphone using this function
Of course, the first time round it will fail because there will be nothing waiting
Anyway, just comment out this function and instead fill the buffer yourself with samples from your file ( which I think you would probably want to load into memory in advance, probably don't want fileIO clogging a high priority thread )
that means you will probably need to create some sort of AudioFile class, and pass a reference to an instance of this class when you set up the render callback. that way you will be able to access the data from within this render callback ( which is a vanilla C function, ie not a member of a class, so it has no other way to access class data -- unless you want to do something horrible with file-level variables ).
make sure you create this AudioFile* audiofile NONATOMIC if it is a property, you don't want your render callback to be kept waiting because some other thread is inside the object and consequently has a lock on it.