Databites Labs

ML and Audio Primitives Notes

Sat, 27 Sep 2025 00:00:00 +0000

🎧 Audio Engineering Basics – PCM, Sample Rate, Bit Depth

After working on Zero-Shot TTS (cascading), Sesame (multimodal), and a host of other pipelines, I’ve learned there are a few primitives you have to commit to muscle memory. When you can picture the inputs and outputs—down to the units and shapes—you can sanity-check a model’s behavior in seconds.

1. Mono vs Stereo

Think of channels as lanes on an audio freeway: the more lanes, the more parallel signals you have to juggle.

Mono pushes the same signal everywhere.
Stereo keeps left and right independent—each at the full sample rate.
5.1 (or any surround format) simply adds more lanes.

Quick gut check: 48 kHz stereo means each ear still gets 48,000 samples every second.

2. Sample Rate

Sample rate is the metronome driving how often you capture amplitude. Speech stacks usually sit at 16 kHz; music master chains often ride at 44.1 or 48 kHz, and experimental rigs run higher when latency is a luxury.

3. Bit Depth

Bit depth is how many “clicks” your amplitude knob has.

16-bit PCM (int16) lives in integer land: -32768 to 32767, two bytes per sample.
32-bit Float PCM (float32) keeps everything normalized between -1.0 and +1.0, with more headroom for DSP math.

Translation: more bits = finer amplitude resolution, so transient details survive mixdowns.

4. Core Formulas

These are the sanity checks I reach for when a tensor feels off.

duration_ms = (samples / sample_rate) * 1000

samples = (sample_rate * duration_ms) / 1000

chunk_duration_ms = (480 / 24000) * 1000  # 480-sample chunk at 24 kHz ≈ 20 ms

5. Data Rate Examples (Uncompressed PCM)

Once you know the frame composition, bandwidth math is just multiplication.

Sample Rate	Bit Depth	Channels	Bytes/sec	kB/sec	MB/min
48 kHz	16-bit	Mono	96,000	96	5.76
48 kHz	16-bit	Stereo	192,000	192	11.52
48 kHz	Float32	Mono	192,000	192	11.52
48 kHz	Float32	Stereo	384,000	384	23.04

6. Frames in PCM

In PCM audio, a frame is the snapshot across every channel at a single instant.

Frame = one sample from each channel.
Sample = the amplitude value for one channel at that instant.

So:

Mono → 1 channel → 1 sample per frame.
Stereo → 2 channels → left + right samples per frame.
5.1 surround → 6 channels → six samples per frame.

Frames keep multi-channel tensors aligned. One missing channel value and the whole frame is corrupt.

7. Frame Size Example

Let’s walk the math for a frame you actually ship: 48 kHz, stereo, float32, 20 ms.

samples_per_channel = (48000 * 20) / 1000   # 960 samples

total_samples = samples_per_channel * 2     # stereo → 1920 samples

bytes = total_samples * 4                   # float32 → 7680 bytes

✅ Summary

Sample rate = time resolution; bit depth = amplitude resolution.
Frames bundle every channel’s sample at a moment so tensors stay synchronized.
Keep those formulas in reach and you’ll know instantly whether a model output is reasonable—or about to blow up your real-time budget.

Draft notes for ML and audio primitives will be added here.

Object-Oriented Shell, Functional Core - Managing State in Modern Applications

Tue, 19 May 2020 00:00:00 +0000

Combining the best of object-oriented and functional programming paradigms to build maintainable SCRUD applications.

Introduction

Object-Oriented Shell, Functional Core (OSFC) represents a powerful architectural pattern that emerged from my experience with both Haskell’s pure functional approach and the pragmatic realities of OOP languages. This technique offers a compelling solution for managing complexity in modern SCRUD (Search, Create, Read, Update, Delete) applications.

The core principle is elegantly simple: encapsulate side effects within an object-oriented shell while keeping business logic pure and functional at its core. This separation yields code that’s both testable and maintainable.

Understanding State in Applications

Before diving into pure and impure functions, let’s establish a clear taxonomy of state in applications:

1. Global State

Variables accessible throughout the entire application for both reading and writing. While powerful, global state introduces coupling and makes reasoning about code flow challenging.

2. Object State

Member variables confined within object boundaries. Access control (public/private) determines visibility, providing encapsulation while maintaining flexibility.

3. Persisted State

Data stored in databases or file systems (e.g., CoreData, SQLite). This state survives application restarts and requires careful synchronization with in-memory representations.

The Two Faces of Side Effects

Understanding side effects is crucial for applying OSFC effectively:

Static Side Effects

These manifest at compile time. Remove a singleton’s method, and your IDE immediately highlights every broken reference. While disruptive, static side effects are predictable and manageable.

Runtime Side Effects

Far more insidious, runtime side effects emerge during execution. A function modifies a shared variable, another function reads it later expecting the original value—suddenly, you’re debugging seemingly impossible behavior. These effects compound exponentially as systems grow.

Pure Functions: The Functional Core

Definition

In object-oriented contexts, a pure function exhibits three key characteristics:

No self modification - It doesn’t alter the object’s state
Immutable inputs - Parameters remain unchanged
Deterministic output - Always returns a value (synchronously or asynchronously)

For asynchronous operations, the return mechanism might involve callbacks, promises, observables (Rx), or other async patterns—but the principle remains: predictable input-output relationships.

Why Pure Functions Matter

Pure functions offer compelling benefits:

Testability: Deterministic behavior makes unit testing straightforward
Composability: Chain pure functions without fear of hidden interactions
Reasoning: Understand functions in isolation without tracing global effects
Refactoring: Remove or relocate pure functions safely

This dramatically reduces cognitive load. When reading pure functions, you need only understand their inputs and outputs—not the entire system state.

The Reality of Impure Functions

Despite their benefits, pure functions alone cannot build complete applications. SCRUD operations inherently require state mutation—updating databases, modifying UI, handling user input. This is where the object-oriented shell comes in.

Consider this practical example:

class TaskManager {
    private var tasks: [Task] = []
    
    // Impure: Modifies object state
    func deleteTask(at index: Int) {
        tasks.remove(at: index)
        persistTasks() // Side effect: Database write
    }
    
    // Pure: Returns new array without modifying state
    func tasksFiltered(by status: TaskStatus) -> [Task] {
        return tasks.filter { $0.status == status }
    }
}

Practical Implementation in Swift

Let’s examine how Swift’s type system helps enforce these patterns:

Free Functions and Side Effects

class Account {
    var balance: Int = 0
}

struct Transaction {
    let amount: Int
}

// This appears pure but isn't—reference types allow mutation
func processTransaction(account: Account, transaction: Transaction) {
    account.balance += transaction.amount // Side effect!
}

// Truly pure version returns new state
func calculateNewBalance(currentBalance: Int, transaction: Transaction) -> Int {
    return currentBalance + transaction.amount
}

Key insight: Swift’s value types (structs) naturally encourage pure functions, while reference types (classes) require discipline to avoid unintended mutations.

Member Functions in Classes

class BankAccount {
    private var balance: Int = 0
    
    // Pure member function - doesn't reference self's mutable state
    func calculateInterest(principal: Int, rate: Double) -> Int {
        return Int(Double(principal) * rate)
    }
    
    // Impure - modifies state
    func applyInterest(rate: Double) {
        let interest = calculateInterest(principal: balance, rate: rate)
        balance += interest
    }
}

The Graph Theory Perspective

Viewing code through graph theory illuminates why pure functions reduce complexity:

Nodes: Variables and state
Edges: Read/write relationships
Pure functions: Isolated subgraphs with no outgoing edges

Pure functions create localized computation graphs disconnected from the larger system state graph. This isolation is what makes them so powerful—changes propagate predictably within boundaries.

Best Practices for OSFC

Identify boundaries: Clearly separate pure business logic from stateful coordination
Push effects outward: Keep side effects at the system’s edges
Leverage type systems: Use Swift’s structs for data, classes for coordination
Test the core: Focus testing efforts on pure functions
Document effects: When functions must be impure, clearly document their side effects

Conclusion

Object-Oriented Shell, Functional Core isn’t about choosing sides in the OOP vs. FP debate. It’s about leveraging each paradigm’s strengths: OOP’s encapsulation for managing effects and FP’s purity for expressing logic.

In your next project, try identifying one complex business rule and extracting it into pure functions. You’ll likely find the resulting code more testable, readable, and maintainable. The journey toward better architecture begins with a single pure function.

Next in this series: We’ll explore advanced patterns for chaining pure functions and managing asynchronous operations within the OSFC paradigm.

Inheritance is bad - don't use it.

Mon, 18 May 2020 00:00:00 +0000

OOP and Inheritance - the scourge of modern programming practices.

“OOP is a terrible paradigm, stop using inheritance, it’s bad practice” - this is something that you will hear around on the internet and through some ideologues. Yes, that was clickbait.

Is inheritance a bad design decision?

Not necessarily, if you understand how to architect systems and quantify the change distance and complexity stemming from inheritance decisions.

TL;DR This article explores reframing our mental model of code by applying graph theory to reveal hidden structural patterns, empowering more informed architectural decisions.

The conventional wisdom suggests limiting inheritance to one or two levels. When parent classes share substantial common variables or functionality that child classes will extend or utilize, subclassing helps maintain the DRY principle. Beyond this threshold, the consequences warrant careful consideration.

In this tutorial, I’ll demonstrate a method for quantifying inheritance-induced complexity and its impact on change propagation. This approach enables data-driven design decisions and extends to broader software architecture concerns.

This technique leverages graph theory to calculate distances between objects via edge relationships.

Okay, let’s write some code. Inheritance of classes in Swift is denoted by classTemplate:

class A {
}

class B:A {
}

class C:B {
}

class D:C {
}

A -> B -> C -> D

We should envision this scenario as a sequence of interconnected nodes forming a directed graph.

If you don’t know what that is, here’s an article: https://en.wikipedia.org/wiki/Graph_theory

Here we can describe the distance from A using the edges. The distance from D to A is 3 The distance from C to A is 2 The distance from B to A is 1

Furthermore, numerous permutations emerge when examined from different object perspectives, though we’ll focus primarily on A.

Having explored the depth distance from A to D, let’s examine the breadth dimension. Or how about we just subclass from A?

class A {
}

class B:A {
}

class C:A {
}

class D:A {
}

//A -> [C,B,D]

Here the distance between A and CBD is 1, but the width or breadth of A is 3. Does that have an impact on change? If so, whose perspective? Now let’s cut into this a bit deeper. (Exercise left to the reader after completing the article)

By overlaying this graphical abstraction onto OOP code, we establish a framework for measuring change propagation when modifying functions or variables in A’s design.

How about functions and variables now?

class A {
  public var someNumber:Int = 0
  public func hello() -> String {
        return ""
  }
}

class B:A {
}

class C:B {
}

class D:C {
}

Let’s go back to the first example and add a variable to class A and a function func Hello() -> String that returns a string.

By introducing the public variable someNumber to A, we’ve effectively disseminated variables and functions throughout A’s entire inheritance hierarchy.

What does that mean from a graphical perspective?

class A {
  public var someNumber:Int = 0
  public func hello() -> String {
        return ""
  }
}

class B:A {
	public func useHelloB() {
		hello()
	}
}

class C:B {
	public func useHelloC() {
		hello()
	}
}

class D:C {

	public func useHelloD() {
		hello()
	}

	func useVarC() {
		print(someNumber)
	}
}

Examining the graph reveals that modifications would cascade through 4 functions and 1 variable while preserving their original behavior.

Should we attempt to eliminate A entirely, the change distance in this contrived design becomes substantial. This stems from the intricate web of dependencies inheritance creates.

When architecting with inheritance, these implications demand careful deliberation.

Design must account for the temporal dimension: how future developers will interface with and extend your architectural choices.

Consequently, as others build upon your foundation, modifying base implementations becomes increasingly arduous without substantial refactoring efforts.

Typically, we would navigate this transition through systematic deprecation.

To minimize complexity, we must shorten the dependency chains between variables while strengthening cohesion—co-locating related functionality to ensure that closely interdependent elements reside together. This reduces the traversal distance between dependent components and minimizes the ripple effects of change across the inheritance hierarchy.

Consider the principle of locality: when methods frequently access the same variables, they should exist at the same inheritance level. This proximity reduces cognitive load—developers don’t need to trace through multiple parent classes to understand interactions. Moreover, it enables easier refactoring since related changes remain localized within a single class boundary.

The inverse relationship between inheritance depth and maintainability becomes clear through this lens. Each additional layer of inheritance increases the conceptual distance between cause and effect, making the codebase progressively more brittle. By flattening hierarchies and favoring composition over inheritance, we create systems where change propagation follows predictable, localized patterns rather than cascading through an elaborate ancestry.

Note: I’ve omitted the nuanced implications of public variable exposure and its compounding effect on complexity.

Note On Example: Additionally, while removing A and modifying Hello() might seem trivial in our examples (given their minimal functionality in child classes), the critical insight remains: these changes must still be propagated throughout the codebase.

Numpy Top Functions used with Dataframes

Sat, 02 May 2020 00:00:00 +0000

Numpy Top Functions used in Data Analysis

Top Functions

# %%
import numpy as np
import pandas as pd


# %%
labels = ['a','b','c']
aList = [1,2,3]
array = np.array([1,2,3])
d = {'a':1,'b':2,'c':3}

# A Series is a numpy array with labels
series = pd.Series(aList)
print(series)


# %%
seriesLabel = pd.Series(aList,index=labels)
print(seriesLabel)


# %%
seriesWithDict = pd.Series(d)
print(seriesWithDict)


# %%
# Let's create a series
series1 = pd.Series([1,2,3],index=['Asia','Europe','NorthAmerica'])
print(series1)


# %%
# Access a series via its label
series1["NorthAmerica"]


# %%
# You can add series together
series2 = pd.Series([1,2,3,4],index=['Asia','Europe','NorthAmerica',"NorthUmbria"])
newSeries3 = series1 + series2
print(newSeries3)
# Expect that it wouldn't be able to add non-existing labels 


# %%
# 2D frame of data
from numpy.random import randn
# All a DataFrame is, is a set of series that share common index abcde; xyz are the series
dataframe = pd.DataFrame(randn(5,3),['a','b','c','d','e'],['x','y','z'])
print(dataframe)


# %%
# Selecting from DataFrames
dataframe["y"] 


# %%
type(dataframe['x']) # Series type


# %%
dataframe[['x','y']] # Get two series


# %%
# Create a new series in a DataFrame. If you create one that is larger than axis=0 or runs along the rows or the labels, it will error out
dataframe['newSeries'] = range(0,5)


# %%
print(dataframe['newSeries'])


# %%
dataframe['newSeries'] 


# %%
# Let's delete a column or a series. You can use the inplace arg to ensure that it modifies it in memory rather than returning a copy
dataframe.drop('newSeries',axis=1)
print(dataframe) # You will see here that the DataFrame is still available


# %%
# Let's drop a labeled row
dataframe.drop('a',axis=0)


# %%
dataframe.shape


# %%
# Rows are also a series as well. This is how to select a row.
dataframe.loc['a']


# %%
# Select a row with iloc
dataframe.iloc[0]


# %%
# You can select by each one
dataframe.loc[['d','a']]


# %%
# You can slice
dataframe.loc['a':'e']


# %%
# You can slice via row and col 
dataframe.loc['a':'b',:'z']


# %%

Numpy Top Functions used in Data Analysis

Fri, 01 May 2020 00:00:00 +0000

Numpy Top Functions used in Data Analysis

Top Functions

# To add a new cell, type '# %%'
# To add a new markdown cell, type '# %% [markdown]'
# %%
import numpy as np


# %%
# Numpy: The commonly used functions - memorize these


# %%
# Initialize an array from a list
my_list = [1,2,3,3]
x = np.array(my_list)


# %%
# If you need to check the type
type(x)


# %%
# Create a matrix from an array
my_matrix = [
    [1,2,3],
    [4,5,6],
    [7,8,9]]


# %%
print(my_matrix)


# %%
# Use the same initializer
np.array(my_matrix)


# %%
# Create a range from 0 -> 5
list(range(0,5))


# %%
# Create a range with space in between
list(range(0,10,2))


# %%
# Easier way: use a range
print(np.arange(0,100,2))


# %%
# An array of zeroes rows by columns
np.zeros((2,3))


# %%
# An array of ones
np.ones((10,10))


# %%
# This gives us numbers from 0 to 10, with 100 elements evenly spaced between them
np.linspace(0,10,100)


# %%
# Identity matrix 
np.eye(10,10)


# %%
# Random Library! Want a random set of numbers? Gives us random numbers between 0-1 using a uniform distribution
# Meaning from 0-1 each number is picked randomly given probability. 
np.random.rand(5,5)


# %%
# The closer you are to the mean, the higher likelihood you are picked as a number
np.random.randn(5,5)


# %%
# How about a random integer between two values, not including 100? Give me 10
np.random.randint(0,100,10)


# %%
# Reshape into 5 by 5 matrix
arr = np.arange(25)
arr.reshape(5,5) # Quick trick for reshaping: 5*5 must equal 25


# %%
# Max number gives you the max number
arr.max() 
# ArgMax gives you the argument (index) of the max, same with min
arr.argmax()
# Gives you the type of the array
arr.dtype


# %%



# %%

Python VirtualEnv

Wed, 29 Apr 2020 00:00:00 +0000

Notes about VirtualEnv and Visual Studio Code

Create a Virtual Environment

python3 -m venv --copies /path/to/new/virtual/environment 
source venv/bin/activate #activate
deactivate # leave

Visual Studio Code: When you create a virtual env and open a folder where your code is sitting, then create the virtual environment there. Once you do, you can activate the environment in Visual Studio Code - look to the bottom corner and you can change the environment with the dropdown menu, or use the command palette and select the environment. We have to use copies to ensure that we don’t symlink to the system installed python3.

Command + P select interpreter

# settings.json
{
    "workbench.colorTheme": "Noctis Viola",
    "python.pythonPath": "/usr/local/bin/python3",
    "editor.fontFamily": "FiraCode-Retina",
    "editor.fontLigatures": true,
    "editor.fontSize": 15,
}

To start the Jupyter notebook, set up your virtual env.
Then Command + P and select interpreter to start Jupyter notebook. Restart Visual Studio Code if it doesn't work.

Matplotlib using the Basic OOP API and Graphing with Colors

Mon, 24 Jun 2019 00:00:00 +0000

Graphing with Matplotlib in OOP style. I often see many tutorials using the global state machine version of matplotlib. While they are quick to use, it’s often confusing and quickly becomes unwieldy when you want to reuse the code.

I often see many tutorials using the global state machine version of matplotlib. While they are quick to use, it’s often confusing and quickly becomes unwieldy when you want to reuse the code.

The best way to work with Matplotlib is to look at the tutorials. Matplotlib has a guide explaining what a figure comprises of here: Direct link to tutorial

We really want to use the object-oriented pyplot in this case: OOP API Documentation As the global state API is pretty dated and really confusing, it makes it difficult for people to track what changes are occurring.

When I start learning an API, I make sure I learn the typical workhorse functions for various tasks.

Here’s the import statement we would require for getting this into a Jupyter Notebook:

import matplotlib.pyplot as plt
import matplotlib as mpl
mpl.rcParams['figure.dpi']= 300 # MAKES CRISP
mpl.rcParams['figure.figsize'] = [10, 10] # MAKES DEFAULT FIGURE SIZE
%config InlineBackend.figure_format = 'svg' # MAKES RENDERING CLEAN
%matplotlib inline # ALLOWS INLINING IN THE NOTEBOOK

Standard OOP Usage

You will usually start by creating a figure and axes. Here we access the linechart via plot, and pass xs and ys.

You can find the Plot Types in the Documentation Here.

The core API design requires lists of data as xs and ys, as np.arrays allows data to be plotted easier.

rows = 1
cols = 1

fig, axs = plt.subplots(rows,cols) # returns two objs
xs= np.linspace(0,100, 100) # create take 100 values between 0 100 so 0 -> 100
ys= np.linspace(0,10000, 100) # create take 100 values between 0 10000

# Plot on the same axis

axis1 = axs
axis1.plot(xs,np.sin(ys * 2 * np.pi))
axis1.plot(np.cos(xs * 0.1 * np.pi ** 2))

axis1.set_title("Example Of Two Graphs") # title for the axis
axis1.set_xlabel("Sets the X Values automatically") # x label
axis1.set_ylabel("Sets the Y Values automatically as well!") # y label
axis1.legend(["Plot 1 Blue","Plot 2 Orange"],loc="upper right",title="Title Legend for Chart") 
axis1.grid(color='black',linestyle='-', linewidth=0.05) # A grid for easier reading

Colors

How about changing the color of the plots? I’m not a huge fan of the plot colors. I prefer gradients, so let’s try and change that.

Here’s a list of gradients and colors we can use and map

rows = 1
cols = 1

import matplotlib.colors as colors # Need for normalizing the colors

# We create a function that will create a color gradient 
def create_color_map(cmap_string="viridis",number_of_colors=10):
    color_curves = [i for i in range(number_of_colors)]
    normal = colors.Normalize(vmin=0,vmax=color_curves[-1])
    cmap = plt.get_cmap(cmap_string)
    scalar_map = plt.cm.ScalarMappable(norm=normal, cmap=cmap)
    colors_array = [scalar_map.to_rgba(i) for i in range(number_of_colors)]
    return colors_array

fig, axs = plt.subplots(rows,cols) # returns two objs

xs= np.linspace(0,10, 100)
ys= np.linspace(0,10, 100)
axis1 = axs
color_plots = []

number_of_colors = 10
color_map = create_color_map(number_of_colors=number_of_colors)

for i in range(number_of_colors):
    color_plots.append(i)
    axis1.plot(xs,np.sin(ys+i * 2 * np.pi) + i,color=color_map[i])

axis1.set_title("Example Of Color from Colors Graphs")
axis1.set_xlabel("X Values")
axis1.set_ylabel("Y Values")

axis1.legend(color_plots,loc="upper right",title="Colors Chart") 

axis1.grid(color='black',linestyle='-', linewidth=0.05) 

How about multiple axes inside a figure?

rows = 2
cols = 2

# Use oop methods
fig, axs = plt.subplots(rows,cols)

fig.tight_layout() # Fix issue with plots being too close to each other

xs = np.linspace(0,10,100)
ys = np.linspace(0,10,100)

color_map = create_color_map(number_of_colors=4) 
for idx, axis in enumerate(axs.reshape(-1)): # turn it into a list you can also access via axs[0,0], axs[0,1], axs[1,0], axs[1,1]
    axis.plot(xs + idx, np.cos(ys + 5 + idx * 2 * np.pi) + idx, color=color_map[idx])
    title = "{0}".format(idx)
    axis.set_title(title)
    
axs[0][0].scatter(np.random.random(1000),np.random.random(1000),color = color_map[0])
axs[0][1].scatter(np.random.random(1000),np.random.random(1000),color = color_map[1])
axs[1][0].scatter(np.random.random(1000),np.random.random(1000),color = color_map[2])
axs[1][1].scatter(np.random.random(1000),np.random.random(1000),color = color_map[3])

You can find more about plots in general from here in the Plots

This was a short article to help you get into the workflow of creating charts! Hope this helps!