Saturday, May 9, 2015
Saturday, February 28, 2015
Kind of a cool idea: a recorder that allows you to pin back later audio onto an earlier part of a recording. You, an interviewer, are recording an interview, and you hear the interviewee say something interesting about XXX. You hit a button on your audio recorder, the interview goes on to YYY and ZZZ, and then you say, "Can you say a little more about XXX?" You hit the button again and the interviewee expands on XXX. You hit another button. On the first button press, a pin is attached at the point where the interviewee mentioned XXX, when you press the button again a thread is attached to the pin with the audio from that point attached. When you press the other button, the thread is cut. The linear track of audio as spoken is preserved the whole way, but now there's another track where you can attach a single excerpt from later parts in the track to earlier parts.
There are, of course, limitations to the method. You can't attach a thread to either YYY or ZZZ with only the two buttons. You may be able to return to XXX depending on how we set the semantics of that first button, but it makes much more sense for that button to do the same thing as before by either pinning to one of the second-track threads in a sort-of skewed tree:
------------- `--------- `----- `--or to re-pin on the base track (p means pin):
--------p---- `---------Maybe it would be better to have a three-button system to set multiple pins with the first button, a second button to attach the thread to the earliest pin, and a third button to cut the current pin.
I'm focusing on a simple button system which can be managed more or less without thinking about what thread you're on since I think that, when I talk, my model of the conversation has this sort of folding linearity that matches with this system. Obviously, a full tablet computer with a display of these threads would allow for great flexibility, but wouldn't that display get in the way of engaging with the interviewee, the focus of your activity? There's also much more applicability for the simple thing than the complicated pretty thing that's all about itself and not about the thing that you're doing with the thing. I might permit a dial of sorts that allows you to move between pins more freely.
Tuesday, February 10, 2015
I'm a casual juggler and I'm wondering whether, when I juggle, I'm predicting the parabolic path of the balls as they fall through the air or I'm doing something else, like predicting a linear continuation of the balls' motion from any given point. To test this, I would have myself standing or sitting with my head in a fixed position. I would have a machine for throwing balls in a predictable arc (e.g., a batting cage ball delivery system). I would have the balls thrown with a spread of trajectories that land within the range of my arms for catching. I would have a head-mounted camera recording approximately the visuals that I could see. I would have a set of goggles that could obscure my vision after a specific time-delay from launching the balls. Each trial would consist of the throwing machine throwing a ball and myself attempting to catch. To establish a baseline, I would attempt to catch the balls without my vision being obscured at any point in the ball's arc. Then, I would have my vision obscured before the top of the arc, at the top, and after the top until the next trial. I would have an assistant record the trials on which I caught the ball and the ones on which I did not.
In order to reject the theory that I was calculating parabolic arcs, my performance when my vision was obscured would have to be close to as-good-as my performance when it was not. We would still expect that when my vision was blocked earlier, my performance would be worse than later. The camera recordings are to explore whether an alternate strategy, linear extrapolation, could be in effect. For the failed trials, we would predict the linear path of the ball from the time, maybe .1s, before my vision was obscured and see if my hand placement was closer to intersecting that path than the parabolic.
Since I thought of this experiment before consulting any of the literature, I'm going to do a little study. I'm starting with these here:
Friday, February 6, 2015
Tuesday, January 20, 2015
Recently I found read that the collision is handled by marking a memory page set between the stack and heap areas as a guard page. When the page is accessed, this signals an interrupt to the processor similar to what occurs in a page fault and thus allows the operating system to resume control and handle the overflow by, for instance, killing the process. Guard pages can also be used for debugging a process with unknown behavior that is presumed to access a certain portion of memory in a critical part of its operation, and this technique is valuable for software that subverts debugging with soft breakpoints (which temporarily modify program code) by checksumming code-in-execution.
Wednesday, December 10, 2014
Thursday, December 4, 2014
The API provides a way for URIs referenced from within the stylesheet instructions or within the transformation to be resolved by the calling application. This can be done by creating a class that implements the URIResolver interface, with its one method, URIResolver.resolve(java.lang.String, java.lang.String), and use this class to set the URI resolution for the transformation instructions or transformation with TransformerFactory.setURIResolver(javax.xml.transform.URIResolver) or Transformer.setURIResolver(javax.xml.transform.URIResolver). The URIResolver.resolve method takes two String arguments, the URI found in the stylesheet instructions or built as part of the transformation process, and the base URI against which the first argument will be made absolute if the absolute URI is required. The returned Source object must be usable by the transformer, as specified in its implemented features.