Re: [LAD] LAD] RT-Safe UI/Engine Decoupling using Functional

On 08/06/2011 11:26 PM, Florian Paul Schmidt wrote:
> On 08/06/2011 10:55 PM, Jeff McClintock wrote:
>> I'm just in the process of porting my plugin to a platform where the GUI
>> runs on Windows, but the Audio processing runs on an real-time optimized
>> Linux box.
>> With the proliferation of iPads etc, I see this approach of mixing
>> a cool
>> portable GUI with a Linux 'powerhouse' audio processor become more
>> common in
>> studios.
>> Surly passing functors (which are pointers?) to audio code running
>> in a
>> separate address space can not work?
>>
>
> No, a functor (in c++-speak) is an object that has operator() and thus
> behaves in a way like a function (thus the suggestive name).. But you
> are right, with boost::bind you can _easily_ create functors that call
> preexisting functions (or member functions). And this is done via the
> address of the function.. And yeah, I think you are right about your
> assumption. For sending commands to another address space you don't
> get around serialization in some form, since you cannot just point the
> other process to the address of a function and tell it to run that
> function.. The different processes don't have this intricate knowledge
> of each other..
>
> Now if C++ had some decent introspection calling a method in another
> process space might be more easily done (or rather: the serialization
> would become much simpler), but alas C++ lacks in that respect..

I guess though, that one could try a little dirty hack parsing the
symbol table of the target process to simplify lookup of functions to
call. Assume you want to be able to just send the rendering process a
command via the network, like

["/filter_set_frequency", 1, 0.2]

(assuming OSC style commands)

meaning: call the function filter_set_frequency with the arguments 1 and
0.2. where 1 is the number of the filter and 0.2 the frequency.. The
rendering process would have a non-RT thread in which it receives
network commands. The receiver process could parse the output of a dlsym
function call on itself to get a function pointer to the function
filter_set_frequency. Then it would use a boost::bind object to bind the
arguments to it and pass this functor as command to the RT thread of the
rendering process. No explicit hacking of command tables or what not,
would be needed.. Member function handling would be a bit more
difficult. I have to think about this a bit..

Flo
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Aug 7 04:15:02 2011