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 geos.
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, Thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
hi Thoralf, i'm not a GEM master but if you want a functional oscilloscope, i would recommend you give [fiddle~] a try. it will output a wider and richer amount of data than [snapshot~]. i use it all the time and it's acid.
r
% evol~~~~~~ http://www.mego.at/evol.html
% alku~~~~~~ http://personal.ilimit.es/principio
% imbécil~~~ http://imbecil.net
% foofoofoo~ http://openserver.cccb.org/~foofoofoo
hello,
i think pack~ and unpack can help.
pack~ the audio data to a list, unpack the list to change the Y position of the 64 spheres. (each element of the list should change only 1 sphere position).
cheers, cyrille
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 geos.
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, Thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
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 geos.
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, Thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi
thank you all for your input. I'll have a look at your suggestions ... if I come up with something, I'll post it.
bye, Thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-
carmen -
cyrille -
roc -
Thoralf Schulze