Pierre Alexandre Tremblay

As I ported the code to SuperCollider (shame on me ;-) I discovered a behaviour error in the code (12 years after the original release and hours of abuse later - useless to say it was a hidden one!)

Anyway, now fixed, and supporting Windows. Enjoy!

https://github.com/tremblap/ipoke-/releases

ps the gen~ version is still available, and had no bug, here:

ps the gen~ version is still available, and had no bug, here:
http://www.no-tv.org/MaxMSP/index.html

Dear all
As I ported the code to SuperCollider (shame on me ;-) I discovered a behaviour error in the code (12 years after the original rele

ipoke~-4-1-1-released-macwindows-from-max5-to-max7

Hi Pierre and thank you for this amazing contribution!

Im working on a looping device, and came across an issue that i cant figure out how to fix. 

If Im driving ipoke with a phasor~ and the phase skips back before the end of the buffer, the usual behaviour would be to be to fill in all the blank space of the buffer with the last poked sample. But it seems like if the looping back happens before the end of the buffer, the filling in is done backwards, resulting in a click at the loop point, and sometimes other changes to the sound. 

I get that this probably makes sense in most cases, to allow going both directions by picking the closest way, but for what Im doing it's creating problems! Any suggestions on how to get around it?

Hi Pierre and thank you for this amazing contribution!

Im working on a looping device, and came across an issue that i cant figure out how to fix. 

If Im driving ipoke with a phasor~ and the phase skips back before the end of the buffer, the usual behaviour would be to be to fill in all the blank space of the buffer with the last poked sample. But it seems like if the looping back happens before the end of the buffer, the filling in is done backwards, resulting in a click at the loop point, and sometimes other changes to the sound. 

I get that this probably makes sense in most cases, to allow going both directions by picking the closest way, but for what Im doing it's creating problems! Any suggestions on how to get around it?

Here's an example.

The fill always goes the fastest route, which is the shortest distance either of the wrap around the end of the buffer or the straight line back. I should add another parameter to decide the max write playhead instead of taking the buffer size, it has been on the todo wishlist forever... I'll do it in the next few weeks and will update this thread.

Wow, thank you so much for your fast response, and willingness to fix the problem! 

With "max write playhead", do you mean something similar to what Rodrigo is suggesting here?

https://cycling74.com/forums/zippergritty-distortion-when-writing-with-pokeipoke-backwards-groove-sync

aka: only fill the gaps IF the distance is less then X. I think that would be a really good solution!

Wow, thank you so much for your fast response, and willingness to fix the problem! 

With "max write playhead", do you mean something similar to what Rodrigo is suggesting here?
https://cycling74.com/forums/zippergritty-distortion-when-writing-with-pokeipoke-backwards-groove-sync

aka: only fill the gaps IF the distance is less then X.  I think that would be a really good solution!

It also seems like something strange happens with the first sample (maybe more) if Overdub is not 0. My goal now is to get my looper to overdub clean through the zero-point at the first punch-in without pops or noises, and it seems like overdub gets confused and does some weird stuff for the first sample. 

Trying to work around this Im having a go at the "dirty trick" in the help file, but can't get it to work. As i understand it the idea is that if the output of Wave is connected to the input of ipoke, the wave~ would first play the current sample, before it gets overwritten, but even with that setup, If overdub is 0. my Wave~ doesn't play anything back even the first time around, so i can't use that to make my own feedback. I could offset the ipoke or wave, but then the sample starts slowly drifting each overdub... any ideas?

It also seems like something strange happens with the first sample (maybe more) if Overdub is not 0.  My goal now is to get my looper to overdub clean through the zero-point at the first punch-in without pops or noises, and it seems like overdub gets confused and does some weird stuff for the first sample. 

Trying to work around this Im having a go at the "dirty trick" in the help file, but can't get it to work. As i understand it the idea is that if the output of Wave is connected to the input of ipoke, the wave~ would first play the current sample, before it gets overwritten, but even with that setup, If overdub is 0.  my Wave~ doesn't play anything back even the first time around, so i can't use that to make my own feedback. I could offset the ipoke or wave, but then the sample starts slowly drifting each overdub... any ideas?

ipoke~ 4.1.1 released (Mac+Windows) (from Max5 to Max7)