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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Linux Audio Developers <linux-audio-dev@...>
Date: Sunday, December 26, 2010 - 1:05 am

--00151748dfea3a8011049845cf2e
Content-Type: text/plain; charset=ISO-8859-1

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...

Help, advice, laughter etc welcomed :-) -Harry

--00151748dfea3a8011049845cf2e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 h=
it 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 bu=
gfixes), and now I've started implementingthe GUI in the same binar=
y. Ie: its all compiled together, double-click it and it shows on screen &a=
mp; loads JACK client.
The GUI code has a nasty habit of segfaulting.. which is also killing the e=
ngine. 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 tha=
t's segfault-ing things.
So I'm wondering if it feasible to keep the audio/other data in SHa=
red Memory, and then write the GUI in Python readingfrom the same memor=
y? Is this concidered "ugly" design? I have no experience with SH=
M, so I thought I'd ask.
The other option I was concidering is writing the front-end GUI part us=
ing only info obtained from OSC, but that wouldexclude the waveforms of=
the audio, and lots of other nice features...Help, advice, laughte=
r etc welcomed=A0 :-)=A0 -Harry

--00151748dfea3a8011049845cf2e--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Program design: C++ -> SHM -> Python, Harry Van Haaren, (Sun Dec 26, 1:05 am)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Paul Coccoli, (Mon Dec 27, 8:32 pm)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Arnold Krille, (Sun Dec 26, 8:22 am)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Harry Van Haaren, (Sun Dec 26, 10:57 am)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Harry Van Haaren, (Sun Dec 26, 12:37 pm)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Olivier Guilyardi, (Mon Dec 27, 11:51 am)
Re: [LAD] Program design: C++ -&gt; SHM -&gt; Python, Arnold Krille, (Sun Dec 26, 4:00 pm)