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...