15 Jun
2006
15 Jun
'06
11:56 a.m.
On Thu, Jun 15, 2006 at 08:53:11AM -0400, Paul Davis wrote:
On Thu, 2006-06-15 at 16:32 +0900, David Cournapeau
wrote:
The bottom line here is that this sort of thing is dictated by the system,
or by interfaces close to it such as JACK. And you better do thing the way
the system expects you to, unless you are prepared to accept intermediate
layers that add overhead and latency.
One could in theory contruct a language that knows the concept of a
'period' of frames, and that allows you to write audio code and be
oblivious of the fact that is in fact processed in chunks of N frames,
that you have to maintain state between callbacks, etc. But you can
only hide these things up to a certain point. When you write some
code that maps badly onto the current period size, then either it
will be be very inefficient, have horrible latency, or the language
will just fail. So the result would be that the language becomes the
thing that determines what sort of functionality can be programmed
and what can't, and in that sense it has indeed become an 'application'
rather than a language: it only allows you to do those things that
were envisaged by its designer.
There is a similar situation with multithreading. ADA is one of the
few languages that supports it natively, and most early ADA compilers
had their own implementation. But if you want your ADA tasks to
interact in a natural way with the surrounding system, then you have
to use the system's concept of what a thread is (i.e. construct the
ADA tasks on top of NPTL), and it's near impossible to do this without
either exposing somehow the underlying system to the user, or limiting
the functionality.
--
FA
Follie! Follie! Delirio vano e' questo!
I am in no way as experienced as most people on
this list for audio
programming, but I don't see why C/C++ should be the only way to write
software to handle audio stream, neither do I see why GC would be the
only useful feature. For example, having language constructs to
explicitely handle "time line" sounds like a good idea to me, and it
looks like both Faust and chuck enable that.
there is no universal agreement on how such features should work. if you
provide a "language" in which this is possible, you're really providing
an application (such as supercollider).
a some builtin language idea about what a playlist looks like ? there
are many variants on the idea of a playlist, and i don't think you can
usefully provide abstract building blocks (which is what a language is
for) and support all the variations without compromising at least one of
those goals.
faust, btw, has no concept of a timeline in the sense that chuck does.