Subject: Re: [linux-audio-dev] LADSPA Control Protocol v0.0.1 now available
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri Dec 07 2001 - 21:04:46 EET
>> int lcp_write (lcp_client_t *client,
>> unsigned long plugin,
>> unsigned long port,
>> LADSPA_Data value);
>
>Is this unsigned long plugin the ladspa_id? If so how does the server know
nope.
>which instance its meant for (assuming there are several)?
>
>I presume that eventually the gui will be called with
>argv[1]=<server-address> and argv[2]=<plugin-id>.
precisely.
>If there is one socket per GUI then why does the client need to specify?
excellent point. we will remove `plugin' from the API for read/write
and add it to the lcp_open() call. we'll stick the value given us in
the lcp_client_t struct, and use it implicitly. sending it with the
request saves the host doing a lookup in a file-descriptor<=>plugin
map.
>> int lcp_read (lcp_client_t *client,
>> unsigned long plugin,
>> unsigned long port,
>> LADSPA_Data *value);
>
>And I guess this isn't implemented yet? Will it be a case of adding the
>pid to a select and then calling it when it comes up?
i can't figure out if it should be poll/select-able or not. its
generally fine for most GUI's to do low-frequency polling. however,
its not very elegant, and in the worst case results in a lot of
traffic for the host. so i suppose that yes, it will have to be
implemented via a similar (select/poll-centered) mechanism as the
server side (where the read stuff is already implemented). coming up
tonight.
--p
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 21:03:08 EET