Is there a way to extract the AudioBuffer of an element for analysis? I want to avoid dealing with cross-origin issues that arise when using an XMLHttpRequest, if possible.
No, because an element doesn't necessarily have a backing AudioBuffer (it may be streaming an hour-long podcast, for example - you don't want a gigabyte-order AudioBuffer).
It would be possible to RECORD (in realtime, unfortunately, not faster) the output of an element - createmediaelementsource() it and hook it up to code like RecordJS.
Related
I have been using Bytebuddy to monitor application behaviours, and I would like to check whether an array field of one of application classes is updated before executing a particular method. I have read Bytebuddy documentation and stack overflow questions and have found some useful documentation of how to intercept field accesses using MemberSubstitution.
However, because the field I'm interested in is an array, onWrite and onRead events in MemberSubstitution seem irrelevant.
Is it possible to track updates on an array field using Bytebuddy?
No, unfortunately no. Arrays are read onto the stack. Then only afterwards elements are accessed by index. This can be preceded by arbitrary instructions and is not interceptable individually.
I'm learning Metal, and there's a conceptual question that I'm trying to wrap my head around: at what level, exactly, should my code handle successive drawing operations that require different pipeline states? As I understand it (from answers like this: https://stackoverflow.com/a/43827775/2752221), I can use a single MTLRenderCommandEncoder and change its pipeline state, the vertex buffer it's using, etc., between calls to drawPrimitives:, and the encoder state that was current at the time of each call to drawPrimitives: will be preserved. So that's great. But it also seems like the design of Metal is such that one can make multiple MTLRenderCommandEncoder instances, and use them to sequentially throw batches of commands into a MTLCommandBuffer. Given that the former works – using one MTLRenderCommandEncoder and changing its state – why would one do the latter? Under what circumstances is it correct to do the former, and under what circumstances is it necessary to do the latter? What is an example of a situation where the latter would be necessary/appropriate?
If it matters, I'm working on a macOS app, using Objective-C. Thanks.
Ignoring multithreaded encoding cases, which are somewhat advanced, the main reason you'd want to create multiple render command encoders during a frame is because you need to change which textures you're rendering to.
You'll notice that you need to provide a render pass descriptor when creating a render command encoder. For this reason, we often say that the sequence of commands belonging to a particular encoder constitute a render pass. The attachments of that descriptor refer to the textures that will be written to by the commands encoded by the encoder.
Many different techniques, including shadow mapping and postprocessing effects like bloom require multiple passes to produce. Since you can't change attachments in the midst of a pass, creating a new encoder is the only way to encode multiple passes in a frame.
Relatedly, you should ordinarily use one command buffer per frame. You can, however, sometimes reduce frame time by splitting your passes across multiple command buffers, but this is highly dependent on the shape of your workload and should only be done in tandem with profiling, as it's not always an optimization.
In addition to Warren's answer, another way to look at the question is by examining the API. A number of Metal objects are created from descriptors. The properties of the descriptor at the time an object is created from it govern that object for its lifetime. Those are aspects of the object that can't be changed after creation.
By contrast, the object will have various setter methods to modify other properties over its lifetime.
For a render command encoder, the properties that are fixed for its lifetime are those specified by the MTLRenderPassDescriptor used to create it. If you want to render with different values for any of those properties, the only way to do so is to create a new encoder from a different descriptor. On the other hand, if you can do everything you need/want to do by using the encoder's setter methods, then you don't need a new encoder.
I'm trying to figure out the name behind this design pattern. Basically, you have some arbitrary data that needs to be processed, and any arbitrary number of "handler" objects that may be capable of handling the data. The data gets passed to these handlers until something processes it.
For example, in Qt, QImage reads images via QImageReader. QImageReader queries QImageIOHandler objects to see if the given file format can be read by that QImageIOHandler. If so, it uses that handler to read the image.
Is there a name for this delegation of responsibility?
Chain of Responsibility
Hi could anyone point me in the right direction with a tutorial, guide or sample code, thanks, Sami.
The answer given by shreyasva is close but somewhat misleading.
First, parsing the XML into an easily-managed Cocoa data structure is perfectly correct. For performance reasons, you shouldn't be tying your table's datasource directly to the XML. yan.kun's suggestion is certainly possible but if you have "more than a little" data, you very well could run into performance problems. I highly recommend just parsing the data into an NSArray of NSDictionary objects for longer data sets.
Second, Core Data is a bit overkill if you don't plan to persist the XML document in some other way or if you only have a handful of objects. Overkill by a long shot. It's also not necessary (and often not reasonable) to shoehorn every data structure in your app into Core Data without good reason. An NSDictionary instance will work just fine for caching the parsed data for consumption by a table view.
Third, there is no -tableView:cellForRowAtIndexPath: method. This seems to be confusing NSTableView with UITableView. Since you specified the Mac tag, look into the NSTableViewDataSource protocol. Cocoa Bindings is not "better than" or a "replacement for" the data source protocol. It's an "alternative to". You can either load your parsed data into an NSArrayController (an array of dictionaries, one per "record", for example) and bind the table columns to it (each column is bound to a key in the dictionaries in the array controller's arrangedObjects) or just use the (easy) table data source protocol that takes literally two minutes of copy/paste from the docs to get up and running.
Ill give you an idea of the architecture.
Parse the XML using any popular XML parser NSXMLParser is fine.
Store the data using core data objects, if data is not too much, keep it in memory.
Load data in tableView:cellForRowAtIndexPath:
Alternatively, if you just want to list the content, without editing capabilities, you can load the XML into a NSXMLDocument and bind the TableView via xPath.
I have a stream of data that I want to place into a container. This container will either be of fixed size or dynamically constrained to a certain size at runtime. The latter may be preferable.
When the container is full, the oldest data will be removed.
I want to display this data using a wxVListBox because I need full control of the display. However there is a problem: the calls to OnDrawItem are not atomic meaning that once the container is full, each call the OnDrawItem will be accessing moving data, the result will be a non-contiguous display with missing elements.
This is certainly true with any container with native array-like indexing, are required by OnDrawItem.
I can simulate array-like indexing in a std::map using iterator indexing, if the key is sequential integer, then all the items will be ordered and the map can be pruned quite easily, but that seems like an inefficient hack.
How can I solve this? Any other ideas or containers I haven't thought of?
The best approach seems to be to manage the full container state lazily within OnDrawBackground. That way the UI itself ensures the data remains static in the subsequent calls to OnDrawItem, using a deque as the container.