> De: Mathias Lundgren <mathias_lundgren@...>
> A: lmuse-developer <lmuse-developer@...>
> Objet: Re: Re: [Lmuse-developer] bug GUI refresh deicsonze
> Date: 18 Jan 2005 20:22:43 +0100
> tis 2005-01-18 klockan 06.03 skrev alin weiller:
> > > Hi there!
> > >=20
> > > It looks as if you added an attachment to the mail (perhaps with
> the
> > > code in question?) but for some reason it doesn't show up in
> my
> > > evolution...
> > No file that I wanted to attach(maybe the mail itself)
> >=20
> >=20
> > >=20
> > > Anyway, just a question to make sure this isn't the cause of
> the
> > > problems (if you already know this, you can simply ignore me.
> :-):
> > >=20
> > > You're sending the gui messages from the synth when you get a
> hbank,
> > > lbank and prog (with f.ex. gui->writeEvent(ev)) - not calling
> methods
> > > on
> > > the gui directly from the synth, right? The synth and the gui
> are
> > > running in different threads (synth=3Drealtime, gui is non-realtime=
),
> and
> > > since you say muse freezes I'm getting a bit suspicious. :-)
> The synth
> > > cannot do things that might make it lock up (f.ex. calling things
> in the
> > > gui, allocating memory etc) while processing, since if muse isn't
> done
> > > in time, jack will shut it down (jack is sooo picky when it comes
> to
> > > those little things).=20
> > I think you point it,=20
> > I call _gui->setPreset(hbank, lbank, prog) in the setController(int
> ch, int ctrl, int val).
> > In this case maybe I need to define some communications; apply emmit=
,
> slot...
> >=20
> > A-LIN
>=20
> You're not talking about Qt:s sending signals and slots between the
> synth to the gui I hope (emit signal, connected to slots?)? If so, I
> have to disappoint you again. If you already know this, or this wasn't
> what you intended to do, please disregard the rest...
>=20
> Qt:s signal/slot implementation is actually performed by "normal calls"
> behind the scenes, so emitting a signal from the synth, connected to a
> slot in the gui is, in the sense of a realtime context, not allowed,
> since Qt gui thingies are not realtime safe. This means that your synth
> can be disconnected at any time during those calls. In another sense
> it's also not allowed since you're not (someone plz correct me here if
> I'm wrong here) allowed to emit signals from any other thread than the
> gui thread. Since the synth is running in a different thread than the
> gui it would (if I'm correct above) probably lead to all sorts of nasty
> things. I'm guessing there are actually issues like these that make you
> get the error you described: the call to setPreset you're doing from th=
e
> synth probably triggers Qt to send signals (from another thread than th=
e
> gui-thread), and the lock-up you're getting comes as an effect of these
> errors.
>=20
> I see that you, in your gui, are actually holding a reference to the
> deicsonze synth, and calling methods on it directly. This can be
> dangerous (in another sense than the realtime problems) since the gui
> and the synth are run in different threads, and changing the same data
> from two or more threads at the same time can lead to all kinds of
> horrible terrors, hopeless to debug. Perhaps you're sensitive with thes=
e
> manners and only change simple datastructures in the guithread, while
> reading them in the synth thread, haven't checked (that might be ok) bu=
t
> still, I'd suggest that you, before you've done things hard enough to
> change, to set up the gui<->synth-communication in a threadsafe way.
> This can ensure both "realtime-safeness" as well as "threadsafe-ness".
> I
> hope you don't think that I'm just whining at you, but if you do this
> correct once, you'll save looots of hair and tears later! :-)
>=20
> Now, you can do this in different ways, but the easiest way is to
> inherit the method processEvent in your gui (from MessGui), and forward
> the MidiPlayEvents you're interested in notifying your gui of, with
> _gui->writeEvent(ev). This will send them from the synththread to the
> guithread via a fifo, which will make them end up in processEvent
> automagically. To send things from the gui to the synth, use the
> sendEvent-methods in the gui, which will also send them to the synth in
> a threadsafe manner (they'll end up in playNote/processEvent/sysex
> methods et al) . Here, you can actually do two good things at once:
> Since they're sent as midi-events you can send them as controllers, and
> process them accordingly. By defining specific controllers for your
> synth, that you feed to MusE by implementing getControllerInfo(...) in
> your synth it makes it possible to use the controller pane in the
> editors for editing the parameters to your synth. Very nice way to
> integrate it with the sequencer, not to mention that you're making it
> possible to control all the parameters of your synth as midi-messages,
> which gives you the possibility to add controllers in your songs and
> change them during playback.
>=20
> Since your synth is probably the most advanced and flashiest of all
> Mess's around, it would mean a lot of controllers to implement
> (setVol1,2,3,4, LS1,LS2 etc etc), and yes, it's not the funniest thing
> to do. Werner's automation handling does some very good things for you
> here though, since it keeps track of controller values, and if
> everything works as it should, you shouldn't need to store/reinitialize
> any of the controller values for your synth, since they will be
> reinitialized when reopening a project file (correct me if I'm wrong
> here, Werner!).
>=20
> Hope you managed to read all the way down here, and that there was
> something worth of reading.
>=20
> /Mathias
Thank's a lot :-), as the matter of fact we are quite synchronous threads=
;-), just before reading you email I was looking from cover to cover you=
r simpledrum and gui.cpp and realizing what you're telling me. Thank's ag=
ain.
A-LIN
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....<A HREF=3D"http://www.thinkgeek.co=
m/sfshirt"
> TARGET=3D"_blank">http://www.thinkgeek.com/sfshirt</a>
> _______________________________________________
> Lmuse-developer mailing list
> Lmuse-developer@...
> https://lists.sourceforge.net/lists/listinfo/lmuse-developer
C est le moment de dynamiser votre bo=EEte mail en d=E9couvrant les offre=
s CaraMail Max et Pro - http://www.caramail.com
|