[PD] [gem] - repeated objects vs. time
ix at replic.net
Mon Jan 24 11:51:09 CET 2005
On Mon, Jan 24, 2005 at 11:23:47AM +0100, Thoralf Schulze wrote:
> Hi list,
> I really learned to love the use of repeat with gem -
> there's nothing more tedious than creating 100 or so
> geos by hand. In fact, my threshold is closer to 10
> I tried to build an oscilloscope that way the other
> day - and failed miserably. The idea was simple
> enough: repeat 50 spheres or so, distribute them
> evenly on the x axis and get values delivered by
> snapshot~ as amplitude for each of them. Having only a
> vague idea of what fft actually does, snapshot~ seemed
> to be the right choice to me: it outputs values on
> bangs, and the output is in the -1 to 1 range.
> I got only vertically moving straight lines. At first
> I thought that snapshot~ was too slow and replaced it
> by env~ with various block sizes - same thing. The
> surprising thing was that the value delivered by
> either snapshot~ or env~ was the same for all of the
you can use a fixed table size (say 441) and bang it 100x a second and feed that to a linestrip. ive not used GEM so not sure how you create a linestrip...but you should be able to call the function however its wrapped..
> So it seems like all repeated geos are created
> simultanously - okay. I then tried to introduce some
> delay into the render chain, with no success. Could it
> be that "the joys of statemachines" are a major
> drawback in that respect?
> Now, it would be really cool if someone had an answer
> to these questions:
> - do I have to use uzi & until for creating delayed
> render chains created with repeat?
> - what about single- vs. doublebuffering?
> - if render chains cannot be delayed at all, what
> about this: the audio input would be continously
> sampled each x milliseconds, the results are stored in
> a table. These values will then be used to determine
> the amplitude of so-and-so-many points of a curve that
> would be created by repeat. The index to the beginning
> of the values to be used will be increased by one with
> every frame gem is rendering. Obviously, one would
> have to implement some sort of looping
> sampling/indexing, otherwise the table would grow
> infinitely ... Is there a realistic chance of getting
> this to work?
> Thank you for your help,
> Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
More information about the Pd-list