Hello,

Today [ipoke~], a variable speed writer class with linear interpolation, is released as beta version. This class enables you to model some intriguing processes, like variable speed sound-on-sound looping and doppler effects.

[ipoke~] was originally written for MaxMsp by Pierre Alexandre Tremblay. The Pd port results from a happy collaboration between P.A. Tremblay, his colleagues at Huddersfield University, and Pd people. Collaboration still goes on - a version with higher order interpolation is in the pipeline, but that is for the next version. Find [ipoke~] v.3test1 with source code, binaries and test patches here:

http://puredata.info/Members/ipoke

We're in test phase so if you find bugs or flaws, please let us know. And if you design cool patches with [ipoke~], please upload!

Katja

I'm trying ipoke~ to make an overdubbing. Ubuntu 12.04, 64bits. For the moment, it works OK. But, I have some doubts about stopping the writting in the table. Possibilities and tries:

1.- For now, the only way I discovered to do that is to change the array through set message... to an empty array. There's no click and it stops recording at the main array.

2.- Add [*~ 0] to left inlet. So, there's nothing to write, but... it continues processing.

3.- Send a value outside the array size and stay there, but this makes very loud clicks. I realized that it is because the interpolation, isn't it? There isn't any stop?

Maybe a mix of 2 and 3?

EDIT: Also, a [switch~ 0] somewhere, may help?

Hello MarioMey,

Thanks for your report/question. If you send negative index values to [ipoke~]'s index inlet it should stop writing. At least that is the intention in the C code as it was originally written. Anyhow it is an untested and undocumented aspect of [ipoke~].

Can you send negative indexes and check if you still get artifacts? If so, can you post your patch?

Katja

Before testing sending negative values, I post the patch with an overdub working, using switch~ inside a subpatch. Maybe you can tell me if is useful or not.

Also, I want to know how to be sure that the tableread4~ is reading and sending to ipoke~ just before ipoke~ job. Because, if it is at reverse, it wouldn't do the trick.

Now, I'm checking sending negative values...

EDIT: I tried a patch sending the same signal as [tableread4~] use and a negative value (with sig~) to stop writing.

But, when starting the overdub, it writes a silence, sometimes before, sometimes after that. And then, it continues writing well. I don't know if it can be fixed inside the patch, because ipoke~ works like that... or it is a bug.

I keep on thinking that, to make an overdub, switch~ must be used. Because, if you send negative value, unless that it really stops writing and stay there, when ipoke~ interpolate to -1, it continue writing in the interpolation. The same when it receive the signal again. Am I wrong?

Added the sending negative value file.

ALSO: Isn't there any set-write-to-none-array option? So, the signal in right and left inlet could be there, but ipoke~ not writing any array... only if ipoke~ doesn't consume CPU doing that.

SECOND EDIT: in the attached patch, writing at the same time as reading IS possible. But, in my project, ISN'T. So, I had the great idea: adding a delay line of 100 samples to the signal and another for the value. But it doesn't work... and, for the moment, I don't know why.

THIRD EDIT: any time that ipoke~ goes to a point to an array, using switch~ or a negative number, it writes null data between the last point to the new point. So... I think that the solution is, if it is possible, to have an option for not-writting. So, if it continues moving along the array or stay quiet and then go to the new position (using switch~ or negative value), it should not write the array.
There're two workarrounds:

• to change the array with a set message.
• wait the playing array to start from 0, and then, start ipoke~ (using a metro).

ONE EDIT MORE: looking at the code, I found that, by sending [overdub 1(, it is not necesary to add the array playing to the mic. Also, there's [interp 1(, but I didn't hear the difference. I suggest a [mute 1( ! It wouldn't be difficult at all (I think). Anyway, I still have problems with the delay line.

Some day, ipoke~ and tabread4~ coulnd be merged in one class... In that way, sampling, looping and overdubbing could be easier than ever before. Adding [mode 0(: 0 for readding, 1 for writting, 2 for overdubbing, 3 for reading and, then, writting, 4 for reading and, then, writting with overdubbing...

http://www.pdpatchrepo.info/hurleur/test_ipoke~_switch~.pd

Before testing sending negative values, I post the patch with an overdub working, using switch~ inside a subpatch. Maybe you can tell me if is useful or not.

Also, I want to know how to be sure that the tableread4~ is reading and sending to ipoke~ just before ipoke~ job. Because, if it is at reverse, it wouldn't do the trick.

Now, I'm checking sending negative values...

EDIT: I tried a patch sending the same signal as [tableread4~] use and a negative value (with sig~) to stop writing.

But, when starting the overdub, it writes a silence, sometimes before, sometimes after that. And then, it continues writing well. I don't know if it can be fixed inside the patch, because ipoke~ works like that... or it is a bug.

I keep on thinking that, to make an overdub, switch~ must be used. Because, if you send negative value, unless that it really stops writing and stay there, when ipoke~ interpolate to -1, it continue writing in the interpolation. The same when it receive the signal again. Am I wrong?

Added the sending negative value file.

ALSO: Isn't there any set-write-to-none-array option? So, the signal in right and left inlet could be there, but ipoke~ not writing any array... only if ipoke~ doesn't consume CPU doing that.

SECOND EDIT: in the attached patch, writing at the same time as reading IS possible. But, in my project, ISN'T. So, I had the great idea: adding a delay line of 100 samples to the signal and another for the value. But it doesn't work... and, for the moment, I don't know why.

THIRD EDIT: any time that ipoke~ goes to a point to an array, using switch~ or a negative number, it writes null data between the last point to the new point. So... I think that the solution is, if it is possible, to have an option for not-writting. So, if it continues moving along the array or stay quiet and then go to the new position (using switch~ or negative value), it should not write the array.
There're two workarrounds:

• to change the array with a set message.
• wait the playing array to start from 0, and then, start ipoke~ (using a metro).

ONE EDIT MORE: looking at the code, I found that, by sending [overdub 1(, it is not necesary to add the array playing to the mic. Also, there's [interp 1(, but I didn't hear the difference. I suggest a [mute 1( ! It wouldn't be difficult at all (I think). Anyway, I still have problems with the delay line.

Some day, ipoke~ and tabread4~ coulnd be merged in one class... In that way, sampling, looping and overdubbing could be easier than ever before. Adding [mode 0(: 0 for readding, 1 for writting, 2 for overdubbing, 3 for reading and, then, writting, 4 for reading and, then, writting with overdubbing...

http://www.pdpatchrepo.info/hurleur/test_ipoke~_switch~.pd