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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
