I want to read a signal stream, and conditionally alter the value of individual samples coming through before writing to an array. Right now I am doing a [snapshot~] at the sample rate and multiplying by 1 or 0, depending on whether it is above a threshold value, and banging a [tabwrite] at the sample rate to write to the array. It works but this all seems clumsy; is there a way to let the signal remain a signal but intercept and manipulate it at the sample level?

I tried to make a [fexpr~ $x1# > ] but no such object seems to exist

Hey guys, I have a patch set up to load audio files using [soundfiler]. I'm using it to play with my loop library which has .aiff files, some of which are 16-bit, others 24- or 32-bit (yeah I know, crappy organization...) The 16-bit files work in my patch but the other ones do not. Is there a way to make the 24- and 32-bit files work with [soundfiler]? I imagine it has something to do with the -raw tag but I don't really understand how that works from the help file?

Hey guys, been lurking here a few weeks and posting for the first time. I'm trying to set up a patch such that I can run multiple instances of it at the same time without references getting mixed up. It's working out except for one detail: there is an array used for control in the main window of the patch I want to rename for every instance of the patch that I open. I'm trying to do this by calling it "g1" and then using

[loadbang]
|
[symbol $0-control]
|
[g1 rename $1(

to rename it as "1022-control" (or whatever) each time I open the patch. Thus if I open each instance of the patch one at a time, each array should have its own "10xx-control" name. This works EXCEPT: if I save the patch after opening and changing the array name, the array name gets saved as "1022-control" and the next time I open the patch I will get the obvious "error: no such array g1" error, as that array is stuck on the last $0 value before saving while everything else has updated!

Are there any workarounds for this, besides renaming the array to "g1" every time I change something with the patch and want to save? I also have an array I'm using as a buffer that gets renamed fine because it is in a

Hi, I am currently working on a timestretching/pitchshifting loop player based on this 2-grain implementation. My problem is I can always hear the frequency of the grains themselves in a sort of amplitude modification effect, even though the second grain is out of phase to fill up the empty spaces in the first one. With longer grains it sounds like a tremolo, with shorter it sounds like a ring mod. Changing the window shape doesn't seem to help.

Is there any way to make this effect go away?

As I understood from the [expr~] help files, [expr~] and $v1 (etc.) evaluated the signal each block instead of each sample, or is that wrong?

Are you trying to emulate a pedal such as, say, the Ibanez DE7 delay? I have one and am pretty familiar with how the delay time sweep trick sounds on that pedal.

It's very analog-sounding for a digital delay, so I threw together something based on my very rudimentary knowledge of how bucket brigade analog delays work. I used 5 different delwrite~ and vd~ pairs and modulate the delay times of all vd~s simultaneously. That basically does the simultaneously shifting reading and writing heads thing you talked about (I think?) I also put a filter in the feedback loop to emulate the signal decay in an analog delay. I still hear the ramp-up between frequencies with each echo but it seems to be blurred somewhat. This is as close as I can get to the DE7 right now.

Edit: changed it to 10 delwrite~/vd~ pairs though it's late and I can't actually tell if it sounds any better.

http://www.pdpatchrepo.info/hurleur/bbd-test.pd

I'm not using a -raw flag right now, just the old read -resize, and it is giving me this

"error: soundfiler_read: /Users/wkc/Library/Application Support/Ableton/Library/_Live/Loops/Continuous/Full Range/Strings Arvo.aif: unknown or bad header format"

OK, fixed it by adding [delay 10] before the bang that eventually pushes the [; read -resize( message through. Best guess is the patch outraces the hard disk without this delay.

Wow, my first thread here turned into a soliloquy...sorry everyone

OK figured it out. Turns out creating an array in the main window with "$0-control" works, stupid me.

But now I have a different problem. Now I am using writesf~ to record a file, which is immediately "read -resize"d into the buffer array at the same time the [stop( message is banged. However the resizing of the buffer array always gives me an "error: resize failed" message. What's weirder is that if I bang the resize message again it works again, and a [print] object I've attached to the

[; read -resize(

message (above the comment "diagnostic purposes only" in the "pd input" subpatch) shows this message outputs the exact same message on both bangs. So why does it only work on the second bang?

Buggy patch attached for reference...

http://www.pdpatchrepo.info/hurleur/grainlooper-1c.pd