[LAD] Program design: C++ -> SHM -> Python

[Arnold Krille]

On Sunday 26 December 2010 02:05:03 Harry Van Haaren wrote:
> Hi,
> 
> I've been trying to come up with a nice program architecture for a live
> performance tool (Audio looping etc),
> and I've kind of hit a wall:
> 
> Input will be taken via OSC, the "engine" will be written in C++, and the
> GUI is up in the air.
> 
> I've written most of the engine, (working to a degree needs some bugfixes),
> and now I've started implementing
> the GUI in the same binary. Ie: its all compiled together, double-click it
> and it shows on screen & loads JACK client.
> The GUI code has a nasty habit of segfaulting.. which is also killing the
> engine. That's a no-go for live performance.
> The engine is rock solid stable. So its the fact that there's the GUI
> thread running around that's segfault-ing things.
> 
> So I'm wondering if it feasible to keep the audio/other data in SHared
> Memory, and then write the GUI in Python reading
> from the same memory? Is this concidered "ugly" design? I have no
> experience with SHM, so I thought I'd ask.
> 
> The other option I was concidering is writing the front-end GUI part using
> only info obtained from OSC, but that would
> exclude the waveforms of the audio, and lots of other nice features...

You could do both: Connect the gui via OSC for general usage and define a 
shared memory for the big-data for local usage. If your engine is that rock-
stable, you might want to run it on a headless machine and control it via OSC. 
Which allows the gui to run on any win/linux/mac/ipad/ipod/galaxy 
tab/whatever. And once the shmem is working, you can try to port some of that 
to osc too.

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20101226/c169ae3c/attachment.pgp>