Updating table in real-time

Reply to Updating table in real-time on Sun, 11 Nov 2012 16:33:00 GMT

Krex — Sun, 11 Nov 2012 16:33:00 GMT

Hi all!

I'm trying to implement a real-time synthesis algorithm which produces waveforms sample by sample. My approach is to calculate a block of samples, store them in a table, wait for those samples to be reproduced (using phasor~ and tabread~) and calculate another block. For example, if there are 8820 samples in a block, the reading frequnecy is set to 5 Hz, whilst the waiting between calculating two successive blocks is 200 ms (I use METRO 200).

And it works fine. However, in every reading cycle there is a hearable click. The click is not caused by the synthesis algorithm because the updateded table smoothly continues from the old values. So, I guess that the problem is updating the table while reading it.

I spent a lot of time trying different apporaches (such as tabosc~ and even direct usage of sig~), but have not found a solution. Also, searching for an idea on the Internet did not help. As I am quite new to Pure Data, maybe there is a different approach or an obvious solution which I don't see. I would appreciate every suggestion.

Cheers!

Reply to Updating table in real-time on Sun, 11 Nov 2012 17:04:08 GMT

baptiste_c — Sun, 11 Nov 2012 17:04:08 GMT

Could you attach your patch ?

Reply to Updating table in real-time on Sun, 11 Nov 2012 19:11:52 GMT

Krex — Sun, 11 Nov 2012 19:11:52 GMT

Please, find attached the patch. This should be a dynamic stochastic synthesizer, but it is not finished yet.

http://www.pdpatchrepo.info/hurleur/GenDyn6.pd

Reply to Updating table in real-time on Sun, 11 Nov 2012 19:22:31 GMT

sunji — Sun, 11 Nov 2012 19:22:31 GMT

Generally, reading and writing tables simultaneously causes clicking. Maybe try adding a table, writing the next block on the unused table and then crossfading onto that table. You can pingpong the fade back and forth between the two table and produce the desired continuous waveform.

Reply to Updating table in real-time on Sun, 11 Nov 2012 21:58:38 GMT

Krex — Sun, 11 Nov 2012 21:58:38 GMT

Sunji, thanks for the advice. It seems a little bit tricky to implement. Do you maybe have some example patches?

Meanwhile, I tried a different approach. Instead of being written into a table, calculated samples are now converted directly into audio using sig~. The algorithm processes block by block (triggered by bang~). However, the results are even worse, the sound is distorsed. Maybe I did not set appropriate values for block size and overlapping. Please find attached the new patch.

http://www.pdpatchrepo.info/hurleur/GenDyn7.pd

Reply to Updating table in real-time on Mon, 12 Nov 2012 20:40:21 GMT

Krex — Mon, 12 Nov 2012 20:40:21 GMT

I've tried two more soultions, but clicks are still there.

GenDyn8 uses two tables as sunji suggested.
GenDyn11 uses one table and tabplay which triggers the computation.

Is it possible to change the title of this thread to "Converting stream of floats into audio", because the soultion doesn't need to employ tables at all. I believe that there is a simple way to do this with sig~ and bang~ (as shown in GenDyn7).

http://www.pdpatchrepo.info/hurleur/GenDyn8.pd

Reply to Updating table in real-time on Mon, 12 Nov 2012 20:42:45 GMT

Krex — Mon, 12 Nov 2012 20:42:45 GMT

And here is GenDyn11 (based on tabplay).

http://www.pdpatchrepo.info/hurleur/GenDyn11.pd

Reply to Updating table in real-time on Tue, 13 Nov 2012 05:30:38 GMT

Maelstorm — Tue, 13 Nov 2012 05:30:38 GMT

I haven't had the time to really dig into your patch, so I don't know if this will work. But maybe try writing to the table at audio rate instead of message rate. Then you could ensure that the table is written before it is read by forcing the order with subpatches (see G05.execution.order.pd).

Reply to Updating table in real-time on Tue, 13 Nov 2012 07:01:51 GMT

Krex — Tue, 13 Nov 2012 07:01:51 GMT

Thank you, Maelstorm!

I found on this forum a way to get bangs at audio rate. So, I've adapted patch to calculate sample by sample and send them to:

[serialize 64]
|
[unpack~]

This way, tables are avoided. It works fine!

Also, another way is to calculate a block of 64 samples at each bang~ as I did in GenDyn7. However, the problem was sig~. Now with serialize 64 and unpack~ it also works fine. If you are interested in this version, you can find it attached.

Thank you for help!

http://www.pdpatchrepo.info/hurleur/GenDyn7a.pd