im working with realtime spacialization with netreceive and every time i change intensity values, or tables, i get some clics!

I recently read in this forum that this is a pd bug and that to reduce those clics , in case of reading soundfiles into tables, i could use sndfiler, but in my case im reading tables written in textfiles.

im constantly reloading the tables (25 times a second), but i only get these clics when the values of the files change.

anyone solved similar problem?

thks!!

i think you should just load all the textfile info into arrays, and then use [set $1-array< with a [tabread] ??

that way you aren't accessing the hard disk while your patch is running, because the array data is stored in memory.

hi hardoff! recently weve been having quite a dialogue

im having flash to send via php all the spacialization info i need every frame in a second(writing a text file), when it finishs writing it sends pd an order (via netreceive) to load the file:
[netreceive 4000]
[bang]
[;
mytable read myfile.txt;]

this process is going every 25 times per second, but only when spacialization values change in flash it makes these weird clics.

other weird thing i cannot understand is that is i open my flashplayer in my computer(localhost) dsp goes around 84%, but if i open it in other machine it goes up to (120%) and then it clics a lot!!!

do you know were i can find info to understand dsp? i think the problem might come from here!!

well, if you want to read up on dsp in general it's going to take quite a while i think !

the problem is pd related. or more to the point, the problem is related to how pd treats data. every time you load a file, pd's data flow will be interrupted until that file is loaded.

so, when you are loading text files, pd has to wait until it has loaded the text file into memory before proceeding.

if you are just loading small files, this might be ok on a fast machine, because the time to load text files might be so small as not to matter. but because you are loading 25 per second, the transfer of data from the text files is going to interrupt the data flow that you need to make your audio.

my only suggestion is that reading and writing text files at such a rate and loading them while a patch is running is a bad idea.

there must be some other way you can send the data from flash to pd without writing files to the hard disk.

basically, writing to the hard disk (which is what you do when making text files) is going to cause clicks and dropouts. but if you write to memory (by writing the info into arrays, etc) is going to be much smoother.

i think you have to find another way to get the information from flash to pd. instead of text files, there is probably a way to send the raw data directly from flash to pd so you can write it to arrays or directly into your patch.

...

oh, and flash also uses computer resources, so if you have 2 different computers, flash is going to require 2 differents amounts of computing power to run, that's why you get the 84 / 120 split.

heyhey!

thanks for the info and advice!!
so best to do is find a way to put flash sending big amounts of info directly to pd. something similar to netsend but sending more data.

ill post news if i can find a good solution

thanks again hardoff