? wrote:
[Rory Walsh]->[Re: [PD]Creating noise in Gem]->[02-05-31 17:22]
|I can't seem to find the sig2pix~ object? Is this an |extern? I'm using windows 95, thanks again for the |help.
got it from ftp://iem.at/pd/Externals/GEMEE/
There is a pix_sig2pix~ in the new gem release, I am not sure if it is the same one that was in the gemee ....
pix_sig2pix~ (from GEM>0.87) is not exactly the same thing as sig2pix~ from GEMEE::: GEMEE's version uses a per-line interpretation of signals (this is: signal vector n is used as pixel-line k; in the next dsp-cycle, the same signal-vector n will be used as pixel-line k+1 (at least, that is, how i understood it) GEM's object is a per-image interpretation: (thus signal vector n will be interpreted as y consecuting lines if pixel-data; in the next dsp-cycle, the old signal-vector will not be re-used) this is the same approach as in the SOLVE-library by Michael Droettboom.
in practical terms this means: GEMEE's object will eventually have scrolling images (which might be no problem when generating noise) because the signal-vectors are reused. i thought this somehow unpractical, especially, when converting images to signals, doing some manipulation (in dsp-domain) and converting the signals back to images. images created by GEM's object will always stay synched to some external clock and therefore will not scroll. however you can obtain a scrolling effect by delaying the signals. the major drawback is, that you will need large blocksizes if you want high resolution. eg: for a 128x128-image, you need a [block~ 16384] somewhere, else only a part of the image might get drawn (for example: only 64 samples, which would equal to half of the first-line) of course you might want to set an overlap-factor (or upsampling ???) to get more than 4 images per second.
mfg.cdsa.dr IOhannes
PS: there seems to be a bug in the reverse pix_pix2sig~ object, which keeps crashing my machine...(have had no time yet)