Is there a way to take multiple video signals using GEM, sample only portions of them then recombine them into a single frame.

For example I need to divide video into 4 separate sections across the screen, think of layers stacked on top of one another. the video will be sampled from multiple input streams such as camcorders. each camcorder covering a zone in the stack of video.

so simply put can you select a region in the gem output to display. something like a layer mask?

Does anyone know if puredata has a port started or completed for the PS3?

I know not many people would be doing this but I am interested in seeing how well this would work.

I just wanted to share a 16-step midi-trigger sequencer. I might not look nice but it works.

http://www.pdpatchrepo.info/hurleur/16-step.pd

I have been trying to find the best way to do this simple thing and I am looking for advice. I have a sub patch called selectMode which has 2 signal inlets and 1 number or message inlet for selection. The two signal inlets use one of 4 signal mathematical elements +~, -~, *~,or /~.

Now i have attempted to use a few options to use only one of the 4 mixed outputs. The most logical seemed to be polygate~. However, I had no luck with that. Is there any anything similar to this function which would allow me to select 1 of X inputs for output?

I am experincing a horible glitch/pop sound with any OSC~ function I use. I have read this could be a result of the frequencies amplitude being beyond the capabilities of the computer audio card. I am using a G4 powerbook, with Mac OS X 10.4.11. This sound is not present during the use of noise~

any help with this would be great.

@sonsofsol said:

@dioioib said:

Well yes I need to take 3 video signals and stack a section of them to form one body or image.

for this id use 3 separate gemchains
everyone looking like:

[gemhead]
I
[translateXYZ] -- 0 -1 0 for 1st, 000 for 2nd, 0 1 0 for 3rd
I
[pix_video] -- device 1 - 3 or so
I
[pix_crop] (if needed)
I
[pix_texture]
I
[rectangle]

Sonsofsol regarding [pix_crop]I am having issues with setting dimensions and offsets as there is no information on the sizes. I find that I usually end up with a crop that does not fit to the dimensions required or is not in the proper offset. Am I correct in saying that the dimensions of the capture source are not the same as the rectangle and/or Gem window? If not how do I correct for this issue or does the placement of the [pix_crop] before the [pix_texture] correct the problem I was having?

Well yes I need to take 3 video signals and stack a section of them to form one body or image.

so divide the image plane into 3rd's and put them one on top of the other. The idea is to have a section for head, torso, and legs, so they will be stacked vertically.

[gemframebuffer] i am assuming is the entire buffer for that video frame? So could you unpack it as raw YUV / RGB data and recombine the sections into one frame or is there an easier way to do this?

So I had some ideas should I be drawing everything into one [rectangle]
Is there a way of taking the stream of data and just displaying that in sections so part 1 is lets use an arbitrary value of 4000 pix then part 2 is 4000 then part 3 is 4000, but have them display as a a hole in one rectangle?

I am having some real issues with this. First I can't open the patch as it crashes right away. I am on a mac so I don't know if that is the difference.

In my existing patch I can not get pix_crop to work properly. I can get multiple input streams USB and Firewire to test for now until I can get 2 more firewire cameras. The patch seams to have all the info I need but I just can't seem to stack the video the way I need to or get the crop to work at all.

Bellow is my semi functional patch. Some things are hood up and others not as I am in the middle of testing it. But if you have any suggestions let me know.

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

thanks for the tips. I was expecting the need for firewire cameras for some reason and the fire-i boards look fantastic, and have some lens options which will really help out for this project, of course price is always an issue but there pricing isn't bad.

I'll give [pix_crop] a try sounds like exactly what I need to use.

Sonsofsol: how did the project handle the 4 input streams? Did you encounter any issues with delay or latency?

arif, i already have it installed on my box so I don't need to worry about the removal of the feature as I have no intentions of updating to the new firmware.

My interest is in the computational power of the cellBE, and using it for computational intensive programs like puredata.

Was there ever anything born out of this? I am interested in solving a similar problem for an exhibition. I have been reading some interesting posts about hardware limitations with multiple cameras but have not found anything corroborating this.

You would want to use the Firmata firmware on the arduino so it will transmit the data directly to a serial line. I have never experimented with Xbee so I am not much help there. For that you might want to ask on the arduino.cc forum. Here http://www.arduino.cc/playground/Interfacing/PD

As for the pd~ patch there are examples on the above link.

I will help where I can.

@Maelstorm said:

Any aliasing you get from playing it faster is already going to be applied before it hits those filters. If you wanted to get rid of it you'd have to stick the sample playback parts with the filters in a subpatch and in increase the samplerate using [block~]. I think the artifacts you're hearing are coming from the grains comb-filtering each other.

I'm finding that there was aliasing in general not just from the speed increase. Perhaps I am using the incorrect term for the effect as its more like bit rate reduction. I find that the filter chain at the end works well for the results I want. This is a technique I use to improve the quality of a DAC built in circuit. Plus the cheby~ can create some crazy sounds if the variables are modified.

You might be right about the comb-filtering of the grains though. I'm going to experiment with it a little more. I love this patch though, reminds me of spinning records.

Thanks,

its big but I want to check this out. You have obviously put a great deal of work into this project.

So I have been experimenting with the timestretch2 and found the aliasing caused by the processing to be a little bit of an issue so I introduced a small 5th order low-pass filter and a cheby~ and find it improves the sound to a degree. Also I modified some of the characteristics of the sample playback which re-trigger the messages, I was finding it was not playing back audio on PD~ for MAC OSX until I reapplied the messages.

I'll post the solution to the extended sample time when I finally attempt it.

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

@Maelstorm said:

That's something I didn't handle in my patch, either.

I have been experimenting with your patch and i find I can get it to work with shorter samples quite well but what can I do to modify it for use on an entire track of say 5 to 10 min in length?

@boonier said:

[mux~ 1 2 3 4]

Perfect works great. I am not sure what was happening with the patch the first time but it works now. Does order of connection to the inlets matter with that particular object?

That worked a bit the glitch is still there in the background. Its like a metronome. I have to say it sounds a lot better now than it did before.