Hi
Ok, I spend too much time trying to figure this out, so I have to chicken in and ask:
I want to do something that I think is fairly simple and standard: Load a sample at arbitrary length and play it back at various rates. tabplay~ works fine (byt doesn't transpose), and tabread4~ complains that my array is not a power of 2 + 3.
So how do I:
Sorry if this is too obvious!
unless you've got a really weird pd setup. then i guess that it's not tabread4~ that is complaining about the power of 2 + 3 error. it's usually tabosc4~ that does that.
tabread4~ should do what you want.
hard off wrote:
tabread4~ should do what you want.
Ok, thanks.
I got a basic patch running that works (I drive the tabread4~ with a phasor~ and after rescaling phasor~ to match the table length it works.
On Tue, 2008-07-01 at 22:30 +0900, hard off wrote:
yeah, and you can use [vline~] if you don't want to loop
and also in case you WANT to loop. though it's harder to deal with, in many cases i founded it to be more useful, for instance in all cases, where you need to know, when the loop starts. there is actually only one drawback in using [vline~] as the 'table index driver' - compared to [phasor~]: it doesn't allow to change speed at samplerate (yeah, it is possible, but only by sending sr * times messages per second -> very expensive, i suppose).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Tue, 2008-07-01 at 10:12 +0200, Atte André Jensen wrote:
Hi
Ok, I spend too much time trying to figure this out, so I have to chicken in and ask:
I want to do something that I think is fairly simple and standard: Load a sample at arbitrary length and play it back at various rates. tabplay~ works fine (byt doesn't transpose), and tabread4~ complains that my array is not a power of 2 + 3.
So how do I:
- play my sample at half speed, one-shot?
- play my sample at half speed, looped?
- play my sample at half speed, with loop points set by hand?
Sorry if this is too obvious!
just let me add, that i find this not trivial (nor stupid) at all. since one works with quite low level primitives in pd, there are lots of ways to implement a certain task, where each of it has its pros and cons. peeking at the 'better tabread4~' thread, there are many strategies to only pitch a sample from table down- and upwards. when looping it also comes to choosing an adequate strategy to avoid click/jumps at loop end/start. there are so many different kinds of samplers, that could be implemented in pd: this topic is actually quite complex.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
just let me add, that i find this not trivial (nor stupid) at all.
Thanks for you uplifting remarks about my intellect :-) But being new at something can make you feel stupid. I'm understanding a bit more every day, though, so maybe all hope is not lost!
one
drawback in using [vline~] as the 'table index driver' - compared to [phasor~]: it doesn't allow to change speed at samplerate (yeah, it is possible, but only by sending sr * times messages per second -> very expensive, i suppose).
phasor~ doesn't allow speed change at samplerate either. it allows speed change at block rate.
so if you want to work with a metro and vline's triggered every 1ms, it would still have better resolution than a normal phasor for speed changes.
hard off wrote:
phasor~ doesn't allow speed change at samplerate either. it allows speed change at block rate.
Err, yes it does support samplerate control of speed - the left inlet is a signal inlet, and I checked the source code to confirm it:
// d_osc.c static t_int *phasor_perform(t_int *w) { t_phasor *x = (t_phasor *)(w[1]); t_float *in = (t_float *)(w[2]); // (1) t_float *out = (t_float *)(w[3]); // snip weirdness while (n--) { tf.tf_i[HIOFFSET] = normhipart; dphase += *in++ * conv; // (2) *out++ = tf.tf_d - UNITBIT32; tf.tf_d = dphase; } // snip boring bits }
The line marked (1) gets a signal vector from the dsp graph, and the line marked (2) increments the phase by each signal element.
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:
hard off wrote:
phasor~ doesn't allow speed change at samplerate either. it allows speed change at block rate.
Err, yes it does support samplerate control of speed - the left inlet is a signal inlet, and I checked the source code to confirm it:
What phasor~ doesn't support is setting the phase at samplerate, as the *right* inlet is just a message inlet without support for clock-delayed messages. So you cannot start playing a sample or loop as exactly as with vline~ while vline~ cannot change the loop speed at samplerate easily. Duh.
Frank Barknecht _ ______footils.org__
oops, my mistake.
here's the patch which i based my faulty logic on, and in hindsight all it proves is that signals are delayed one block before affecting the phasor's pitch.