Re: [sc-users] Graphics, Video and SC

[JostM <sc@xxxxxxxx>]

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