Hi !
I'm going to describe a bit my project first, for you to understand why I'm trying to do weird things.
My project is to use audio effects (like EQ, filters, comp, …) to modify an image at the same time than a sound.

I first tried some fun stuff with audacity. Open you image in audacity (using import > raw data), apply fun effects, export it, and finally open the file as an image. It become fun when you use delay, reverb, flanger, …

But the image you get is "one shot", and I now want to use it as a live tool, when I modify the sound you hear, it modify the image at the same time using the same method.

But image data are wrote like these (R value for pix1, G value for pix1, B value for pix1, R value for pix2, G value for pix2, B value for pix 2, ……)
Thats the kind of "signal" I get when I open the image with audacity

Using GEM library of PD, the [pix_pix2sig~] object output 3 different and distinct signals (R, G and B ). But if I want the same thing that I said above, I need to put every sample value of R, G and B signal in one signal by "concatenating" them.

In other words, from this occuring at the same time
[Rsample1, Rsample2, Rsample3, …]
[Vsample1, Vsample2, Vsample3, …]
[Bsample1, Bsample2, Bsample3, …]

I want a function that makes:
[Rsample1, Vsample1, Bsample1, Rsample2, Vsample2, Bsample2, Rsample3, ……]

Then I do some audio treatments, and convert it back into 3 parallels audio signals for RVB and put it in the [pix_sig2pix~] GEM object.

I find a way to do it, here's what i did.
I store each 3 waveforms in 3 corresponding arrays (each arrays in the size of the image, 16385 + 3 = 16387 for a 128x128 image)
Then I read each sample of these waveforms using [counter] and [tabread] and put them one by one in an array of size 3 times greater than the previous ones.
It works, but if I want to do it quickly (close to the sample rate) I need to bang the [counter] so frequently that PD start to lag drastically. It cannot treat so many scalar data in a such short time.

Is there a way to do it more "properlly", only in signal computation ?

I did some research but I didn't exactly know what to type…

Hope you can help me.

Px

PS: Sorry if my english isn't correct, i'm french

@Parallax I think the method you describe is the only way, using [until]. I don't know if the [array]-family is more efficient than [tabread]/[tabwrite], but maybe it is worth a try. A manual counter of [f] and [+ 1] is probably more efficient than [counter], but these are the only few improvements i can think of.

Thank you for your answer, so I'll try some improvement in this method. If it's still not effective enough, I'll probably try another kind of data treatment…

Using [array] instead of graphical arrays can always give a little bit of performance, speaking vanilla here, of course.

@Parallax I don't think that you can get even close to real-time if you are storing and reading arrays.
The help-files for pix2sig~ and sig2pix~ suggest increasing the audio block size of your patch and setting an overlap, or up-sampling, so that all of the data for each video frame is contained in one audio block.
That way, all of the processing can stay in the audio domain.
If you look at the block~ help-file it will tell you the time between blocks as you change its settings, and help you process each block~ within each video frame.

helper_master.zip ..... open [master.pd] which is required to re-block audio from [adc~] and then drill down to [base_image] and replace the pix_image with video or whatever you want.

Also, at the bottom of the help file for [block~] you will see that it is possible to match the block size exactly to the frame rate....... but with constraints on audio objects.
David.

also there is [pix_data] to try. I had some success to downsample images like that, than process data and resample the picture using a reduced resolution using [gemvertexbuffer]

Thank you everyone for your answers, I'll take the time to study all of your suggestions.
Since the last time, and the @ingox answers, it works fine with tables but i get weird result when i use all of them at the same time, as if it can't synchro the treated audio signal to the "gemlist" connection of the gem objects.
So @whale-av I'm affraid that you're right about the real-time, but it works well when you don't put to much tables. I'll have a look at what you put there.
Also, because I use [pix_pix2sig~], I must fix the blocksize to the number of pixels in my image (128x128 = 16384 in my test image).

@Johnny-Mauser, interesting this object, but do you think that i'll be able to reconstruct an image from these data ? Is there an obect to do the reciprocal transformation ? Maybe it will work if i put the data in a table and use [tabreceive~] in the [pix_sig2pix~] object like i do for now.

After an inimaginable number of hours, i finally resolve the problem I said above ! The main issue was due to the fact that the table with the "concatened signal" has to be in a sub-patch with bocksize of 3 times the blocksize of the originals RVB signal !

-facepalm-

Now it's working well, with descent image size i can do someting close to real time, I just need to actualized the table information regulary using a [metro].

You all gave me useful informations, definitely !

Cheers

Px

@Parallax [gemhead] sends the message "gem_state (pointer) (pointer)" every frame...... so you should be able to sync better with a bang connected to the outlet of [gemhead] than with a separate [metro].
Use a [t a b] to get the order right....... or as my head is not completely around your patch..... maybe [t b a] or........ maybe it doesn't matter.
If you stay with pix objects (no gl shaders] I think that will work, as all will be synced to the cpu.
You should try a frame-rate that will sync to the gpu as closely as possible though.......
https://lists.puredata.info/pipermail/pd-list/2007-10/054906.html
Aaaaargh....! as they say
Any problems with gem that you google add "cyrille henry" in your search and you should get straight to the answer.
David.