Many thanks again, Pix. I'll revisit the patch. I've posted this to the list as you suggest in case people may find it useful.
Richard Bowers.
Subject: Re: [PD] PD Pitch shifter
| On Wed, 16 May 2001 09:49:15 +0100 | "richard.bowers" richard.bowers@ntlworld.com wrote: | | > Thanks very much, Pix. That helps a lot. I understand the principle now. | > My | > remaining problems are to do with the pd objects themselves. Maybe you | > could | > help me out? I've enclosed the patch so that we are looking at the same | > thing. | > | > I think I pretty much understand the left hand column - for setting the | > transposition via tape head speed. However... | > | > 1) Am I right in thinking the delay time (5000 samples or ms?) is | > immaterial, other than it has to be larger than the window size and that | > it | > will actually delay the response. | | yes.. it is the maximum size of the delay line. it has to be larger than | the window size. just like csound (i used to use csound) you have to set | it at init time and you can't change it afterwards, so you set it to some | arbitrarily large value (but not so large as to soak up all your ram). the | delay in the output will only be as big as your window, which you can | change live. | | > 2) I am unsure about the roles of moses | | moses "splits a stream" of numbers. so here, all the numbers >= 1.5 will | appear on the right output, and all the numbers less than that will appear | on the left. you can see that numbers on the left immediately get used to | trigger a "1" signal. so this just means that any numbers smaller that 1.5 | will be turned into 1's. this is to stop reading from the very beginning | of the delay line where bad things can happen. | | > 3) I don't see what wrap and t b f are doing. | | wrap is almost just returning the fractional part of a floating point | number. eg, 1.5 -> 0.5, 2.3 -> 0.3... it's called wrap because of the way | it deals with negative values, -1.1 -> 0.9 (and not 0.1), -2.7 -> 0.3 etc. | | "t b f" is a trigger object. it takes it's input, and first, sends it out | as a float to the right most output, then sends it out as a bang on the | left input. the reason this is done, is because the "/" object that it is | being sent to will 'trigger' when it receives a bang or a value in it's | left most inlet (like most objects in pd). so the trigger makes sure that | the value is sent to the right inlet, and then after it has done that, it | bangs the left inlet to make it recalculate the division. | | the trigger object is used almost exclusively to get around the facts that | objects only trigger when hit on certain inputs. it's also used to make | sure that things get done in the right order. | | > Sorry, this is very much a newbie question. I would be grateful if you | > could | > help me with this. I haven't sent this to the list. I'm using a pitch | > shifter based on a similar model in CSound but it is simply not as | > smooth. | > I'd like to be able to write the pd version in CSound. | | maybe you should send this to the list incase it is useful for other ppl. | i initially didnt post to the list because the traffic has been picking up | recently, but now i'm thinking it probably would have been useful info. | | > Many thanks, | > | > Richard. | > | > | i'm pretty sure the one you are talking about is the rotating tape | > head | > | pitch shifter, which i agree is very cool. actually the idea crops up | > all | > | over the place in my main patch. anyhow... | > | | > | it is modelled on an actual physical device. you have a tape loop, | > running | > | at constant speed (eg, a delay line). then you have a number of read | > heads | > | mounted on the edge of a disc that rotates, passing the heads over the | > | tape (a number of delay taps, which can move). the gain on the | > different | > | read heads is oscilated so that the signal is only used from the read | > | heads that are in contact with the tape. you also have to be careful | > to | > | have the gain completely off when the head first touches the tape, or | > when | > | it leaves the tape (eg, dont mix in the signal from the delay reader | > as | > | you change it's position). | > | | > | in the digital world you only really need two delay taps (because you | > dont | > | hav eto worry about the mechanics of rotating them around a disc, in | > which | > | case you would probably need about three). the delay taps sweep (ala, | > | phasor) across the delay line (at a speed which determines the pitch | > | shift). you oscilate the gain of the two taps with a cosine | > (oscillating | > | between 0 and 1), in such a way that just as the tap is about to leap | > from | > | one end of the tap to the other, it's gain is 0. | > | | > | there's my possibly incoherent description... | > | | > | pix. | > | | > | On Wed, 16 May 2001 00:31:22 +0100 | > | "richard.bowers" richard.bowers@ntlworld.com wrote: | > | | > | > Hi all. | > | > | > | > I was exploring the supplied patches in pd and was delighted at the | > | > quality | > | > of the delay pitch-shifter. Would anyone be able to describe it's | > | > implementation to me as I would like to be able to converted it into | > a | > | > CSound instrument (sorry ;) ). I've had a go at understanding it but | > I'm | > | > not | > | > very confident with the PD language so I need some help. | > | > | > | > Many thanks, | > | > | > | > Richard Bowers. | > | > | > | > ============================ | > | > Richard Bowers at | > | > http://www.kakutopia.fsnet.co.uk | > | > ============================ | > | > | > | | >