On Thursday 20 November 2003 22:38, Mathias Lundgren wrote:
> torsdagen den 20 november 2003 22.04 skrev du:
> > > I noticed that it's not possible to start/stop playing by pressing
> > > space/insert/enter. Found "// only allow the user to set the button
> > > "on" ". Does this have anything to do with Jack transport, or is it
> > > just to make it easier to read? It seems to work fine after a quick
> > > test, after changing the calls to use setStop and setPlay in kbAccel in
> > > app.cpp, and only true as parameter...
> > its Jack related. Now Jack holds the transport state (PLAY/STOP/SEEK).
> > To start play, MusE calls jackAudio->startTransport() and waits until
> > Jack switches to state PLAY. This state is send back to the GUI to
> > set the play/stop button.
> > This means the play/stop buttons always reflect the actual Jack tranport
> > state regardless which jack client changed it. As all Jack clients can
> > call start/stop transport there is no "Master".
> I thought it would be something like that... So I guess calling any of the
> 3 methods are OK, since setPlay and setStop + other things prevent the gui
> from being in a state not representing Jack's?
> BTW, noticed that export.cpp writeTrack is right now commented out. I guess
> that's because tracks are being handled differently now, not only because
> of drummap inconsistency? If it's only because of drummaps, I'll add the
its unfinished code. Export to SMF does not work. writeTrack() is from
stable omuse branch as a kind of reminder what has to be done.
> I'm wondering a little about what to do next... It feels like double-work
> to do a lot of things for omuse, implement those in unstable and vice
> versa. I've been thinking of a keyboard shortcut configuration dialog, but
> it depends a little on what's coming up next. Testing midi stuff (read:
> fluidsynth) is a bit difficult right now. Could you give a very short
> roadmap on what you're planning to do, and in what order?
this weekend i want to further test & debug muse. I want to see most
functions working to make it usable again.
The next big thing to code would be mixer automation. This is what i
need for doing work with wave files. I want to see a consistent interface
for both audio tracks and midi tracks. This has some problems.
There is a 1:1 relationship between audio tracks and audio mixer strips.
This is not true for midi tracks. There can be more than one midi track
for a midiport/midichannel but only one mixer strip for it. Im not sure
how to handle this.
> Storing softsynth init parameters was up once. I think I'd be happy if it
> would be possible to send a big "array" of sysexes when the project is
> saved. All in a bunch. Wham. Done. No need for switches and checks for
> which round we're currently at. I guess that would be an easy solution.
yes i thought about it and its probably the easiest solution, but it would
be better if MusE knows the initial controller settings to.