Balloon Pops, Convolution Reverb, and You!

Balloon Pops and You! The Audio essence of CSUMB This project involves convolution reverb. I\u27m sure you’ve used reverb before when making music. Scientifically a reverb is a self-contained echo. Most reverbs are digital, either logorhymic or algorthymic. Convolution Reverb is different from regular reverb. A convolution reverb attempts to capture the essence of a physical space. The can be done with a few different methods such as sine sweep or transients. If you have ever seen the wave form of a snare drum, you will notice it will have a steep attack with a short decay, the high point is what it known as a transient. With the transient method you can either clap your hands or pop a balloon. So, for my project I am attempting to capture the sound of the campus Okay, so what does any of this mean to me? You might be asking. Well think about this. What if you were in a Rock band and you wanted to have a unique sound to your tracks? Let’s say you wanted to have vocals sound like they are coming from a subway station, or your bass is coming from a dumpster. Maybe you want your drums to sound like they are coming from the hallway closet? You can do this with convolution reverb. This project intends to create a collection of Impulse Responses in order to put them in a convolution reverb for a musical project. After looking over CSUMB alumni’s Sam Kantoric’s capstone on Convolution reverb I seem to have been beaten to the punch. However, I believe that my project is still vastly different from his. His capstone was a broad overview of the process of convolution reverb and featured a small gathering of various IR’s. My project would be doing the same thing, only I would focus on collecting IR’s from various locations of the CSUMB campus. The method used in this project will specifically be Impulse Response Capture through Balloon Pops. In addition to not only collecting the Impulse response from the campus. The package of impulse responses will be available to everyone to download for free

Intermittent Computing: Challenges and Opportunities

The maturation of energy-harvesting technology and ultra-low-power computer systems has led to the advent of intermittently-powered, batteryless devices that operate entirely using energy extracted from their environment. Intermittently operating devices present a rich vein of programming languages research challenges and the purpose of this paper is to illustrate these challenges to the PL research community. To provide depth, this paper includes a survey of the hardware and software design space of intermittent computing platforms. On the foundation of these research challenges and the state of the art in intermittent hardware and software, this paper describes several future PL research directions, emphasizing a connection between intermittence, distributed computing, energy-aware programming and compilation, and approximate computing. We illustrate these connections with a discussion of our ongoing work on programming for intermittence, and on building and simulating intermittent distributed systems

ORCA: Ordering-free Regions for Consistency and Atomicity

Writing correct synchronization is one of the main difficulties of multithreaded programming. Incorrect synchronization causes many subtle concurrency errors such as data races and atomicity violations. Previous work has proposed stronger memory consistency models to rule out certain classes of concurrency bugs. However, these approaches are limited by a program’s original (and possibly incorrect) synchronization. In this work, we provide stronger guarantees than previous memory consistency models by punctuating atomicity only at ordering constructs like barriers, but not at lock operations. We describe the Ordering-free Regions for Consistency and Atomicity (ORCA) system which enforces atomicity at the granularity of ordering-free regions (OFRs). While many atomicity violations occur at finer granularity, in an empirical study of many large multithreaded workloads we find no examples of code that requires atomicity coarser than OFRs. Thus, we believe OFRs are a conservative approximation of the atomicity requirements of many programs. ORCA assists programmers by throwing an exception when OFR atomicity is threatened, and, in exception-free executions, guaranteeing that all OFRs execute atomically. In our evaluation, we show that ORCA automatically prevents real concurrency bugs. A user-study of ORCA demonstrates that synchronizing a program with ORCA is easier than using a data race detector. We evaluate modest hardware support that allows ORCA to run with just 18% slowdown on average over pthreads, with very similar scalability