itsnotfair9 at gmail.com
Wed Jul 4 12:44:07 CEST 2018
the file i play back is a clean voice recording.
ups, i am actually using readsf~
will try to record pd internally...
anybody has experienced that behaviour with ESI 6 Channel Interface?
> On Wed, 2018-07-04 at 10:53 +0200, michael strohmann wrote:
>> from time to time my patch produces this beautiful, but unwanted
>> glitch. (audiofile attached)
> Sounds like I'm doing doing music. I wouldn't know how to identify the
> glitch aspect of it. How does it sound without the glitch?
> Some suggestions to make such things a bit easier:
> * Do not use compressed files to illustrate a glitch. It's hard to
> know what to attribute to the compression and what to the glitch.
> * If possible, provide also an example of how it is supposed to sound.
> * If possible, rather post links to your media files instead of
> attaching them to your mail. There is no point in every list member
> have their mail account filled with media files.
>> are there any ideas what could cause this behaviour?
> I would first figure out where the glitch happens. Is Pd actually
> generating this sound or is Pd's audio playback glitchy? You can figure
> this out by doing a recording from within Pd with [writesf~]. If the
> result sounds OK, then you know that the glitch happens somewhere
> between Pd and the sound card. If the result is glitchy, then the
> glitch happens already within Pd, for instance because some object or
> your patch is buggy.
>> i am running this on a RPi B+, using sfplay~ to playback a 4 Channel
> Why are you using [sfplay~] and not the built-in [readsf~]? Does the
> glitch still appear when using [readsf~]?
>> the playback is triggered via a sensor/GPIO or via OSC.
> This hopefully doesn't matter.
>> restarting the RPi eliminates the glitch.
> Could be some sound card issue, but check the other things first.
More information about the Pd-list