Re: [ecasound] boolean and small-choice values?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [ecasound] boolean and small-choice values?
From: Mario Lang (
Date: Mon Oct 21 2002 - 13:49:05 EEST

Kai Vehmanen <> writes:

> On Sun, 20 Oct 2002, Mario Lang wrote:
>>> cop-register), and 'map-cop-describe x' would return a decription string
>>> for the xth cop type in the list. The syntax could be something like...
>>> 'name,number_of_args,arg1_default,arg1_lowbound,arg2_highbound,...'
>> To be honest, I'd prefer cop-register to just do all that at once.
>> Otherwise I'll need to issue N+1 commands to get all the info I want...
> Hmm, as a little background to this issue, the xxx-register commands
> were basicly a quick hack to somehow export information about registered
> objects. The output these commands produce is meant for human users.
> But I guess, as both Janne and you have already parsed these commands in
> scripts, their output is also suitable for programs.
It is, yes.

> One thing that is stopping from adding more stuff to register cmds is
> that adding more info will make the output hard to interpret for
> human-users. And also, because all the data is in one big list, adding
> more per-object info fields later on would break current parsers.
So what about equivalent *-descriptions commands?

It could look like:

cop-number. "description",arg1_type,arg1_default,arg1_low,arg1_high;"description",argN_type,...

arg_type could be bool, float or integer.

Not sure how to expose a choice-arg. Is this info available,
like the waveform selection copps we have?

> But anyway, suggestions are welcome. I think you and Janne are the best
> persons to say what kind of output would be good to have from parsing
> point of view. Here's a short list of available information that is
> already available in libecasound:
> - all object (audio objects, chainops, controllers)
> - keyword ('alsa', '-efl', '-ea', '-el:decimator', etc)
> - name ('ALSA PCM Device', 'Lowpass Filter', 'Amplify', etc)
> - description (longer version of name)
this longer description, is it exposed already? never saw that.

> - number of parameters
> - parameters names
> - additional info for chainops (native effects,
> presets, LADSPA plugins) and controllers
> - for each parameter
> - default value
> - description
> - is_bounded_above
> - and if yes: upper_bound
> - bounded_below
> - and if yes: lower_bound
> - toggled (on/off)
> - integer (only integer values)
> - logarithmic (user-if should provide a logarithmic scale)
> - output (parameter is an output parameter)
> This is quite a lot of information. I could put export this in one list,
> but that would be quite a huge one. But let me know what you'd like to
> have, and how to format the information.

I'd suggest we leave *-register like it is, to also not
break backward compatibility, and add a *-description command
which produces basicly the same numbered list, but with the
descriptive stuff, like type, bounds, defaults, and so on.

Is this possible/easy?

>>> Yup, these are directly related (they set PARAM_DESCRIPTION fields for the
>>> preset that is being defined).
>> So, do you have any plan to expose this information through eci? I was just
>> wanting to add preset-register support to ecasound.el and noticed
>> that I cant find a way to get on the -ppl and -ppu information, so before
>> I start doing anything which needs complete rewrite later on, I wanted to
>> ask how the schedule is there...
> Well, it depends on what kind of output and how many new EIAM commands
> are needed. If it's an easy task, I might have time to add this
> functionality before 2.2.0. Otherwise it'll take some time.
Given the fact that 2.2.0 will only have ECI as preferred
(only?) way of accessing ecasound, I stronlgy hope this
can go in before the release...


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Oct 21 2002 - 13:46:44 EEST