Hello,

I'm doing the usual poking of audio to an array with [poke~], reading from that array with [tabread~], etc. For the most part, this operates exactly as expected but on the odd occasion I get horrible artifacts that disappear after a while with no obvious explanation as to why...

Anyone else experiencing these kinds of anomalies with poke~?

Maybe it's related to my ADC? I'm using an RME FF400.

Ricky

Hmm, interesting. Didn't even think of that....

Let me give that a whirl...

Thanks, B.

@Balwyn I changed the array size to 65536 samples.

I still get some clicks in places. I wonder if multiple phasor objects running concurrently has anything to do with it... They're all reading from their own independent buffer, though.

Windowing is pretty tight, too. CPU overhead is minimal.

Here's some audio. Sometimes it's pretty clean, sometimes not. The longer I use the patch, the more frequent the pops, hence why I think it may be related to some kind of sync issue, perhaps related to the block size / buffer size.

https://www.dropbox.com/s/5o96hubedi1uixz/glitch_pop.wav?dl=0

Anyone?

@ricky Hello Ricky....... it doesn't do it on my system...... no artefacts whatsoever. When I listened to your recording I thought that the "knocks" were a very strange form of "glitch" that I have never heard before......
I just ran your patch again for about 5 minutes and so as not to have runaway feedback I found that I was using the laptop volume keys to control that. Even if I let your patch go to chronic feedback it recovers.
It's not the sound of you pressing your volume keys recorded by your laptop microphone?...
No, probably not.
You might need to hand over your unreadable patch!
David.

Attached.

Introducing [gramulator~]

I run 6 to 7 instances. This example patch has 2 to begin with.

pokeproblem.zip

@ricky Off to bed now, but an immediate thought....the toggling of the spigots and the multiplex~ introduced clicks. I have not looked at your large patch yet.
Maybe using [matrix~ 2 1 100] would help as it includes a line function in its arguments.....the 100 (ms)...... you have to type the arguments so as to create it. [matrix~] will not create............ Then you send it messages just like [line~] but telling it which input to connect to which output at what level (0 - 1) and you can send a new ramp time again if you really wish.....but that's not necessary here........
It's a real "mixer"........
David.

@whale-av I'll give it a shot! Thanks for the suggestion.

@whale-av Trying this today. So far, so good. Thanks for the suggestion!

Quick follow-up:

While the issue with artifacts generated by multiplex~ has been resolved, I am getting some weird interpolation effects between samples previously written and new source material when I start poking audio again.

Maybe this can be solved if I synchronize / snap / hard-sync mixer changes per block? I presume some way using block~ might help. Cheers!