Re: [ecasound] MISC: Of dump-commands

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] MISC: Of dump-commands
From: janne halttunen (
Date: Fri Oct 27 2000 - 16:25:11 EEST

> > The dump-commands have been useful in my ecasound-frontend at
> > reducing the parsing of ecasound normal output. You have to, however,
> > to request the dumping, there's no automatic 'when value changes'
> > dump-objects. I don't know if it would be worth the effort to extend
> > the dump section with commands like: dump-object-add
> > <value-to-dump-when-changed>, or to have multiple dump-targets.
> [...]
> > Depends on you Kai, but I guess at some point it would be easier
> > to go straight to libecasound. How is it going with the C-api? :)
> The C-api is still in the "might-be-implemented" section. But unlike many
> other todo-items, I'm willing to give this top priority. I'm just still
> unsure whether C-API is good enough. As you might have noticed, I'd like
> to get more people involved in ecasound development (either ecasound
> itself, or apps using ecasound/libecasound). There are so many things I'd
> like to try, but I just don't have the time. I've tried to make the C++
> API as usable as possible, but this hasn't received much interest. So
> far, extending the console mode API, and providing LADSPA support have
> proven to be most useful. But what to do now...
> Possible solutions:
> 1) continue to extend the iactive-mode
> 2) provide a small C-API (easy to maintain)
> 3) provide a more functional C-API (C wrapper for C++)
> 4) provide wrappers for scripting languages (Python, Perl, ?)

     The problem I had with the C++ API was that when I tried (sometime ago) to make Python-bindings for it with SWIG, (Simplified Wrapper and Interface Generator) it
spewed out too many error-messages to even begin with. I learned that SWIG was most suitable for binding C-stuff.
     While I was exploring the possibility of a Qt-ui for Heteca, I found that there's one bindings-generator that's specifically made for C++ and Python, called SIP.
(the PyQT/PyKDE bindings are done with it)
I haven't been able to compile it yet, (probably due missing -devel packets) but so far it seems promising. ;)

    SWIG, on the other hand has support for multiple scripting languages. (including Perl) There supposedly are some plans to expand the C++ support in future

> I have little experience with the above mentioned "scripting" languages,
> so it's difficult for me to compare the alternatives. Writing a simple
> C-API (2) would be a quick task, but I'd like to know what functionality
> is needed to do actually do something useful. Here's a short example:
> --cut--

> How does this look? Implementing the above would be really an easy a task,
> but as you imagine, it can quickly turn into a maintainance hell.
> Thoughts; what would be a good subset of libecasound functionality?

    The main thing in my mind is quick access (minimal/no parsing) to ecasound variables, like: engine status, aio-positions and cop-values. The dump-commands help,
but I'm thinking the position-slider should rather be sliding than jumping. :)
    I think that it could be achieved either by instant access to the variables (through some sort of bindings), or (in iactive-mode) automatic value dumping with
adjustable intervals to dedicated dump-targets. The first one is perhaps more reasonable, since in dumping there's always the conversion from string to int, which
slows things down.


To unsubscribe send message 'unsubscribe' in the body of the
message to <>.

New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Oct 27 2000 - 16:35:37 EEST