[LAD] Program design: C++ -> SHM -> Python
arnold at arnoldarts.de
Sun Dec 26 08:22:11 UTC 2010
On Sunday 26 December 2010 02:05:03 Harry Van Haaren wrote:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Linux-audio-dev