Subject: Re: [ecasound] extending the C-API design
From: S. Massy (theanaloguekid@tak.net.dhis.org)
Date: Mon Nov 06 2000 - 19:07:10 EET
On Sun, 05 Nov 2000, Kai Vehmanen wrote:
>
*clip*
> On the other hand, does anyone really want lowlevel (in audio world this
> would mean sample-level) access from scripting languages?
>
IMHO, no; I'm no guru but it seems to me that there are three major
ways in which one would need an interpreted language to interact with
ecasound's engine:
-- To make one's life easier: simplify down to a single command (with
maybe a few arguments) an operation that otherwise would require a
very complex command or a long set of IA-mode commands (to which the
sequence would be conditional to certain results).
-- Interfacing: "Scripting" languages are often used to create
front-ends to other programs nowadays (e.g: perl (perl/tk sometimes,
though I'm not familiar with this mix), python, etc.). (So here one
could create "specialized" front-ends for different purposes.)
-- Other purpose: Programs for which the end would not be to interact
with ecasound but rather a mean to make the program "sound-enabled".
I'd be curious to hear if anybody here sees some other way in which it
could be used... Anyway, I don't see in the above utilizations any
need for "lowlevel manipulations", maybe they would have their place
in the C API itself however.
I guess, besides the IA-mode commands that would need to be available
(and return extended information), what would be the most needed would
be functions that would return info on mostly every aspect of the
engine's state (What's connected, to what position it is, what are the
characteristics of each objects, and so forth)
Just my two cents,
S. Massy
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Nov 06 2000 - 19:21:39 EET