I am in the process of trying to make a patch that will continously record incoming sound, and then process this sound in various ways(from various playback-modes, speed change, perhaps vocoding shit, etc.). The main idea is to not have to press a button or rely on a timer or whatever to keep writing to an array, but to have the processing occur sort of all the time, or at least when sound is coming in). So far I played around a little with tabsend~ (for writing the audio to an array/table), and tried to use tabplay~ and tabread4~ for playing back parts of the incoming audiostream. I had best results with tabread4~, with the index controlled by a phasor~, after I made an array that was 1 second long that got written to with tabsend~. It worked, somehow, but it had pop's and click's and what not at seemingly random intervals. I guess it's because when you are trying to read what is being written at the same time, you get conflicts and hence these artifacts. I imagine you could perhaps try to use several arrays for writing, and in a way only look up where it is not being written to. Pardon my sloppy articulation on the matter here, I hope you get what I mean. I saw a friend using max, and there he had sort of this index-number coming out of the object he used for recording to a buffer, but PD's "tabwrite" and "tabsend" do not appear to have such things(although I guess if i use tabwrite I could have a metro with a counter or similar to get the idea of how it goes). Anything like it in PD, like a way to recieve the index of just where tabsend~ is writing in the array? Or have I misunderstood a bit, do tabsend~ actually just record one "block" at a time(so if I put a block at 44100 to correspond with my array of 1 seconds length, it only get updated once a second?).

Have anyone here attempted such a project, or know the theory good enough to perhaps come with a wize suggestion on the matter? I have as I said just started this, so I have not experimented that much yet, i started earlier today, but alas had to go to work before I got anywhere. I was hoping i'd find some info on the matter by browsing the forum(as i can do that much from work), but it seems noone have made a post about it yet(as far as i managed to find anyway), so... yeah.

Rliivt Anything like it in PD, like a way to recieve the index of just where tabsend~ is writing in the array? Or have I misunderstood a bit, do tabsend~ actually just record one "block" at a time(so if I put a block at 44100 to correspond with my array of 1 seconds length, it only get updated once a second?).

yes, [tabsend~] writes exactly one block, so you have to change the block size with [block~] if you wanted to do loops - not very flexible

Rliivt _It worked, somehow, but it had pop's and click's and what not at seemingly random intervals. I guess it's because when you are trying to read what is being written at the same time, you get conflicts and hence these artifacts. I imagine you could perhaps try to use several arrays for writing, and in a way only look up where it is not being written to. _

yes, that's standard technique ("double buffering" is the keyword) - write to one array then flip to the other one - and read from the array you're not writing to -- but then that's not so fun either.

maybe instead of working with arrays and stuff, and having to keep track of read position vs write position, using a long [delwrite~] and some [vd~] to play back could work

@ClaudiusMaximus said:

maybe instead of working with arrays and stuff, and having to keep track of read position vs write position, using a long [delwrite~] and some [vd~] to play back could work

Seconded, delays are the best for looping and layering. Until some Pd witchdoctor gives us an index based tabwrite(akin to tabread4~) it will be very hard to get the timing just right with arrays. It would also be nice if delays and tables could share the same buffers, no?