Hi All,

I'm just (at last) getting to pd, using the latest extended version on a Macbook Pro. I've been working at a couple of projects, the attached is a patch for one of them; involves a live logitech mic input with four sub-patches that are intended to manipulate the incoming vocals if/when triggered by a ping-sensor reading.

I was pleased to get any of this working : ) but it seems to me that all the sub-patches are not feeding through (I can't hear any pitch or speed altercations, for eg). I'm afraid this is about as far as my own insights to-date take me....

Help?

Pleases and thank you's... in advance.

http://www.pdpatchrepo.info/hurleur/live_sleepless.pd

One of the sub-patches (pitch change)....

http://www.pdpatchrepo.info/hurleur/live_low.pd

Another sub-patch (accelerated speed)...

(FYI: It has been a while now since last I tried, but seems to me these configurations worked if all by themselves and not all included within same parent patch)

http://www.pdpatchrepo.info/hurleur/live_speed.pd

So sorry... I just realised that you will need the following sub-patch in order to get any of this working (if you need to see it work)...

http://www.pdpatchrepo.info/hurleur/live_constant.pd

They seem to all be feeding through here, but right now all the abstractions are just static delays. The [tabwrite~] objects need to be banged in order for the tables to be filled, otherwise you won't hear anything from the corresponding [tabread~]s.

For clarity (and easier debugging), it would probably be better to have all of your [catch~]s feeding to one [dac~], and attach number boxes to the right inlet of those [*~ 0.2] objects. That way you can turn each "track" down individually and hear them one at a time.

Hi Maelstorm,

Thanks for the tip, that is helpful for figuring out what is what.

I've tried now to connect the inlet to the tabwrite, also tried to send a bang. Tried cabling all into one dac~ also. The only difference made is that with each modification I get a reverbrating high-pitch sound from each of the sub-patches so long as they are on. Still no indication of speed/tone changes. The piercing ringing sounds are still present no matter how many ways I change the various gain levels. Would this be because all the sub-patches have delays in them (too many for one patch)? Or, perhaps my math is wrong in the above patches for sig~ and phasor in context with "mydelay" and the table sample size?

I must admit I'm kind of taking a stab in the dark with the correlating equations required for the above attached....

Actually, I just realised that the pitched noise (as well as buzzing noises) are only emitted if more than one of the sub-patches is triggered at the same time (excluding the live_constant sub-patch). Which would be the case in the live performance, via the sensors (reading more than one trigger distance at a time). I'm wondering if I need a metro in the sub-patches, or some such, in order regulate how many times per sec the patch can be triggered....?

The high pitch stuff is a result of the numberboxes going in to [sig~]. For example, in live_speed.pd you have a [sig~ 0.5] with a comment saying that it will take two seconds to read 88200 samples. Given that the table is 88200 samples, that's right. But when you send that numberbox value of 120 to [sig~ 0.5], it replaces the 0.5 with 120, so now you're reading through the table at 120 Hz instead of .5 Hz, which means it will read through those 88200 samples in 1/120th of a second.

I don't really think you need these tables anyway. You can do the pitch and speed stuff with variable delay lines (using [vd~]), which just constantly write and rewrite audio to a buffer. Tables are essentially buffers also, but they are only written to on command. They don't automatically rewrite once full, so you'll keep repeating the same snippet until you bang [tabread~] again.

Take a look at G09.pitchshift.pd to see how it is done with delay lines. To do a simple speed change, send [line~] to [vd~], giving [line~] a message to start from a short delay time and increase it.

Hope that helps.

Ahhhh... Makes sense (sig~ override)!

Only, I'm afraid I don't really know what I'm looking at with the G09.pitchshift patch, there is a lot of multiplication, subtraction, addition et al.... Not sure I understand why or what for, or what is being unpacked in there. Though I understand it must be a sub-patch (receiving messages or arguements it appears)... I'll take a look through for the parent see if it helps, insight wise.

I tried to arrange line and vd as you've proposed, but am getting error messages and no sound (I guess I still need a delwrite? But then, don't I need the table and tabread?). Would you mind at all to provide an eg of this simple (speed change) arrangement?

I thank you for the clarity of your responses, very informative for me. And for lending me some of your time - much appreciated.

Okay, so I made a little patch comparing the table approach and delay approach, and they both have their ups and downs. For one, the table method will only allow you to speed/pitch down for the most recent audio. Faster playback will result in the virtual playback head to pass in front of the record head, causing it to playback previously recorded material, which I get the feeling isn't what you're after.

The downside to the delay method has more to do with the fact that I just can't remember how to go about determining the exact transposition you're looking for. But it does allow for longer playback than the table method using the same size buffer. This is because the playback head is always following the record head and can thus wrap around the buffer before reaching the max buffer length or catching up with the record head.

I used the [cos~] object to generate an envelope. This is what is used in G09.pitchshift.pd. The difference is that there are two of them, offset by 180 degrees. These envelope to delays playing back at different speeds, and as one delay is silent the other is at max peak. They are essentially crossfading in and out with each other. The silent one is switching from the beginning of the delay line to the end (or vise versa, depending on the pitchshift) while we can't hear it. So basically it plays short snippets (or grains) at different speeds to change pitch, but the start times of each grain are relative to the input signal so there's no sense of timestretching.

Something like that.

I don't know what's going on with the math in the transpose section, I just know it works!

http://www.pdpatchrepo.info/hurleur/helpforpatches.pd

Maelstorm,

Thanks so much for putting the time into providing egs; 'tis very kind of you.

To be honest, I can't keep either side of the patch working more than once (one bang) for the sake of comparisons. Can't get my head around the construction of them for the moment either - my head is to foggy today.

I'm going to come back to it after a break from it. After restarting the patch this morn, I found that the noise issues were largely gone... I suspect simply changing the over-riding number inputs made all the difference, but that the patch needed to wear out the 'old' delays and echos left over from the prior arguments... ?

Many thanx, again.