
LarsXI
it's no trouble! what do you mean by one sound? like to play the sound through one time without looping?
When loading different samples, it's necessary to do the calculations for the new length of the samples again. That's everything downstream of loadbang. And the 69.03 value will change with samples of lengths other than 100.

LarsXI
It's not crappy!
This has the phasor method patched up and I put the one I use for oneshots on the right too. samplepitch.pd
The mtof / from stuff and also converting frequencies around with the reciprocals always takes a couple tries for me because I don't understand totally how the conversions are working. I think it comes down to the midi scale being a linear scale that represents an exponential change. Converting back and forth to time on top of that is needed for sampling

LarsXI
oh shoot! okay. I use a vline~ to feed tabread4~ so the method is a little different
The mtof part is designed to calculate a ratio  so if you input a zero into the left part, the result is one. If you input something like 5, it will give you a value that is less than one. You can multiply that value by the length of the sample in ms to get how long the sample would play back if you wanted it to play at 5 semitones above(?) the base pitch of the sample. You have to choose a midi note to start at. Above that note, the sample will play faster, below that note the sample will play slower. I think I calculate this value by taking the base note and subtracting from that the note from the midi keyboard.
You want to use the tabread4~ method from the (3.7.1.1.) example, but instead of feeding it with a phasor~, try feeding it with a vline~. Then you can calculate the length in samples of your sample. That's the left output of soundfiler. Dividing length in samples by the samplerate~ gives you the lenght of the sample in seconds. Multiply that by 1000 and you have the the length in milliseconds. vline~ takes input in milliseconds. Send it a message to ramp from 0 to the number of samples in your sample in the number of milliseconds you just calculated. If you want to repitch it, also multiply by the midi ratio from above.
If you want to use phasor~ instead, you're setting frequency in Hz. So instead of multiplying the sample length by 1000, you might want to multiply it by the ratio and then get the reciprocal of it with this:
Then feed that to the phasor~Are you going to use phasor~ in your design? I could double check that there's not a better transposing method with phasor.
Actually, it might be way easier with phasor, You could convert your current input to phasor to midi with ftom, then add transposition in semitones and then convert back to a frequency...

LarsXI
Hi. If you are referring to phase in the conventional recordingengineer sense, I think this is straightforward. You take one of the two samples, invert it [*~ 1} and then add it to the other signal. This results in the difference of the phases. I believe this is how it work in mid/side converters and the like
If you want to do something with frequency components in an fft scheme, you would want to run the fft analysis on both samples and then do something similar before resynthesis. I don't know fft, but I think there is some info in the help browser.

LarsXI
Hi,
the way i've done this recently is by using a single phasor~ to start, then routing that to multiple subpatches, each processing that signal into a different shape. inside each subpatch, I put a control inlet to the object [switch~]. when this object receives a zero, it deactivates DSP to that subpatch. using a hradio and several == objects, you can select a single subpatch to activate at a time. this is what it looks like in one of my lfos:
this has been my favorite way to do muxing lately. maybe there is a better way...


LarsXI
Hi. I don't work with wavetables so I'm not confident about this.
But try putting each wavetable backtoback in a single table. Then use signal logic like this:
If each cycle is a certain number of samples long, this should switch to another integer multiple of that number of samples on each cycle of the pitch.

LarsXI
This might work depending on the rest of your patch:
Sending a float to the left inlet of [f ] will forward that float to the output. Sending just a bang to the left inlet will add 0.1. If you need additional buttons with different increments, I think it's useful to have additional [f ] objects.

LarsXI
vline~ is sample accurate,you can use line~ instead but you'll need to break up the message.
you could use whatever numbers you like or make it dynamic.
edit: shoot sorry, the message should read 0 60 0, 1 300 60