> On Saturday, January 21, 2012, Tom Breton (Tehom) wrote:
>
>> channel set to 2." implying that (as I suspected) SoftSynth are not
>> playing on distinct channels as MIDI are.
>
> Each one is basically a channel unto itself. I think you can safely just
> ignore plugin instruments for your purposes, and save some headaches.
Thanks for the information.
One question: What's the status of MidiFile? That's the one I still need
to fix. It seemed like it was already ignoring repeats, triggered
segments, etc.
> [...]
> First, I'm not sure what cool thing the provided example files are
> supposed to
> be showing me. It isn't that apparent, since I don't know what
> controllers or
> whatever to look for, to watch what changing. I'm too lazy to dig around
> in
> the event list to try to figure it out.
OK, I guess it wasn't as clear as I thought. The example is meant to show:
* The 4 piano segments are alternately playing in unison and playing
separately. The old way, they would (as a group) alternately play 1 note
and 4 notes; ie, the sonority would change for unisons. It's more
obvious with voices or wind instruments; maybe I should have used those
instead. Now when they play two or more notes in unison, they really
sound that many notes in unison.
Measure 2 contrasts this with an actual 1-vs-4 section. If you can
hear the difference when it switches back, it's working.
* The "Fixed instrument" segments demonstrate that fixed instruments are
in fact working the old way; when they change from thirds to unison, the
sonority should change (be cut in half), just like old times.
* For the trumpet segments, it's pretty much what you demonstrated with
your own example: one is crescendoing, simultaneously the other is
diminuendoing. May not seem striking, but if you'd heard them fighting
it out when I was developing this, the difference would be striking.
Also if you jump back in the trumpet bit, it will demo another
"invisible feature" - they get the right controllers for that point in
time. The old way, if you jumped back it would start with a big burp
as controllers first got their static values that were very different
from the progressing values they would have at that time.
* The metronome track demonstrates that the metronome works on its proper
instrument. It's on slightly obnoxious keys because before it worked, it
played on piano and I got tired of hearing minor seconds clashing so I
moved it to a C/G fifth.
> [...]
> ways to break it either. It's sort of an invisible feature that quietly
> does
> a whole lot of things to make something cool but subtle possible.
Thanks. That's what it's supposed to be.
> I do see a big can of worms when it comes to percussion though. Try
> loading
> "Stormy Riders" or "Bogus Surf Jam" and the drums are coming out with a
> piano.
> I eventually managed to get percussion working by checking the percussion
> checkbox. I kind of hate to force everyone to go fiddle with that
> checkbox in
> order to get old files to play. Instrument #10 should probably default to
> being fixed on channel 10, and that would probably take care of it.
> Probably.
That is a good idea. I force percussion to channel 10 (one-based), but I
missed doing it in the opposite direction.
> [...]
> I still think that was the right call. It would probably complicate your
> allocation logic a little bit, but I think you can probably deal with it.
> When this box is checked on instrument #4, find whatever instrument is
> using
> channel 4, switch it over to some other available channel, and switch
> instrument #4 to channel 4. Life just seems less complicated that way,
> and I
> can't now, as then, think of any reason why people should ever _have_ to
> have
> instrument #3 play on channel 12. It shouldn't constrain anybody's
> ability to
> achieve something.
Ah, the voice of experience. That is a very good idea. Wish I'd thought
of that! Would've saved me a fair bit of coding. But I learned more
about Qt, so the time wasn't wasted.
OK, so fixed instruments will take their track number as the channel.
I think it's worth the tradeoffs:
* Adding or deleting tracks above the fixed instruments changes the channel.
* Won't handle multiple MIDI devices neatly. For instance, fixing 2
track tracks on different devices becomes impossible.
But maybe we can improve on even that. I want to run this by your voice
of experience first: Suppose there were 3 options:
* auto
* fixed to track number
* custom - fix to a specified channel on a specified MIDI device no
matter where the track is.
In your opinion, is that clear enough to forestall user confusion and bug
reports?
And where "custom fixed" and "fixed to track number" compete for the same
channel, "custom" would win because it's more of a deliberate user choice.
And "fixed to track" will clone instruments to give each fixed track a
dedicated instrument, so there's no question of the same instrument being
fixed to two tracks or playing oddly on an "auto" track.
> All in all though, it seems pretty solid, Tom. Nothing really jumps out
> as
> being different, you can move segments full of pitch bends and so forth
> around
> randomly without causing any obvious strange things to happen, and it
> doesn't
> seem possible to get the whole thing out of whack by jumping around.
Thanks.
> I
> don't
> notice some crazy amount of processing overhead either.
Thanks. I actually am rewriting the controller context code for speed.
When I came to understand segment mappers, I realized that I could just
look for triggered events on the temporary segment. Wish I'd realized
earlier.
> I don't think I have a problem with the idea of merging this into mainline
> Rosegarden whenever you think it's had long enough to bake.
OK.
> --
> D. Michael McIntyre
Tom Breton (Tehom)
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
