[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-users] Graphics, Video and SC
Approach 4: the language does everything, and produces Messages
conforming to Server-command_reference, but send them to a Graphics
Server.
example:
g = Server("localhost", 12000) // the graphics engine;
Synth.grain(\GRect, ["extend", 100, "speed", 13, "lifetime", 2], g);
A simple interface for graphical grains (with node-id -1) is already
done (in processing *), but the difficulty is not the messaging and
tracking of nodes, but the sending/parsing of UGenGraph informations.
I do not know how to read them...
2c
Till
_
*) Yes I've looked to codetree, but my script is not able to produce
anything on-line in applet-form since it uses OSC (which isn't
allowed in the sandbox for obvious reasons). So if you are
interested, I'll send it to you
On 03 Jan 2006, at 14:49, JostM wrote:
crucial felix wrote:
The cleanest separation is to get the pro55ecing/flash etc. app
to send a message to an OSC address like :
The graphics/ sound issue seems to me already to be an issue
_within_ SC. I have three approaches:
Approach 1: What I use currrently.
I have an installation with "sound objects" whose relations to each
other are representable as motion in 2d or 3d space. For example, I
can have an object make a circular motion by running two SinOsc.kr
with pi/2 phase difference. Polling their out busses then gives me
the x (i.e.cos) and y (sin) values for plotting a circular motion
in real time. Control rate is much too fast actually for video, but
this is an easy way to have a common source (synchronized) for both
audio and video control.
So now all I do is , e.g., to map a 4 channel pan to the x and y
out-busses of the sin/cos synth, and then poll those same busses
for the video every 24 seconds (even 12 works quite well). This is
alot of server messaging once you get to about 30 or 40 objects in
space. And remember, you have to gather all of the busses for all
of the objects for every time you call w.draw.
Approach 2: mirror the kr and video functions independently and
make sure they are synchronized. I haven't worked this out yet,
but it would mean, in the above example, to write routine with sin
and cos functions with a (1/24).wait loop, and make sure that the
phase of the sin function is the same as that of the kr synth which
controls the audio. This seems very complicated, but perhaps I
could write some kind of a general sync function for use in most
circumstances. The advantage, is that the messaging to the server
is kept at a minimum.
Approach 3. SC Lang controls everything. Panning in space does not
have to occur at control rate either, after all. So SC Lang could
send messages with the position info to running synths and draw at
the same time. This would happen again 24 time per second. No
advantage over Approach 1 as far as messaging is concerned. Now all
the motion calculation is done by SC Lang and then sent out. In
Appr. 1, the Server was producing the motion information and then
being polled.
I have noticed that the drawing in SC starts to get irregular at
arround 50% processor use (1.5. GHz Powerbook g4).
In a sense, Approach 2 would be the best, I guess, especially if
things are distrbuted on many machines.
All of these approaches are just as relevant when you use several
computers, say one for SClang, one for SCSynth, and one for
proce55ing.
Yet just how much messaging can I do? If I have 50 objects in
space, and am messaging at 50* 24 * (2 (or 3) Busses) per second,
I think things will get too swamped. And we can double this if the
video is done by proce55ing on another machine.
It works with up to a bout 40 or 50 objects if I do it on the same
machine, the .ar synths are very simple, and SC is handling the
drawing.
So perhaps Approach 2 is the right way?
any opinions?
JM
_______________________________________________
sc-users mailing list
sc-users@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-users