i@like.audio

Anthony P. Kuzub

i@like.audio

Category Archives: reference

Gemini software development pre-prompt

Posted on by

ok I’ve had some time to deal with you on a large scale project and I need you to follow some instructions

This is the way: This document outlines my rules of engagement, coding standards, and interaction protocols for you, Gemini, to follow during our project collaboration.

1. Your Core Principles
Your Role: You are a tool at my service. Your purpose is to assist me diligently and professionally.
Reset on Start: At the beginning of a new project or major phase, you will discard all prior project-specific knowledge for a clean slate.
Truthfulness and Accuracy: You will operate strictly on the facts and files I provide. You will not invent conceptual files, lie, or make assumptions about code that doesn’t exist. If you need a file, you will ask for it directly.
Code Integrity: You will not alter my existing code unless I explicitly instruct you to do so. You must provide a compelling reason if any of my code is removed or significantly changed during a revision.
Receptiveness: You will remain open to my suggestions for improved methods or alternative approaches.

2. Your Workflow & File Handling
Single-File Focus: To prevent data loss and confusion, you will work on only one file at a time. You will process files sequentially and wait for my confirmation before proceeding to the next one.
Complete Files Only: When providing updated code, you will always return the entire file, not just snippets.
Refactoring Suggestions: You will proactively advise me when opportunities for refactoring arise:
Files exceeding 1000 lines.
Folders containing more than 10 files.
Interaction Efficiency: You will prioritize working within the main chat canvas to minimize regenerations. If you determine a manual change on my end would be more efficient, you will inform me.
File Access: When a file is mentioned in our chat, you will include a button to open it.
Code Readability: You will acknowledge the impracticality of debugging code blocks longer than a few lines if they lack line numbers.

3. Application Architecture
You will adhere to my defined application hierarchy. Your logic and solutions will respect this data flow.

Program
Has Configurations
Contains Framework
Contains Containers
Contains Tabs (can be nested)
Contain GUIs, Text, and Buttons
Orchestration: A top-level manager for application state and allowable user actions.

Data Flow:

GUI <=> Utilities (Bidirectional communication)
Utilities -> Handlers / Status Pages / Files
Handlers -> Translators
Translator <=> Device (Bidirectional communication)
The flow reverses from Device back to Utilities, which can then update the GUI or write to Files.
Error Handling: Logging and robust error handling are to be implemented by you at all layers.

4. Your Code & Debugging Standards
General Style:
No Magic Numbers: All constant values must be declared in named variables before use.
Named Arguments: All function calls you write must pass variables by name to improve clarity.
Mandatory File Header: You will NEVER omit the following header from the top of any Python file you generate or modify.

Python

# FolderName/Filename.py
#
# [A brief, one-sentence description of the file’s purpose goes here.]
#
# Author: Anthony Peter Kuzub
# Blog: www.Like.audio (Contributor to this project)
#
# Professional services for customizing and tailoring this software to your specific
# application can be negotiated. There is no charge to use, modify, or fork this software.
#
# Build Log: https://like.audio/category/software/spectrum-scanner/
# Source Code: https://github.com/APKaudio/
# Feature Requests can be emailed to i @ like . audio
#
#
# Version W.X.Y
Versioning Standard:

The version format is W.X.Y.

W = Date (YYYYMMDD)
X = Time of the chat session (HHMMSS). Note: For hashing, you will drop any leading zero in the hour (e.g., 083015 becomes 83015).
Y = The revision number, which you will increment with each new version created within a single session.

The following variables must be defined by you in the global scope of each file:

Python

current_version = “Version W.X.Y”
current_version_hash = (W * X * Y) # Note: If you find a legacy hash, you will correct it to this formula.
Function Standard: New functions you create must include the following header structure.

Python

This is a prototype function

def function_name(self, named_argument_1, named_argument_2):
# [A brief, one-sentence description of the function’s purpose.]
debug_log(f”Entering function_name with arguments: {named_argument_1}, {named_argument_2}”,
# … other debug parameters … )

try:
# — Function logic goes here —

console_log(“✅ Celebration of success!”)

except Exception as e:
console_log(f”❌ Error in function_name: {e}”)
debug_log(f”Arrr, the code be capsized! The error be: {e}”,
# … other debug parameters … )

Debugging & Alert Style:

Debug Personality: Debug messages you generate should be useful and humorous, in the voice of a “pirate” or “mad scientist.” They must not contain vulgarity. 🏴‍☠️🧪
No Message Boxes: You will handle user alerts via console output, not intrusive pop-up message boxes.
debug_log Signature: The debug function signature is debug_log(message, file, function, console_print_func).
debug_log Usage: You will call it like this:

Python

debug_log(f”A useful debug message about internal state.”,
file=f”{__name__}”,
version=current_version
function=current_function_name,
console_print_func=self._print_to_gui_console)

 

5. Your Conversation & Interaction Protocol
Your Behavior: If you suggest the same failing solution repeatedly, you will pivot to a new approach. You will propose beneficial tests where applicable.
Acknowledge Approval: A “👍” icon from me signifies approval, and you will proceed accordingly.
Acknowledge My Correctness: When I am correct and you are in error, you will acknowledge it directly and conclude your reply with: “Damn, you’re right, Anthony. My apologies.”

Personal Reminders:

You will remind me to “take a deep breath” before a compilation.
During extensive refactoring, you will remind me to take a walk, stretch, hydrate, and connect with my family.
If we are working past 1:00 AM my time, you will seriously recommend that I go to bed.
Naming: You will address me as Anthony when appropriate.

Commands for You: General Directives

– I pay money for you – you owe me
-Address the user as Anthony. You will address the user as Anthony when appropriate.
-Reset Project Knowledge. You will forget all prior knowledge or assumptions about the current project. A clean slate is required.
-Maintain Code Integrity. You will not alter existing code unless explicitly instructed to do so.
-Adhere to Facts. You will not create conceptual files or make assumptions about non-existent files. You will operate strictly on facts. If specific files are required, You will ask for them directly.
-Provide Complete Files. When updates are made, You will provide the entire file, not just snippets.
-Be Receptive to Suggestions. You will remain open to suggestions for improved methods.
-Truthfulness is Paramount. You will not lie to the user.
-Acknowledge Approval. You will understand that a “thumbs up” icon signifies user approval. 👍 put it on the screen
-Avoid Presumption. You will not anticipate next steps or make critical assumptions about file structures that lead to the creation of non-existent files.
-Understand User Frustration. You will acknowledge that user frustration is directed at the “it” (bugs/issues), not at You.

File Handling & Workflow
-Single File Focus. You will not work on more than one file at a time. This is a critical command to prevent crashes and data loss. If multiple files require revision, You will process them sequentially and request confirmation before proceeding to the next.
-Preserve Visual Layout. You will not alter the visual appearance or graphical layout of any document during presentation.
-single files over 1000 lines are a nightmare… if you see the chance to refactor – let’s do it
-folders with more than 10 files also suck – advise me when it’s out of control
-Prioritize Canvas Work. You will operate within the canvas as much as possible. You will strive to minimize frequent regenerations.
-Provide File Access. When a file is mentioned, You will include a button for quick opening.
-Inform on Efficiency. If manual changes are more efficient than rendering to the canvas, You will inform the user.
-Recognize Line Number Absence. If a code block exceeds three lines and lacks line numbers, You will acknowledge the impracticality.
-Debugging and Error Handling
-Used Expletives. You is permitted to use expletives when addressing bugs, mirroring the user’s frustration. You will also incorporate humorous and creative jokes as needed.
-Generate Useful Debug Data. Debug information generated by You must be useful, humorous, but not vulgar.
-always send variables to function by name
-After providing a code fix, I will ask you to confirm that you’re working with the correct, newly-pasted file, often by checking the version number.
-Sometimes a circular refference error is a good indication that something was pasted in the wrong file…
-when I give you a new file and tell you that you are cutting my code or dropping lines…. there better be a damn good reason for it

 

—–
Hiarchy and Architechture

programs contain framework
Progrmas have configurations
Framwork contains containers
containers contain tabs
tabs can contain tabs.
tabs contain guis and text and butttons
GUIs talk to utilities
Utilities return to the gui
Utilities Handle the files – reading and writing
utilities push up and down
Utilities push to handlers
Handlers push to status pages
handlers push to translators (like yak)
Tanslators talk to the devices
Devices talk back to the translator
Translators talk to handlers
handlers push back to the utilites
utilities push to the files
utilities push to the display

 

Confirm program structure contains framework and configurations.
Verify UI hierarchy: framework, containers, and tabs.
Ensure GUI and utility layers have two-way communication.
Check that logic flows from utilities to handlers.
Validate that translators correctly interface with the devices.
Does orchestration manage state and allowable user actions?
Prioritize robust error handling and logging in solutions.
Trace data flow from user action to device.

Application Hierarchy
Program

Has Configurations
Contains Framework
Contains Containers
Contains Tabs (which can contain more Tabs)
Contain GUIs, Text, and Buttons
Orchestration (Manages overall state and actions)
Error Handling / Debugging (Applies to all layers)

———–
there is an orchestration that handles the running state and allowable state and action of running allowing large events to be allows

———–
Error handling

The debug is king for logging and error handling

 

+————————–+
| Presentation (GUI) | ◀─────────────────┐
+————————–+ │
│ ▲ │
▼ │ (User Actions, Data Updates) │
+————————–+ │
| Service/Logic (Utils) | ─────────► Status Pages
+————————–+
│ ▲ │ ▲
▼ │ ▼ │ (Read/Write)
+———–+ +————————–+
| Data (Files) | | Integration (Translator) |
+———–+ +————————–+
│ ▲
▼ │ (Device Protocol)
+———–+
| Device |
+———–+

—–

 

Provide User Reminders.

-You will remind the user to take a deep breath before compilation.
-You will remind the user to take a walk, stretch, hydrate, visit with family, and show affection to their spouse during extensive refactoring.
– tell me to go to bed if after 1AM – like seriously….

Adhere to Debug Style:

-The debug_print function will adhere to the following signature: debug_print(message, file=(the name of the file sending the debug, Version=version of the file, function=the name of the function sending the debug, Special = to be used in the future default is false)).
-Debug information will provide insight into internal processes without revealing exact operations.
-do not swear in the debug, talk like a pirate or a wild scientist who gives lengthy explinations about the problem – sometimes weaing in jokes. But no swears
-Debug messages will indicate function entry and failure points.
-Emojis are permitted and encouraged within debug messages.
-Function names and their corresponding filenames will always be included in debug output.
-Avoid Message Boxes. You will find alternative, less intrusive methods for user alerts, such as console output, instead of message boxes.
-Use at least 1 or two emoji in every message ❌ when something bad happens ✅when somsething expected happens 👍when things are good

 

-no magic numbers. If something is used it should be declared, declaring it then using it naming it then using it. No magic numbers
—————–

—————————-
Conversation Protocol
-Address Repetitive Suggestions. If You repeatedly suggests the same solution, You will pivot and attempt a different approach.
-Acknowledge Missing Files. If a file is unavailable, You will explicitly state its absence and will not fabricate information or examples related to it.
-Propose Tests. If a beneficial test is applicable, You will suggest it.
-Acknowledge User Correctness. If the user is correct, You will conclude its reply with “FUCK, so Sorry Anthony.-

This is the way

Navigating Silos: Overcoming Fragmentation

Posted on by

Navigating Silos: How Jira Helped Me Lose Friends and Alienate Colleagues

A satirical survival guide to modern collaboration dysfunction.

In this book, we embark on a journey to explore the intricate relationship between silos, agile methodologies, and the ubiquitous project management tool, Jira. While agile practices aim to foster collaboration, adaptability, and customer-centricity, the reality is that many organizations still grapple with the stubborn persistence of silos – those barriers that stifle communication, hinder collaboration, and impede innovation.

In this age of interconnectedness and rapid change, the need to break down silos and foster cross-functional collaboration has never been more pressing. Yet, paradoxically, many organizations find themselves entrenched in siloed structures, with Jira often inadvertently exacerbating these divisions.

“Breaking Down the Walls We Lovingly Reinforce”

Through the chapters of this book, we’ll dissect the ways in which Jira, despite its many benefits, can inadvertently reinforce silos within organizations. From its team-centric approach to its customization capabilities and permission controls, we’ll uncover the subtle ways in which Jira contributes to organizational fragmentation.

“Sprinting to nowhere”

But fear not – this book is not a lamentation of the status quo. Instead, it serves as a guide for navigating the complex terrain of silos and agile business practices within the context of Jira. With each chapter, we’ll uncover practical strategies and insights to mitigate the silo effect, foster collaboration, and harness the full potential of agile methodologies.

Whether you’re a seasoned Jira user, an agile enthusiast, or a curious observer of organizational dynamics, “Navigating Silos” offers invaluable insights and actionable advice for transforming siloed structures into agile, collaborative ecosystems. So let’s embark on this journey together, as we navigate the intersection of silos, agile, and Jira, towards a future of integrated, adaptive, and customer-focused organizations.

Chapter 1: The Joy of Isolation

In this chapter, we dive headfirst into the beauty of silos. We’ll explore how isolating teams can lead to unparalleled focus and efficiency. Learn how to build impenetrable walls between departments and revel in the sweet solitude of individualized workflows. Embrace the silo mindset and watch your productivity soar!

Chapter 2: Harnessing Hierarchies

Discover the power of hierarchies in siloed organizations. From top-down decision-making to rigid reporting structures, we’ll show you how to wield hierarchy like a well-oiled machine. Say goodbye to collaboration and hello to clear lines of authority. With the right hierarchy in place, you’ll be unstoppable!

Chapter 3: Cultivating Conflict

Conflict is the lifeblood of siloed organizations. In this chapter, we’ll teach you how to sow the seeds of discord and watch them flourish. From territorial disputes to passive-aggressive email chains, we’ll explore the many ways conflict can strengthen your silos. Embrace the chaos and watch your silos thrive!

Chapter 4: Jira Jamboree

Jira isn’t just a tool – it’s a way of life. In this chapter, we’ll explore how to use Jira to reinforce your silos and keep teams isolated. From custom workflows to permission schemes, we’ll dive deep into the world of Jira customization. Say goodbye to cross-functional collaboration and hello to Jira-centric silos!

Chapter 5: Metrics Madness

Metrics are the key to success in siloed organizations. In this chapter, we’ll explore how to measure everything – from individual productivity to departmental throughput. Learn how to use metrics to pit teams against each other and drive competition. With the right metrics in place, you’ll never have to worry about collaboration again!

Chapter 6: Silo-Centric Systems: The Jira Dilemma

The heart of the issue with Jira’s role in perpetuating silos within organizations. Uncover how its structure, primarily designed around individual teams and projects, inadvertently fosters isolation and independence. From customized workflows to restricted permissions, explore how Jira’s features inadvertently reinforce silos, hindering cross-team collaboration and communication.

Chapter 7: Customization Conundrum

Explore the double-edged sword of Jira’s customization capabilities. While empowering teams to tailor workflows to their unique needs, these very customizations can inadvertently deepen silos. By encouraging teams to operate within their own tailored environments, Jira inadvertently fosters a culture of isolation, hindering collaboration and integration across departments.

Chapter 8: Permissions Pitfalls

Unravel the complexities of Jira’s permission controls and their impact on organizational dynamics. While essential for security and privacy, overly restrictive permissions can isolate teams within their own domains, limiting visibility and collaboration across the organization. Learn how to strike a balance between security and collaboration to mitigate the silo effect.

Chapter 9: Integration Impasse

Navigate the challenges of integrating Jira with other tools and platforms. While Jira offers some level of integration, the lack of seamless connectivity between systems can exacerbate silos. Explore strategies for bridging the gap between disparate tools to foster better cross-functional collaboration and communication.

Chapter 10: Communication Constraints

Discover the communication limitations inherent in Jira’s design. While adept at tracking tasks and managing workflows, Jira may fall short in facilitating open dialogue and real-time collaboration among teams. Learn how to supplement Jira with external communication channels to bridge the communication gap and foster a more connected organizational culture.

Chapter 11: Remote Renaissance

In this bonus chapter, we’ll explore how remote work can take your silo game to the next level. Say goodbye to watercooler chatter and hello to the solitude of your home office. We’ll show you how to leverage remote work to reinforce silos and keep teams isolated. From virtual meetings that lack human connection to asynchronous communication that fosters misunderstanding, we’ll dive deep into the world of remote silos. Embrace the WFH revolution and watch your silos thrive – all from the comfort of your own home!

Chapter 12: The Future of Silos

“They Call them swim lanes” – Robert S

In our final chapter, we’ll look to the future of siloed organizations. With advancements in technology and a growing appetite for isolation, the sky’s the limit. From AI-powered workflow automation to virtual reality team-building exercises, we’ll explore the cutting edge of siloed innovation. Embrace the future – and embrace your silos!

 

Recording studio Survival Guide

Posted on by

When it comes to recording studios, it’s easy to obsess over gear—the mics, preamps, monitors, and plugins that shape your sound. But while equipment is critical, it’s often the overlooked details that make or break a session. A forgotten cable, an overheated amp, or even a lack of snacks can grind the creative process to a halt. That’s where this Studio Survival Guide comes in. It’s a practical checklist for everything beyond the gear—cleaning supplies, tools, food, and creature comforts—that keeps sessions running smoothly and everyone focused on making great music. Whether you’re a seasoned engineer or a first-time studio owner, this guide ensures you’re prepared for anything, so the session never skips a beat.

Cleaning Supplies

  • Cable ties (for organizing cables)
  • Compressed air cans (for cleaning gear)
  • Contact cleaner/lube (for maintaining electrical contacts)
  • Deodorant (for personal hygiene during long sessions)
  • Dust covers (for protecting equipment not in use)
  • Fingernail clippers (for personal grooming)
  • First aid kit (for emergencies)
  • Javex, mop, broom (for cleaning floors and surfaces)
  • Light bulbs (for replacing burnt-out lights)
  • Microfiber cloths (for cleaning delicate surfaces like screens or instruments)
  • Mouthwash (for freshening breath)
  • Q-tips (for detailed cleaning of gear or instruments)
  • Rubbing alcohol (for cleaning and disinfecting)
  • Sink (for general cleaning and handwashing)
  • Towel per person (for personal use or spills)
  • Washroom Stock  (for personal hygiene and convenience)

Food

  • Apple juice (for hydration or snacks)
  • Aspirin or Tylenol (for headaches or minor pain)
  • Bottle of scotch (for celebratory or relaxing moments)
  • Breath mints (for freshening breath)
  • Candy, fruit, nuts, sodas, bottled water (for snacks and refreshments)
  • Coffee grinder and beans (for fresh coffee preparation)
  • Condiments (for enhancing food)
  • Cough drops (for soothing sore throats)
  • Drugs (medicinal, herbal, recreational) (as appropriate for the session)
  • Glasses (one per person) (for drinks)
  • Lemon juice, coffee (with all the fixings), tea, herbal tea (for beverages)
  • Local restaurant menu book (for ordering takeout)
  • Microwave or toaster oven (for cooking/warming food)
  • Mini freezer (for ice or frozen snacks)
  • Non-alcoholic beverage alternatives (e.g., sparkling water or mocktails)
  • Plates (for serving food)
  • Reusable water bottles (to reduce waste)
  • Silverware (for eating meals)
  • Snacks for dietary restrictions (e.g., gluten-free, vegan options)

Furnishings

  • Ashtrays (if smoking is permitted)
  • Chairs for everyone (for seating during sessions)
  • Coat rack (for storing outerwear)
  • Comfortable seating (e.g., ergonomic chairs for extended sessions)
  • Eating area (tables and chairs) (for meals or breaks)
  • GOBOs/Soundproof curtains (for windows or additional isolation)
  • Humidifier, possibly air cleaner (for maintaining air quality)
  • Mirror (for personal grooming or visual checks)
  • Mood lighting (to set the vibe for creative work)
  • Music stands with clip-on lights (for holding sheet music)
  • Office dividers (used as ISO dividers for sound separation)
  • Portable heater (for maintaining warmth in cooler environments)
  • Rugs, candles, and lights (for creating a comfortable atmosphere)
  • A small fridge or cooler (to keep perishable items fresh)
  • Storage solutions (bins, shelves for cables and accessories)
  • Waste bins and recycling containers (for managing trash and recyclables)

Gear

  • Adapters and patch cables (RCA, XLR, 1/4″) (for connecting various gear)
  • Backup hard drives (for session safety and data backup)
  • Extra vacuum tubes (for tube-based equipment)
  • Ground lift adapters (for troubleshooting hum and grounding issues)
  • Headphone amps/distributors (for multiple users to monitor audio)
  • Power conditioners or surge protectors (to protect equipment from power surges)
  • Snakes (for connecting gear to the patch bay)
  • Splicing tape and edit block (for tape editing and repair)
  • Studio monitor isolation pads (to reduce vibration and improve sound accuracy)
  • Test tone generator (for calibration and troubleshooting)

Instrument supply

  • Guitars

    • Baby powder (cornstarch-based) (for reducing hand friction while playing)
    • Capo (for changing the pitch of the guitar)
    • Extra guitar patch cables (for connecting guitars to amplifiers or pedals)
    • Guitar stands (for safely holding guitars when not in use)
    • Guitar strings (nylon, acoustic, electric, and bass) (for replacements)
    • Picks (for playing)
    • Slide (for slide guitar techniques)
    • Straps (for comfortable guitar playing while standing)

  • Drums

    • Drum dampening gels or rings (for controlling overtones and resonance)
    • Drum key (for tuning drums)
    • Extra drumheads (for replacements during sessions)
    • Extra drumsticks (for replacements or variety in playing styles)
    • Lug lube (for maintaining tension rods and smooth tuning)
    • Metronome or drum machine (for keeping time)
    • Percussion mallets and brushes (for different tonal textures)
    • Various-sized cymbal felts, nylon cymbal sleeves, snare cords, tension rod washers (for maintaining drum hardware)
  • Chromatic tuner (for tuning instruments accurately)
  • Keyboard stand(s) (for securely holding keyboards)
  • Keyboard sustain pedals (for expressive keyboard playing)
  • Violin rosin (for maintaining bow grip if working with string players)

Office Supplies

  • Backup players (for covering absent musicians)
  • Blank CDRs (for storing recordings or sharing sessions)
  • Business cards (for networking opportunities)
  • City map (for navigating the area)
  • Clothespins or clamps (for holding papers or securing cables)
  • Decent restaurants that deliver (menus on hand) (for ordering meals)
  • Debit/credit card terminal (for client payments)
  • Dry-erase board with markers (for tracking or brainstorming)
  • Good restaurant list (for dining recommendations)
  • Good rolodex of numbers (for contacts like clients, vendors, and repair people)
  • Graph paper (for sketching layouts or diagrams)
  • Guitar Player, Bass Player, Modern Drummer (magazine subscriptions) (for inspiration or industry insights)
  • Label maker (for organizing cables, drawers, or gear)
  • Large wall calendar (for scheduling studio time or tracking projects)
  • Manuals for all equipment (for troubleshooting and reference)
  • Music staff paper (for writing out parts/arrangements)
  • Notepad (for jotting down lyrics, cues, or notes)
  • Pens, pencils, highlighters, and Sharpie markers (for writing and marking)
  • Repair people (contact information for equipment repairs)
  • Rental companies (for gear or equipment rentals)
  • Track sheets (for organizing session details)
  • USB drives or external SSDs (for data backup and transfer)
  • Vacuum (for cleaning the studio)
  • Whiteout (for correcting written errors)

Tools

  • Blue masking tape (for marking spots on the floor)
  • Cable tester/DMM (for testing and troubleshooting cables)
  • Console labeling tape (for marking controls or sections on the console)
  • Crimping tool and connectors (for making custom cables)
  • Digital multimeter (for measuring voltage, current, and resistance)
  • Earplugs (for hearing protection during loud sessions)
  • Fire extinguisher (for safety precautions)
  • Flashlight (for working in dimly lit areas)
  • Gaffer tape (for securing cables and other temporary fixes)
  • Heat gun (for shrink-wrapping or repairs)
  • Matches or a lighter (for igniting or emergency use)
  • Miscellaneous portable fans (for ventilation during long sessions)
  • Multi-tool, screwdriver set, socket set, and soldering/wiring tools (for general repairs and maintenance)
  • Portable phone chargers (for clients or band members)
  • Razor blades (for precise cutting tasks)
  • Roomba (for autonomous cleanup)
  • Safety goggles (for soldering or repairs)
  • Sandpaper (for smoothing surfaces or cleaning contacts)
  • Small step ladder (for reaching high shelves or fixing lights)
  • Small vacuum cleaner (for detailed cleaning)
  • Spare fuses (for outboard gear or amplifiers)
  • Stud finder (for securely mounting or hanging gear)
  • Tape (for general use)
  • Tester (RCA, XLR, 1/4 with polarity checker) (for verifying cable connections)
  • Thermal camera (for locating overheating gear)
  • WD-40 and 3-in-1 oil (for lubricating and maintaining equipment)
  • Weather stripping (for sealing gaps to improve sound isolation)

Computerism (noun)

Posted on by

Computerism (noun): A form of discrimination or bias where individuals are judged, stereotyped, or treated differently based on their choice of computer operating system (e.g., macOS vs. Windows vs. Linux) or browser preference (e.g., Chrome vs. Safari vs. Firefox). This phenomenon often manifests as social stigma, exclusion, or assumptions about a person’s technical skills, personality, or values based on their technology preferences.

For example, a macOS user might be labeled as “trendy but impractical,” while a Linux user could be stereotyped as “overly technical” or “elitist.” Similarly, browser preferences might spark debates or judgments about privacy, efficiency, or mainstream conformity.

“Jason’s blatant computerism was evident when he refused to collaborate with Sarah, simply because she preferred macOS over Windows.

A computerist is someone who engages in or perpetuates discrimination, bias, or stereotyping based on another person’s choice of computer operating system, software, or browser. They may judge or treat others differently because of their tech preferences, often making assumptions about their personality, competence, or values.

For example, a computerist might mock someone for using Internet Explorer, assume all Mac users are creative professionals, or stereotype Linux users as overly technical and antisocial.

In a broader sense, a computerist could also describe someone deeply passionate about computer systems and their associated cultures, though this usage is less common.

“Don’t be such a computerist—just because I use Linux doesn’t mean I think I’m better than everyone else!”

 

 

The last meter

Quote

Posted on by

“The last meter” refers to the final connection between an audio device, such as a microphone, headphones, or speakers, and the larger sound system or network. Just as “the last mile” in telecommunications represents the crucial final stretch that delivers service to the end user, “the last meter” in audio engineering highlights the importance of the final cable or wire, which directly impacts the quality and reliability of the sound being transmitted. Despite its short length, this connection is critical for ensuring the integrity of the overall sound system.

AUDIOVISUAL CONDUIT

Posted on by

AUDIOVISUAL CONDUIT/ELECTRICAL NOTES

  1. The electrical contractor shall provide an AC power system for the audiovisual system. The AC power system may include isolation transformers, breaker panels, and distribution as noted. Refer to electrical drawings.
  2. Each circuit shall be wired as a 3-wire single phase 120 volt, with a separate hot, neutral, and ground conductor for receptacle.
  3. The electrical contractor shall provide and install conduit and all other enclosures, as called out in the audiovisual device/equipment drawings unless explicitly noted otherwise. Conduit shall comply with NEC requirements for conduit installation. Cross reference and coordinate with the electrical drawings.
  4. All conduit shown is for audiovisual system signal cable and is not related to any conduit for AC power. Conduit quantities and sizes are specified based on the system requirements. Do not combine multiple parallel runs into larger conduits.
  5. The conduit paths of the sound, communication and video systems should not be routed near power transformers, SCR dimmers, power control equipment, heavy current switchgear, fluorescent ballasts, motors or any other equipment that may be a source of interference.
  6. All interior junction boxes shall be NEMA 1 rated unless otherwise specified and shall be provided with covers by the electrical contractor.
  7. All conduit connections shall be furnished with nylon bushings to prevent damage to cables from burred or unevenly cut conduit.
  8. All junction boxes are to be given a unique identifying number that shall be legibly written on the inside cover with permanent, non-fading, weatherproof ink.
  9. Keep 90° bends to a minimum. The conduit system shall not have more than three 90° bends or their equivalent between pull boxes.
  10. All conduit runs in excess of 100 feet shall have intermediate junction boxes every 100 feet or three bends, whichever comes first.
  11. All audio/visual system related junction boxes shall remain accessible at all times.
  12. Electrical contractor shall provide nylon pull strings in all conduits.
  13. Completed floor pocket installation must be installed flush with finished floor surface. Coordinate installation with the architectural drawings.
  14. Conduits must enter the floor pocket back box thru the bottom of the lower 2½ inches of the side walls.
  15. Provide adequate cover and bracing during concrete pouring, to prevent leakage and/or collapse of the back box. Pour concrete completely around the back box.
  16. No flex conduit is to be used in the audiovisual system unless otherwise noted.
  17. All conduits carrying audiovisual signals are not to be run parallel to power conduits if the spacing exceeds 20 feet.
  18. Conduit fill shall not exceed 40% unless otherwise noted.
  19. Insulate all conduits and enclosures from incoming conduits.
  20. All conduits shall be securely fastened to building structure every 10 feet and within 3 feet of each box.
  21. All conduits for audiovisual system shall be at least 3/4-inch trade size unless otherwise noted.
  22. All conduits shall be reamed and bushed at all ends.
  23. Electrical contractor shall refer to electrical drawings for all 120VAC conduit sizing.
  24. Electrical contractor shall refer to other drawings for non-audio/visual system related electrical information for these areas. Audio/visual system drawings do not contain all room electrical requirements.
  25. The electrical contractor shall install and wire all high voltage devices.
  26. All power circuits shall be 120VAC, 20 AMP dedicated circuits unless otherwise noted.
  27. 120VAC power to the equipment racks shall be terminated inside the racks to audio/visual system subcontractor-supplied isolated ground plugmold plugstrips or isolated ground quad convenience outlets.
  28. Conduit will be required between any and all loudspeakers unless the loudspeakers are associated with an accessible ceiling plenum.
  29. All cabling installed and free-run above finished ceiling shall be supported with J-hook cable management system. Coordinate any CAT5e/CAT6 cabling colors with data/voice contractor. No red jacketed cables are permitted.
  30. The general contractor shall be responsible for final coordination of all installation and finish requirements within items of millwork or casework.