Your SlideShare is downloading. ×
  • Like
Py game talk
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply


  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Embedded Real Time Audio Scripting Or: Python Abuse
  • 2. Scripting in Music
    • Respond to MIDI Events (via callback)
    • Audio Rate VS Control Rate
    • Control Rate Processing IN Audio Rate
    • Callback Example:
      • def onMidiMessage(args):
      • m = args[‘midi’]
      • print m.getNoteNumber()
  • 3. Practical Uses
    • Performance Effects
      • Chord Builder
      • Delay (Echo)
      • Arpeggiator
    • Reproducing Real Instruments
      • Repetition
      • Overtones (f.ex. Piano)
      • Portamento
  • 4. Realtime Concepts
    • No blocking allowed!
    • But what is blocking?
    • “ Realtime safe” message queues
    • OK & Not OK code blocks
      • OK: basic logic, simple API
      • NOT OK: time.wait(), disk IO, recursion
    • Avoid bottlenecks with Async processing
  • 5. “ Safe” For Audio Work
    • Conceptual Requirements
      • Perfect theoretical reliability
      • Absolutely no blocking
      • High performance caching
      • Blah blah blah
    • Actual Requirements
      • Audio just needs to sound good
      • Video just needs to look good
  • 6. “Safe” For Audio Work
    • “ Python is not safe for realtime work”
      • Wait, what?!?
      • A common phrase, but what does it mean?
      • Calls to malloc/free are “slow”
      • Global Interpreter Lock effectively disables true multithreading
      • But a fast malloc / free combination helps
      • A single script thread or process doesn’t need the GIL, so it relies soley on language speed
  • 7. “Safe” For Audio Work
    • Empirical Evidence (drum roll…)
      • Python is fast!
      • Shark Profile (PyEval_EvalFrame: 0.4%)
      • The GIL SUCKS! (only at low latencies)
      • Troubleshooting:
        • Comment out code
        • Comment out API calls
        • Disable scripting all together
  • 8. App / Engine Separation
    • Basic audio app: (2 Threads)
      • Thread 1: Application GUI
      • Thread 2: Audio Engine
    • Advanced mixing app (n Threads):
      • Thread 1: Application GUI
      • Thread 2: Audio Engine (Track 1)
      • Thread n: Audio Engine (Track n)
  • 9. Audio or Scripting Thread?
    • Sync VS Async Processing
      • Sync: Python IN audio thread
      • Async: Python in own thread
      • Async processing opens possibilities for easy refactoring for proc migration
    • Engine “performance paranoia”
      • Audio code is hard to debug
      • Avoid blame from managers who love freaking out
  • 10. Audio or Scripting Thread?
    • Solution: Moving to one new thread
      • Move burden of poor performance to scripting accuracy, not audio quality
      • Avoids “performance paranoia”
    • Solution: Moving to many new processes
      • One (thin) scripting daemon per audio thread, with lock-step processing
      • Great idea, difficult implementation
      • Burdened by IPC overhead, complex proc mgmt
      • Google Chrome, AJAX, HTML5
  • 11. Multiprocessing Caveats
    • Increased Performance means:
      • Decreased Latency
      • Code speed is key
      • GIL competition comes back to haunt you