Re: [sc-dev] demand rate

[Charlls Quarra <charlls_quarra@xxxxxxxxxxxx>]

i don't think that is necessary to have the previous architecture to have the previous functionality; the question is more like; how high-level we can specify our ugen network thru the language thread in a way that it gets efficiently compiled for the scsynth digestion. afaik the only problem i see right now with general purpose compilation of language into ugens is that, while synthdefs are syntactically equivalent to function declarations, and synths are function calls, there is no way to call a "function" from inside other "functions" (synths cannot generate other synths) so we are stuck at 1-level depth recursion. This is why i think the emphasis must be put in a synth spawner ugen.

ronald kuivila <rkuivila@xxxxxxxxxxxx> escribió:

It is totally serious. The problem is that the language is inherently "bursty" in its load on the system.  

This created glitches in SC2, where  the language could interfere with the computation of samples.

Decoupling the language from synthesis makes a much more robust system.

In the case of the internal server, there could be defer mechanism to schedule

code at a lower priority than the server thread (this is what happens at language level already

moving from the SystemClock and TempoClock to the AppClock).   That would be as close as you could 

get to SC2 while maintaining the decoupled performance.

RJK

On Feb 22, 2006, at 12:07 PM, Charlls Quarra wrote:

 

 the idea of "language in a ugen" is disturbing but amazing, i have yet to realize it fully. At first i thought it was a taste of JMC wicked sense of humour, but now i'm suspecting it was partly serious :D

crucial felix <felix@xxxxxxxxxxxxxxxxxxx> escribió:

'm extremely curious; what exactly "spawning a pattern as a ugen" is about? I'm not aware of what i'm missing since i've never tried SC2

 

Pbind.new.play

// i think ron means this :

{

Pbind.new.ar

}.play

// Patch is here just valueing its function

// it isn't creating and managing its own inner synth

{

Patch({ SinOsc.ar }).ar

}.play

the ideal situation would be :

it added itself (invisibly) as a normal player to the inputs of the enclosing Patch

so it would get started at the ! same time, correct order of execution, handle all the inner patching etc.

Patch({

Patch({ SinOsc.ar }).ar

}).play

then

Patch({

PatternPlayer( Pbind.new ).ar

}).play

could easily work

On Feb 21, 2006, at 2:15 PM, Charlls Quarra wrote:

ronald kuivila <rkuivila@xxxxxxxxxxxx> escribió:

Another issue is that the spawner is not going to be able to use
the language. I wonder if this is going to be enough to
recapture the flexibility Crucial was talking about... In SC2, you
could s! pawn a pattern as a ugen - that ain't gonna happen in
SC3 ever. The kind of spawning being discussed is more like the
OverlapTexture style ugens.

I

_______________________________________________
sc-dev mailing list
sc-dev@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-dev

---

1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
Abrí tu cuenta aquí

_______________________________________________

sc-dev mailing list

sc-dev@xxxxxxxxxxxxxxx

http://www.create.ucsb.edu/mailman/listinfo/sc-dev

_______________________________________________
sc-dev mailing list
sc-dev@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-dev

---

A tu celular ¿no le falta algo?
 
Usá Yahoo! Messenger y Correo Yahoo! en tu teléfono celular.
 
Más información aquí.