tis 2005-01-18 klockan 06.03 skrev alin weiller:
> > Hi there!
> >
> > 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)
>
>
> >
> > 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. :-):
> >
> > 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=realtime, 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).
> I think you point it,
> 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...
>
> A-LIN
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...
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 the
synth probably triggers Qt to send signals (from another thread than the
gui-thread), and the lock-up you're getting comes as an effect of these
errors.
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 these
manners and only change simple datastructures in the guithread, while
reading them in the synth thread, haven't checked (that might be ok) but
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! :-)
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.
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!).
Hope you managed to read all the way down here, and that there was
something worth of reading.
/Mathias
|