Physical modelling sound synthesis methods generate vast and intricate sound spaces that are navigated using meaningful parameters. Numerical based physical modelling synthesis methods provide authentic representations of the physics they model. Unfortunately, the application of these physical models are often limited because of their considerable computational requirements. In previous studies, the CPU has been shown to reliably support two-dimensional linear finite-difference models in real-time with resolutions up to 64x64. However, the near-ubiquitous parallel processing units known as GPUs have previously been used to process considerably larger resolutions, as high as 512x512 in real-time. GPU programming requires a low-level understanding of the architecture, which often imposes a barrier for entry for inexperienced practitioners. Therefore, this paper proposes HyperModels, a framework for automating the mapping of linear finite-difference based physical modelling synthesis into an optimised parallel form suitable for the GPU. An implementation of the design is then used to evaluate the objective performance of the framework by comparing the automated solution to manually developed equivalents. For the majority of the extensive performance profiling tests, the auto-generated programs were observed to perform only 6\% slower but in the worst-case scenario it was 50\% slower. The initial results suggests that, in most circumstances, the automation provided by the framework avoids the low-level expertise required to manually optimise the GPU, with only a small reduction in performance. However, there is still scope to improve the auto-generated optimisations. When comparing the performance of CPU to GPU equivalents, the parallel CPU version supports resolutions of up to 128x128 whilst the GPU continues to support higher resolutions up to 512x512. To conclude the paper, two instruments are developed using HyperModels based on established physical model designs.

Manually configuring synthesizer parameters to reproduce a particular sound is a complex and challenging task. Researchers have previously used different optimization algorithms, including evolutionary algorithms to find optimal sound matching solutions. However, a major drawback to these algorithms is that they typically require large amounts of computational resources, making them slow to execute. This article proposes an optimized design for matching sounds generated by frequency modulation (FM) audio synthesis using the graphics processing unit (GPU). A benchmarking suite is presented for profiling the performance of three implementations: serial CPU, data-parallel CPU, and data-parallel GPU. Results have been collected and discussed from a high-end NVIDIA desktop and a mid-range AMD laptop. Using the default configuration for simple FM, the GPU accelerated design had a speedup of 128x over the naive serial implementation and 8.88x over the parallel CPU version on a desktop with an Intel i7 9800X CPU and NVIDIA RTX GeForce 2080Ti GPU. Furthermore, the relative speedup over the naive serial implementation continues to increase beyond simple FM to more advanced structures. Further observations include comparisons between integrated and discrete GPUs, toggling optimizations, and scaling evolutionary strategy population size.

Digital lutherie is a sub-domain of digital craft focused on creating digital musical instruments: high-performance devices for musical expression. It represents a nuanced and challenging area of human-computer interaction that is well established and mature, offering the opportunity to observe designers’ work on highly demanding human-computer interfaces. This paper explores how and why digital luthiers choose their tools and how these tools relate to the challenges they face. Findings from 27 standardised open-ended interviews with prominent digital luthiers from commercial, research, independent and artistic backgrounds are analysed through reflexive thematic analysis. Our discussion explores their perspectives, finding that a process of pragmatic rationalisation and environmental influences play a significant role in tool selection. We also present how challenges faced by digital luthiers relate to social creativity and meta-design. These findings build upon the existing literature that examines the designer-tool relationship.

This paper reports on the Audio Anywhere project, a framework for working with audio plugins that are compiled once and run anywhere. At the heart of Audio Anywhere is an audio engine whose Digital Signal Processing components are written in Faust and deployed with WebAssembly.

Voice assistants such as Amazon Echo and Google Home have become increasingly popular for many home users, for home automation, entertainment, and convenience. These devices process speech commands from a user to execute some action, such as playing music, making online purchases, or triggering home automation such as lights or security locks. The process of mapping speech input to a text command is performed using a machine learning model. In this study, we explore the concept of how voice assistants could be exploited, where genuine audio commands are manipulated such that an attacker could trigger alternative responses from the voice assistant. We present a small-scale study to examine mis-interpretations made by voice assistants. We also study user perception of how secure their voice devices are, and their approach to security and privacy.

General-Purpose GPU computing is becoming an increas-ingly viable option for acceleration, including in the audio domain. Although it can improve performance, the intrin-sic nature of a device like the GPU involves data transfers and execution commands which requires time to complete. Therefore, there is an understandable caution concerning the overhead involved with using the GPU for audio computation. This paper aims to clarify the limitations by presenting a performance benchmarking suite. The benchmarks utilize OpenCL and CUDA across various tests to highlight the considerations and limitations of processing audio in the GPU environment. The benchmarking suite has been used to gather a collection of results across various hardware. Salient results have been reviewed in order to highlight the benefits and limitations of the GPU for digital audio. The results in this work show that the minimal GPU overhead fits into the real-time audio requirements provided the buffer size is selected carefully. The baseline overhead is shown to be roughly 0 . 1 ms , depending on the GPU. This means buffer sizes 8 and above are completed within the allocated time frame. Results from more demanding tests, involving physical modelling synthesis, demonstrated a bal-ance was needed between meeting the sample rate and keep-ing within limits for latency and jitter. Buffer sizes from 1 to 16 failed to sustain the sample rate whilst buffer sizes 512 to 32768 exceeded either latency or jitter limits. Buffer sizes in between these ranges, such as 256, satisfied the sample rate, latency and jitter requirements chosen for this paper.

Various barriers prevent blind and visually impaired people accessing the rich multisensory experiences available at heritage centres. These barriers include large bodies of text and items in glass cases, which are difficult to see. Feedback from the blind community reflects poorly upon the inflexibility of guided tours. Technology-based accessibility tools are often laden with visually heavy interfaces or require storage space or power at each exhibit. \r\n\r\nThis paper presents a low-cost digital audio guide that can be combined with existing 2D and 3D systems, as well as 3D printed reliefs and replicas. The technology aims to work in a variety of environments, allowing curators to retrofit it into centres with limited space. The handheld system provides pre-recorded audio to visitors as they explore the centre. Sound is triggered via \u0027tap\u0027 onto Near-Field Communication (NFC) tags, which are placed by the curator or artist. Content is updated via a central system, which replicates to each device. A storytelling process can be created through the addition of motion gestures (e.g. shake), enhancing the experience for all visitors.

Music provides a means to explore time by sequencing musical events in a seemingly endless and expressive way. This potential often far exceeds the ability of digital systems to enable composers and performers to explore musical time, perhaps due to the influence of Western music on implementation or maybe due to the challenges involved in the notation of music itself. In this paper we look at ways to explore time within a musical context, looking to create tangible examples and methods for exploring complex rhythmic relationships using digital systems. We draw on the approach for describing sequences in terms of cycles, inspired by the live coding language Tidal Cycles. A simple Domain Specific Language (DSL) is described, in order to realize a Digital Musical Instrument (DMI) that facilitates performing with polyrhythm in a intuitive and tactile way. This highlights the use of DSLs for the design of DMIs. Further, an abstraction for representing sequences of musical events on a digital system is provided, which facilitates complex rhythmic relationships (namely, polyrhythm and polymeter) and extends to handle modulation of time itself.

In this paper we address the design and implementation of custom controller interfaces, bridging the issue of user mapping between action and sound in interactive music systems. A simple framework utilizing functional specifications for musical interfaces and their mappings is presented, in terms of a subset of Scalable Vector Graphics (SVG); interfaces can be described using a simple Haskell based 'controller DSL' or equally using a vector drawing application (i.e. Illustrator). We demonstrate the practical use of our system for specifying interfaces as SVGs combined with Faust, a functional DSL for Digital Signal Processing (DSP), in the context of building digital musical instruments. We combine these into a hardware and software audio toolkit, with synthesizers, a sampler, effects, and sequencers. Written in the systems programming language Rust, it demonstrates utilizing the output of our DSLs, providing a type safe and high-level framework for DSP and interface development, with the performance benefits of Rust. Working examples of custom interfaces are described, using ROLI's Lightpad and Sensel's Morph.

Digital audio synthesis has become an important component of modern music production with techniques that can produce realistic simulations of real instruments. Physical modelling sound synthesis is a category of audio synthesis that uses mathematical models to emulate the physical phenomena of acoustic musical instruments including drum membranes, air columns and strings. The synthesis of physical phenomena can be expressed as discrete variants of Newton's laws of motion, using, for example, the Finite-Difference Time-Domain method or FDTD. FDTD is notoriously computationally expensive and the real time demands of sound synthesis in a live setting has led implementers to consider offloading to GPUs. In this paper we present multiple OpenCL implementations of FDTD for real time simulation of a drum membrane. Additionally, we compare against an AVX optimized CPU implementation and an OpenGL version that utilizes a careful mapping to the GPU texture cache. We find using a discrete, laptop class, AMD GPU that for all but the smallest mesh sizes, the OpenCL implementation out performs the others. Although, to our surprise we found that optimizing for workgroup local memory provided only a small performance benefit.

Considering the generation of musical tunings, it is reasonable to expect that the many constructs contained in Functional programming languages may provide useful tools for exploring both conventional and new tunings. In this paper we present a number of approaches for manipulating tunings using basic mathematics. While this provides a simple foundation for describing temperament, it is fundamental enough to support a variety of approaches and further, allows the unbounded description of arbitrary tunings. It is expected that this notion will be useful in defining tunings, and by extension scales, for Digital Musical Instruments. This breaks down the physical barrier that has limited the likes of just intonations from having practical applications in the performance setting. It also enables composers to explore a variety of non traditional temperaments rapidly, without having to manually tune each note.

Considering the generation of musical tunings, it is reasonable to expect that the many constructs contained in Functional programming languages may provide useful tools for exploring both conventional and new tunings. In this paper we present a number of approaches for manipulating tunings using basic mathematics. While this provides a simple foundation for describing temperament, it is fundamental enough to support a variety of approaches and further, allows the unbounded description of arbitrary tunings. It is expected that this notion will be useful in defining tunings, and by extension scales, for Digital Musical Instruments. This breaks down the physical barrier that has limited the likes of just intonations from having practical applications in the performance setting. It also enables composers to explore a variety of non traditional temperaments rapidly, without having to manually tune each note.

The Bristol LoRaWAN Network is a low power radio network for the Internet of Things, based on LoRaWAN and utilising The Things Network. LoRaWAN is a Low Power Wide Area Network (LPWAN) specification intended for wireless battery operated Things in regional, national, or global networks. LoRaWAN targets key requirements of internet of things such as secure bi-directional communication, mobility and localisation services. A 2015 pilot programme in the city of Amsterdam aimed to cover the entire city with just 10 wireless gateways. LoRaWAN Bristol aims to replicate this experiment in the UK.

In this chapter, we introduce and demonstrate the use of HSA queues, including both device queues and soft queues. Device queues allow the HSA developer to interact with HSA devices, for example a GPU, and soft queues allow HSA programs and non-HSA devices to provide software abstractions that implement the same queuing interface as HSA devices implement. We follow with a description of the Architected Queuing Language, which provides a protocol for communicating with each type of device via the corresponding queues, and we show how to use the interface exposed by queues to safely submit work to HSA devices.

A popular approach to programming manycore GPUs is the Single Instruction Multiple Thread (SIMT) abstraction. SIMT has the benefit of presenting a "single thread" view, alleviating the complexity of explicitly vectorizing the source code. However, due to the SIMD nature of the underlying hardware it is often difficult to fully hide all aspects from the developer. An example of "leaks", is OpenCL's barrier, which requires all workitems (i.e. threads) to reach and execute the "same" barrier. But what does it mean to reach and execute the same barrier? OpenCL provides very little information about the underlying semantics. In this talk we explore OpenCL's execution model, from both a programmer's perspective but also considering the set of valid translations that an optimizing compiler can perform while retaining the intended semantics. Using a set of examples, sometimes surprisingly, we show that common transformations often performed by traditional scalar compilers are not, in general, valid when applied to OpenCL code containing workgroup (or subgroup) collective operations. Additionally, we introduce a mathematical notion of workgroup and subgroup uniformity and outline an execution model for OpenCL 2.0, which enables these traditional compiler transformations to be applied, even in the presence of collective operations, for a t of all valid OpenCL programs. The model clearly describes when it is valid and when it is not valid to apply these transformations. This talk is intended for OpenCL developers and compiler writers alike, providing insight into the often ill-documented OpenCL execution model, its intended design choices, and how different implementer's might implement contentious aspects of the specification differently.

Memory consistency models, or memory models, allow both programmers and program language implementers to reason about concurrent accesses to one or more memory locations. Memory model specifications balance the often conflicting needs for precise semantics, implementation flexibility, and ease of understanding. Toward that end, popular programming languages like Java, C, and C++ have adopted memory models built on the conceptual foundation of Sequential Consistency for Data-Race-Free programs (SC for DRF). These SC for DRF languages were created with general-purpose homogeneous CPU systems in mind, and all assume a single, global memory address space. Such a uniform address space is usually power and performance prohibitive in heterogeneous Systems on Chips (SoCs), and for that reason most heterogeneous languages have adopted split address spaces and operations with nonglobal visibility. There have recently been two attempts to bridge the disconnect between the CPU-centric assumptions of the SC for DRF framework and the realities of heterogeneous SoC architectures. Hower et al. proposed a class of Heterogeneous-Race-Free (HRF) memory models that provide a foundation for understanding many of the issues in heterogeneous memory models. At the same time, the Khronos Group developed the OpenCL 2.0 memory model that builds on the C++ memory model. The OpenCL 2.0 model includes features not addressed by HRF: primarily support for relaxed atomics and a property referred to as scope inclusion. In this article, we generalize HRF to allow formalization of and reasoning about more complicated models using OpenCL 2.0 as a point of reference. With that generalization, we (1) make the OpenCL 2.0 memory model more accessible by introducing a platform for feature comparisons to other models, (2) consider a number of shortcomings in the current OpenCL 2.0 model, and (3) propose changes that could be adopted by future OpenCL 2.0 revisions or by other, related, models.

Memory consistency models, or memory models, allow both programmers and program language implementers to reason about concurrent accesses to one or more memory locations. Memory model specifications balance the often conflicting needs for precise semantics, implementation flexibility, and ease of understanding. Toward that end, popular programming languages like Java, C, and C++ have adopted memory models built on the conceptual foundation of Sequential Consistency for Data-Race-Free programs (SC for DRF). These SC for DRF languages were created with general-purpose homogeneous CPU systems in mind, and all assume a single, global memory address space. Such a uniform address space is usually power and performance prohibitive in heterogeneous Systems on Chips (SoCs), and for that reason most heterogeneous languages have adopted split address spaces and operations with nonglobal visibility. There have recently been two attempts to bridge the disconnect between the CPU-centric assumptions of the SC for DRF framework and the realities of heterogeneous SoC architectures. Hower et al. proposed a class of Heterogeneous-Race-Free (HRF) memory models that provide a foundation for understanding many of the issues in heterogeneous memory models. At the same time, the Khronos Group developed the OpenCL 2.0 memory model that builds on the C++ memory model. The OpenCL 2.0 model includes features not addressed by HRF: primarily support for relaxed atomics and a property referred to as scope inclusion. In this article, we generalize HRF to allow formalization of and reasoning about more complicated models using OpenCL 2.0 as a point of reference. With that generalization, we (1) make the OpenCL 2.0 memory model more accessible by introducing a platform for feature comparisons to other models, (2) consider a number of shortcomings in the current OpenCL 2.0 model, and (3) propose changes that could be adopted by future OpenCL 2.0 revisions or by other, related, models.