Dear PD folks,
I'm trying to cook up a Pd/GEM version of the Rutt-Etra scan processor, which sends audio signals to an analog CRT vector monitor/oscilloscope/etc to control the vertical and horizontal positions of its beam, plus its brightness.
The video posted here is webcam->MaxMSP->MOTU soundcard->Vectrex console display, using the [jit.matrix] and [jit.peek] objects:
https://www.instagram.com/p/BWk5imsAao1
To do this in GEM, I need to read the luma values of the pixels in a video stream according to their X and Y positions with the horizontal and vertical signal ramps which form the video raster on the CRT (using [phasor~] for the vertical scan and a multiplication plus a [wrap~] for the horizontal scan), and send that value out as a third audio signal to control the brightness of the scan line on the monitor.
Here is a block diagram of the original Rutt-Etra for the curious:
http://iasl.uni-muenchen.de/links/GCA_ill76.png
The issue that I have run into so far is that [pix_data] from GEM only responds to control rate messages. PDP has the [pdp_scanxy~] object which does basically what I'm looking for: get luma values at given X Y coordinates of the image based on an audio signal input, and send those values out as an audio signal. I've gotten a rough raster with this already, but for various reasons I would prefer to stay clear of PDP.
Can anyone tell me how fast the [pix_data] object can respond? I have been using a [metro] operating at a rate of one bang per sample, and I have set a [block~ 1] in the subpatch doing this analysis.
[timer] reports an interval of 0.022 ms between bangs @44.1K, and 1.451 ms between changed pixel values coming from [pix_data]. (Unchanged values are redundant.) In fact, the rate between the metro and the GEM object match until I go under 64 samples, then it becomes erratic. Is a 64 sample block size hardcoded into [pix_data]?
Can anyone see how I could get audio rate data out of [pix_data], or if there might be another way to get luma values with an audio signal?
Thanks and best wishes! Derek
On 2017-07-17 11:52, Derek Holzer via Pd-list wrote:
Can anyone see how I could get audio rate data out of [pix_data], or if there might be another way to get luma values with an audio signal?
i've never had a problem with [pix_data] at audio rate, using something like the following:
[inlet~] | [tabsend~ $0-x]
[bang~] | [64( [until] | [i] [+ 1] [% 64] | [tabread $0-x] | [pix_data]
there's two "tricks":
- converting the signals to message domain, using [table]
- accessing multiple pixels in zero logical time (using [until])
fgm,asdr IOhannes
Very interesting!
However, what comes out is still limited by the block size to every 64 samples as far as I can tell. I've tried every trick I can to send sample precise messages in, but all I ever get is 64 sample rate messages out.
Or am I missing something? See attached.
D.
On 17/07/2017 11.59, IOhannes m zmoelnig wrote:
On 2017-07-17 11:52, Derek Holzer via Pd-list wrote:
Can anyone see how I could get audio rate data out of [pix_data], or if there might be another way to get luma values with an audio signal?
i've never had a problem with [pix_data] at audio rate, using something like the following:
[inlet~] | [tabsend~ $0-x]
[bang~] | [64( [until] | [i] [+ 1] [% 64] | [tabread $0-x] | [pix_data]
there's two "tricks":
- converting the signals to message domain, using [table]
- accessing multiple pixels in zero logical time (using [until])
fgm,asdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2017-07-17 12:38, Derek Holzer via Pd-list wrote:
Very interesting!
However, what comes out is still limited by the block size to every 64 samples as far as I can tell. I've tried every trick I can to send sample precise messages in, but all I ever get is 64 sample rate messages out.
did you consider converting the data back to audio-domain with [table]? ([tabwrite]+[tabreceive~])?
Or am I missing something? See attached.
ouch. that shouldn't work at all. on each [bang( coming out from [bang~], you first start a counter going from 0 to 63, and send the corresponding table value to [pix_data]. once the counter is finished (and its value has settled to 63) you start a second counter doing the same. once both counters have reached 63, you are sending a bang to [pix_data] to read out a single value. so for each dsp-tick you are fetching the colour of the last (63rd) sample.
ghamdr IOhannes
OK then I think I need a little more help understanding what is going on here then please.
Should I be sending a bang every sample to the left most inlet of [pix_data]? How do I synchronize all the reading counters so that every sample I get a new value of the luma value at X and Y?
I have tried the same 64 sample counter for both X and Y inputs of [pix_data], and a metro at a rate of one bang per sample to the left most inlet, but I'm still not there yet.
D.
On 17/07/2017 12.59, IOhannes m zmoelnig wrote:
ouch. that shouldn't work at all. on each [bang( coming out from [bang~], you first start a counter going from 0 to 63, and send the corresponding table value to [pix_data]. once the counter is finished (and its value has settled to 63) you start a second counter doing the same. once both counters have reached 63, you are sending a bang to [pix_data] to read out a single value. so for each dsp-tick you are fetching the colour of the last (63rd) sample.
Sorry I guess I need a bit more help figuring out what you mean then please.
Should I be banging the left most inlet of [pix_data] once every sample? I am now sending the same until 64 counter to both the X and the Y inputs. But I am still having trouble understanding how to synchronize everything so that for every sample I get a new luma reading of a given X and Y coordinate.
D.
On 17/07/2017 12.59, IOhannes m zmoelnig wrote:
ouch. that shouldn't work at all. on each [bang( coming out from [bang~], you first start a counter going from 0 to 63, and send the corresponding table value to [pix_data]. once the counter is finished (and its value has settled to 63) you start a second counter doing the same. once both counters have reached 63, you are sending a bang to [pix_data] to read out a single value. so for each dsp-tick you are fetching the colour of the last (63rd) sample.
OK, I simply wasn't paying attention to proper structures with until and a counter, I have worked it out now. Thank you for your patience IOhannes, I will post some deliverables of this project soon.
Derek
On 17/07/2017 12.59, IOhannes m zmoelnig wrote:
ouch. that shouldn't work at all. on each [bang( coming out from [bang~], you first start a counter going from 0 to 63, and send the corresponding table value to [pix_data]. once the counter is finished (and its value has settled to 63) you start a second counter doing the same. once both counters have reached 63, you are sending a bang to [pix_data] to read out a single value. so for each dsp-tick you are fetching the colour of the last (63rd) sample.
-
Derek Holzer -
IOhannes m zmoelnig