It sounds to me like the problem your having is just a result of feeding back into the pitch shifter (or even using a pitch shifter at all). If you just feed it back into the delay, you should get the effect of a delay pedal. The pitch shifting comes because as you shorten the delay line, the delay playback head moves up the delay line, essentially reading it faster for that moment (or vice versa). And of course, reading it faster causes the pitch to go up. If you feed that back into the delay line, that moment of pitching up will repeat until the delay dies out, and it doesn't keep pitching up with each delay. The record head stays at a constant rate.

I've been trying to emulate a delay pedal I have, but having no luck.
The effect I'm after is a stable interval's pitch change when you change the delay time - you can tune the sound going around the delay loop up or down by a stable number interval by shortening or lengthening the delay time - just as you could tune sample playback by changing the rate of a phasor~ reading an array.

If I use a vd~ reading from a delay line (as in the rotating tape head pitch shifter example, but with added recirculating feedback) I can get pitch change effects (pretty great pitch change effects tbh) but they're unstable - they keep rising or falling in pitch with each circulation as they get pitch shifted each time they go around the loop.

I figured one way to implement the effect would be to change the write speed and the read speed by the same amount (I'd guess this is how the pedal is doing it)- But I have no idea how to change the delay write speed in PD.
I thought of changing sample rate using block~ in a subpatch with the delay line but that doesn't seem to give the desired results (or in fact any sound at all - so I'm guessing you can't upsample a delay line).

Any ideas???

I'm using PD and Jack on OSX.

Is there any way I can use some sort of PD external to control the Patching/Routing of my jack server? I'm using PD to send OSC signals to control SooperLooper, a looping system that runs on jack, and I'd like to be able to use PD to control which of my DAC inputs go to each loop. I've only got two inputs, but I loop them separately and it would be nice to be able to have setups like... four loops from input one and two loops from input two switching to two loops from input one and six loops from input two without having to have ten total loops, all routed ahead of time, with several loops taking up audio processing power without actually being in use at any given time.

Can I send commands to jack (perhaps OSC?) from within PD like "route system input one to SooperLooper input 4" with some sort of object?

Does anyone else think it would be useful to control audio routing within PD?

Hi all, glad I found this place and it's still active! I'm fairly new to pd and to synthesis in general, but I've been playing with the platform for a few months now and I recognize a few names here already from alot of examples and tutorials I've viewed, so it's good to be here.

Anyway on with my question.. I notice vline~ has two extra inputs, but all the examples I've seen use three-member lists on the hot input. And the built-in help for vline~ only explains the first input as well. What are the other two inputs for? Can all three be used to set the target, duration and delay values individually?

And if so - can I send for example:
msg[ 1, 0 ] to target, msg[ 20, 100 ] to duration and msg[ 0, 400 ] to delay inputs of vline~, instead of using:
msg[ 1 20 0, 0 100 400 ] on the first input?

This would help me alot for the simple ASR envelope I'm working on. Otherwise I suppose I can go through set & trigger hell and maybe figure out a good way to get the variables into the (list, list) format but I'm worried about lagging something up.

Thanks!
-Matt

Alberto,

I figured it out. I made a few changes to your makefile, though:
1. added a path to m_pd.h
2. changed "rm -f $*.o ../$*.dll" to "rm -f $*.o $*.dll"
(the .dll file wasn't being removed from the working directory)
3. forced DEST to the pd/extra directory
4. removed CSYM since it's not being used
5. removed "current: pd_win"; changed "pd_win: $(NAME).dll" to "all: $(NAME).dll"
6. removed non-win stuff
7. removed the clean and install targets for right now
Hopefully these changes make it easier for the complete newbie. Anyway, with enormous thanks to AlbertoZ, here's a mini-tutorial for using my makefile.

1. if you're using pd-extended, save this as "m_pd.h" (into the same directory with
helloworld.c). If you're using pd-vanilla, you can skip this step.
2. save this code as "mk.mk" (into the same directory with helloworld.c):

# mk.mk -- invoke with "make -f mk.mk"

      NAME = helloworld
    PDPATH = "c:/Progra~1/pd"
   LDFLAGS = --export-dynamic -shared
WININCLUDE = -I $(PDPATH)/src
 WINCFLAGS = -DPD -DNT -W3 -WX -Werror -Wno-unused          \
             -mms-bitfields -Wno-parentheses -Wno-switch    \
             -O6 -funroll-loops -fomit-frame-pointer

all: $(NAME).dll
.SUFFIXES: .dll
.c.dll:
    gcc $(WINCFLAGS) $(WININCLUDE) -c -o $*.o $*.c
    gcc $(LDFLAGS) -o $*.dll $*.o $(PDPATH)/bin/pd.dll  
    strip --strip-unneeded $*.dll
    cp $*.dll $(PDPATH)/extra
    rm -f $*.o $*.dll

2. modify the PDPATH variable if needed to reflect the actual location of pd on your
system (MSYS will interpret c:/Program Files/pd as C:/Program, so use
c:/Progra~1/pd instead)
3. if you're using pd-extended, remove line 6 (WININCLUDE = -I $(PDPATH)/src) and
remove $(WININCLUDE) from line 14.
4. close all pd windows if any are open
5. in MSYS, navigate to the directory with helloworld.c and type: make -f mk.mk
(type make -s -f mk.mk if you want to hide the lengthy shell response)
6. the shell should respond with something like:
gcc -DPD -DNT -W3 -WX -Werror -Wno-unused -mms-bitfields -Wno-parentheses
-Wno-switch -O6 -funroll-loops -fomit-frame-pointer -I "c:/Progra~1/pd"/src -c -o
helloworld.o helloworld.c
gcc --export-dynamic -shared -o helloworld.dll helloworld.o
"c:/Progra~1/pd"/bin/pd.dll
strip --strip-unneeded helloworld.dll
cp helloworld.dll "c:/Progra~1/pd"/extra
rm -f helloworld.o helloworld.dll
7. a new helloworld.dll file should be saved into the pd/extra folder, and you should be
able to create the "helloworld" object in a new pd window.

Good luck!
middlepedal

hi friends,
i have a problem about delwrite~ and delread~ objects,
i want to create an object(patch) with a signal input and signal output, that output will be delayed, and i want to be able to use that object in other patches,
i created a patch 'delayobject' using objects like:

|delwrite~ delay 3000( |delread~ delay 400(

but when i want to use more than one of these 'delayobject' s in an other patch, i get the error

warning: delay: multiply defined

so, for every 'delayobject' that i create i have to give 'delay' a different name automatically,
i try to use something like $1-delay but i can't figure out how, cause there is no inlet for 'name' on delread~,delwrite~ objects,
is there a way that i can rename these objects with a message?
or any other ideas, suggestions?
thanx

you might need to use a set up that involves using two (or more) separate delay lines and swapping back and forth between them at the moment you want to 'clean' the delay. here's how it would work:

assume two delwrite~ obects with delay lines named a and b. matching these two delwrite~s are two delread~s. each of these four objects can be 'turned on' or 'muted' (using the method supplied above by giair). muting a delwrite~ object technically means muting the audio going into to the object.

the initial state of the patch would [delwrite~ a] and [delread~ a] turned on and [delwrite~ b] and [delread~ b] muted. when you want to clear the delay line, you would mute [delwrite~ a] and [delread~ a]. at that point you can turn on the 'b' delay line objects. you can switch back and forth between your two delay lines cleanly if you wait an amount of time greater than the length of the delay.

in the case that your delay time is longer than the time you want to wait, you would have to use another delay line. the downside of this is that the control gets a little bit more complicated. if this is something you might apply, check miller puckette's book (pdf available on his website i think) and look at the chapter on polyphonic synthesizers. polyphonic synths require some form of voice allocation and you might be able to use some of pd's voice allocation support to help manage your delay lines, because it is a fairly similar process.

i hope this made sense. i don't think it's as confusing as it sounds, but it is hard to put into words. if you understand what i mean, but aren't sure how to implement it, i could probably post an example; just let me know.

--zac