Subject: Re: [ecasound] boolean and small-choice values?
From: Mario Lang (mlang_AT_delysid.org)
Date: Mon Oct 21 2002 - 13:49:05 EEST
Kai Vehmanen <k_AT_eca.cx> 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...
-- CYa, Mario
This archive was generated by hypermail 2b28 : Mon Oct 21 2002 - 13:46:44 EEST