Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • P purr-data
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 362
    • Issues 362
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 54
    • Merge requests 54
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Jonathan Wilkes
  • purr-data
  • Issues
  • #305

Closed
Open
Created Apr 05, 2017 by Esa Ruoho@esaruoho

OSX: hatched GOP array-update will cause audio dropouts

I discovered something really awkward after doing abstractions for a 8-part-looper..

I'll try and explain it somehow.

if you have a main.pd that has a subpatch with a GOP, and that subpatch has 8 Abstractions (one GOP each).. then every time an array is written to (in one of the 8 abstractions, inside the subpatch), the time the graph-on-parent updates (this is 1 graph-on-parent to main.pd, and that 1gop comprises of 8gop's from 8 abstractions), the audio will drop for a small amount of time. if i then normalize the array content, there will be a dropout too. it's pretty harsh.

i was tearing my hair out (got a gig to play tomorrow).. but then i thought, what if i don't need a subpatch at all, what if i just load the 8 abstractions (8 GOPs, really), directly into the main.pd file, will that cause audio dropouts too?

and you know what, there were no audio dropouts. so i went from this:

multimagic-sourcenexusturbo_pd__-__Users_esaruoho_Library_Mobile_Documents_com_apple_CloudDocs_pd

to this

multimagic-sourcenexusturbo_optimiz_pd__-__Users_esaruoho_Library_Mobile_Documents_com_apple_CloudDocs_pd

now, i like to run a tight ship (ouch! considering my patching, who would believe me?!.. ok, i like to pretend i run a tight ship), and just wanted to wonder - if i was to make this confidential and reattach the subpatch + abstractions and the main patch, would there be some way of figuring out if maybe purr data is doing something extra cpu heavy (when showing a GOP of 8 GOPs) - or should i just continue saving for a new machine?

Assignee
Assign to
Time tracking