6 Aug
2011
6 Aug
'11
10:56 p.m.
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?
Jeff McClintock
From: Florian Paul Schmidt
<mista.tapas(a)gmx.net>
Subject: [LAD] RT-Safe UI/Engine Decoupling using Functional
Programming and Reference Counted SmartPointers
To: linux-audio-dev(a)lists.linuxaudio.org
Message-ID: <4E3CA5A4.7060208(a)gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
during the process of writing a new small jack sampler which fits my
workflow I came up with this little scheme to solve the UI/engine
decoupling problem. For the purpose of spreading the idea or
alternatively getting answers about how it's broken and sucks I decided
to write a little article describing it..
http://178.63.2.231/~tapas/wordpress/?page_id=45
The (largely unfinished and unusable) sampler project is here:
https://github.com/fps/jass
Let me have it..
Regards,
Flo
6 Aug
6 Aug
11:26 p.m.
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..
Regards,
Flo
Jeff McClintock
From: Florian Paul
Schmidt<mista.tapas(a)gmx.net>
Subject: [LAD] RT-Safe UI/Engine Decoupling using Functional
Programming and Reference Counted SmartPointers
To: linux-audio-dev(a)lists.linuxaudio.org
Message-ID:<4E3CA5A4.7060208@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
during the process of writing a new small jack sampler which fits my
workflow I came up with this little scheme to solve the UI/engine
decoupling problem. For the purpose of spreading the idea or
alternatively getting answers about how it's broken and sucks I decided
to write a little article describing it..
http://178.63.2.231/~tapas/wordpress/?page_id=45
The (largely unfinished and unusable) sampler project is here:
https://github.com/fps/jass
Let me have it..
Regards,
Flo
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
7 Aug
7 Aug
12:03 a.m.
On 08/06/2011 11:26 PM, Florian Paul Schmidt wrote:
On 08/06/2011 10:55 PM, Jeff McClintock wrote:
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
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..
12:06 a.m.
On 08/07/2011 12:03 AM, Florian Paul Schmidt wrote:
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..
Actually, type safety would go out of the window, as the signature of a
function is not really apparent from the symbol table. So some caution
would have to be used when sending commands, making sure that the types
of arguments are right. Before creating the boost::bind functor the raw
function pointer from dlsym would have to be cast to the right type..
Maybe boost::bind would be the wrong approach here alltogether.. Will
need to think about it a bit more..
Flo
12:10 a.m.
On 08/07/2011 12:06 AM, Florian Paul Schmidt wrote:
On 08/07/2011 12:03 AM, Florian Paul Schmidt wrote:
OMG, could this be the one single place where polish notation would have
a place? To clarify: Encode the signature of functions in the name of
the function and restrict yourself to several function signatures that
cover the kind of functions you want to expose. Then you could cast into
the appropriate type and again use boost::bind..
Ugly, am I on crack? Who knows? Going to party now. Laters,
Flo
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..
Actually, type safety would go out of the window, as the signature of
a function is not really apparent from the symbol table. So some
caution would have to be used when sending commands, making sure that
the types of arguments are right. Before creating the boost::bind
functor the raw function pointer from dlsym would have to be cast to
the right type.. Maybe boost::bind would be the wrong approach here
alltogether.. Will need to think about it a bit more.. 
10:05 p.m.
On Sat, Aug 6, 2011 at 6:10 PM, Florian Paul Schmidt
<mista.tapas(a)gmx.net> wrote:
On 08/07/2011 12:06 AM, Florian Paul Schmidt wrote:
In C++, isn't the signature of the function encoded in the symbol
table via name mangling?
This is not meant to imply that I think this is good idea...
Actually, type safety would go out of the window,
as the signature of a
function is not really apparent from the symbol table. So some caution would
have to be used when sending commands, making sure that the types of
arguments are right. Before creating the boost::bind functor the raw
function pointer from dlsym would have to be cast to the right type.. Maybe
boost::bind would be the wrong approach here alltogether.. Will need to
think about it a bit more..
OMG, could this be the one single place where polish notation would have a
place? To clarify: Encode the signature of functions in the name of the
function and restrict yourself to several function signatures that cover the
kind of functions you want to expose. Then you could cast into the
appropriate type and again use boost::bind..
Ugly, am I on crack? Who knows? Going to party now. Laters,
Flo
11:02 p.m.
On 08/07/2011 10:05 PM, Paul Coccoli wrote:
On Sat, Aug 6, 2011 at 6:10 PM, Florian Paul Schmidt
<mista.tapas(a)gmx.net> wrote:
True, except for the return type (as it's not used for function
dispatching in C++). I guess if one really wanted one could try to do
something crazy like that.. I don't know though, if the generity of the
approach really counterweights the potential hazards.. :D
Flo
On 08/07/2011 12:06 AM, Florian Paul Schmidt
wrote:
In C++, isn't the signature of the function encoded in the symbol
table via name mangling?
This is not meant to imply that I think this is good idea... Actually, type safety would go out of the window,
as the signature of a
function is not really apparent from the symbol table. So some caution would
have to be used when sending commands, making sure that the types of
arguments are right. Before creating the boost::bind functor the raw
function pointer from dlsym would have to be cast to the right type.. Maybe
boost::bind would be the wrong approach here alltogether.. Will need to
think about it a bit more..
OMG, could this be the one single place where polish
notation would have a
place? To clarify: Encode the signature of functions in the name of the
function and restrict yourself to several function signatures that cover the
kind of functions you want to expose. Then you could cast into the
appropriate type and again use boost::bind..
Ugly, am I on crack? Who knows? Going to party now. Laters,
Flo
4653
days inactive
4654
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Florian Paul Schmidt -
Jeff McClintock -
Paul Coccoli