[chuck-users] other ways to live-code with time

[Kassen]

Rob;

> Howzzat?
>
> ChucK promises deterministic timing on a single processor. The only way
> ChucK can take advantage of multiple processors is by synching them
> together, and techniques for synchronizing multiple ChucKs are generally
> non-deterministic.  And it takes extra work to do this.

Well, you can have multi-core deterministic performance, it just
potentially means some cores will be waiting some of the time. This
can be ok or terrible, performance-wise, depending on how clever
people get and the application. For some applications paralel
processing hardly has any benefits at all.

>
> If I understand correctly, Impromptu uses any available processing power,
> regardless of where it comes from.

Likely, yes, and judging from Andrew's videos it's a lovely system
with very respectable graphical capabilities as well.

>
> So I believe that in a world where processing power gets cheaper and faster
> every year, Impromptu will have an advantage.

In some regards. I also read and appreciated your note on Ethernet.
SC, for example uses the network protocol to communicated between the
"server" and the "language", SC is also generally recongnised to be
very fast indeed. However, execution order in SC can be a tricky
affair that SC specialists sometimes have to spend quite some time and
some care on to get it to behave. Neither of those languages will do
DSP right in the language itself like ChucK will. This is a trade, you
get some nice things for some less nice ones, it might be a good trade
or a bad one depending on your needs.

I don't think you can compare them purely on CPU usage, like you can't
compare a Unimog (A Mercedes-build mountain-truck with 25 gears, 5 of
which are reverse) to a Ferrari purely on speed; though both are cars
they excell at very different things.

I do think it would make sense to start thinking about how ChucK could
make use of multi-core or multi-cpu setups (and fortunately this has
been hinted at) but these concerns are hardly the be-all end-all of
audio programming; quite often precision to the single sample will
matter a lot, maybe not often in sequencing but there is more to sound
than just sequencing.

There are certainly challenges there but I'm still quite happy with
the choices ChucK made here.

Yours,
Kas.