This is truly odd. I don’t have easy means to test it. I don’t know why it wouldbe broken dependent on the dac, however. For fun you might try something like this, just to verify that the valueAt() function is what’s busted. SndBuf s => blackhole; “Fred.wav” => s.read; while (s.pos() < s.samples()) { <<< s.last() >>>; samp => now; } PRC
On Apr 19, 2020, at 9:00 AM, chuck-users-request@lists.cs.princeton.edu wrote:
Send chuck-users mailing list submissions to chuck-users@lists.cs.princeton.edu
To subscribe or unsubscribe via the World Wide Web, visit https://lists.cs.princeton.edu/mailman/listinfo/chuck-users or, via email, send a message with subject or body 'help' to chuck-users-request@lists.cs.princeton.edu
You can reach the person managing the list at chuck-users-owner@lists.cs.princeton.edu
When replying, please edit your Subject line so it is more specific than "Re: Contents of chuck-users digest..."
Today's Topics:
1. sndBuf.valueAt (Forrest Curo)
----------------------------------------------------------------------
Message: 1 Date: Sun, 19 Apr 2020 07:30:15 -0700 From: Forrest Curo
To: ChucK Users Mailing List Subject: [chuck-users] sndBuf.valueAt Message-ID: Content-Type: text/plain; charset="utf-8" Using chuck linux-jack this gives me reasonable numbers between -1 and 1. Using chuck linux-alsa I'm able to play the file I've read into sndBuf; but trying to copy it via .valueAt gives absurdly high ["out of range"] numbers at each point. [It can be a different high number different times I run chuck, but the number it is turns up at every point I sample.]
Is there a fix for this? Aside from using jack on a computer where it befnurgles the midi?