I really want to thank the testers who are sticking with us and the level of mutual help is great.
It's really a fine program but I know some things have slipped, even some regressions,
and some things were never done or finished.
So I took a few weeks to take care of some things. (It always happens that way, once I start a few bug fixes I can't stop.)
I've got a branch 'selection_fixes' which I'll merge in maybe several days.
I'll announce properly when merged so that testers and translators can take a look.
I'm excited to bring you dozens of fixes and some new features.
Highlights: (Stuff too long to put in the ChangeLog.)
- Oops! Where are those note and controller graphics that are supposed to be drawn inside the Arranger parts?
And a whole lot of other 'single vertical line' missing segments - look closely, edges are missing, lassos partially drawn...
All of it was simply missing the infamous 'cosmetic pen' setting which appeared in Qt4. We fixed a lot of that
when we moved from Qt3, but not enough, and a couple of things regressed. Looks great now.
Redesign of all selection/cut/copy/paste/delete mechanisms, and global vs. local 'functions' dialogs and code.
Result: Yay! Finally - Cut/Copy/Paste/Delete on all midi controllers graphs.
Designed to be more WYSIWYG than before, the whole copy/cut/delete/functions side operates ONLY on what you see,
now including midi controller graphs.
(Unless you tell it to operate more globally. All function dialogs now have a 'Parts' button group to refine scope.)
To me that was paramount. I didn't want things being 'Copy'd that maybe were selected in another window
and unbeknownst to the user would be pasted somewhere in this window out of view.
Finally! Midi controller graphs no longer wait for sync with audio cycle upon each item drawn by the user.
With larger audio (Jack) buffer sizes this caused painful sluggish waits for free-drawn graphs with many points,
regardless of computer speed, as it waited for every point drawn to sync with audio.
Speaking of graphics, some may think graphics are trivial, but it turns out that with an Arranger containing a few
Wave tracks and a few Midi tracks, the user simply drawing a lasso causes near-100% CPU usage !
Ugh. A freakin' lasso.
First, we were using rectangles for graphic updates, and worse, currently we update the entire Arranger window
simply from each re-drawing of the lasso ! Way too much.
Second, even if we did only update the actual lasso area instead of the whole Arranger, it's a moot point
because if the lasso is big enough, it still gets slow anyway.
So... I've walked the entire drawing chain - from View::paintEvent() all the way to canvas item drawing -
and added... you guessed it, QRegions. Now each drawing routine has access to not only the update rectangle as usual
but now also the complex regions which Qt passes to us to make drawing much more refined and optimized.
In addition, our humble little lasso object is no longer just a rectangle! It is now a complex region
made up of four 1-pixel wide sides !
Result: Lasso drawing is now virtually infinitely faster. I won't quote CPU figures because I'm still optimizing
the part canvas drawing (especially Wave part drawing) to take advantage of the regions.
Oh, and one more highlight before I go:
Added missing mixer strips to Drum editor and Wave editor.
Yay! Now all the editors have the mixer strip on the left.
I fixed more stuff in the editors ... Notice how there's an errant vertical splitter bar always near the bottom of the Pianoroll canvas.
For the record, there are also two other very important branches I am working on.
1) The latency_fixes branch. This full-featured latency correction/compensation branch is coming along nicely.
MusE currently does no latency correction. Ouch. I just read a paper a couple of days ago about how Ardour
recently accomplished its latency correction. Yeah, I can dig that, it's really hard. Mine is say, two thirds done.
2) The audio_convert branch. This branch supports audio time-stretching, pitch-shifting, and resampling, on the fly.
You have run-time choices of which stretching libraries to use for which purpose (resample, time-shift or pitch-shift).
Support for new or future libraries is eased with a plugin API.
(I was thinking commercial libraries, new free methods as they come along etc.)
It also transparently opens and plays wave files of any sample rate regardless of current audio sample rate.
It actually works at the moment for what it does, you can stretch or resample Wave tracks and so on.
If you'd like to see these things materialize, I accept donations on our website.