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: > > 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.
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!
