The "non-virtuouso case" is fine. That would just fix what was already there, and should work. The "virtuooso case" is something that hasn't yet worked in Rosegarden - possibly from the very beginning, and certainly hasn't worked since Ubuntu 8.04.
Being able to hear what is being recorded would be very desirable for what I'm doing. The work-around involves turning-off MIDI-thru, and piping the audio (from the source) manually, using qjackctl, to the synthesizer being used. This procedure is needlessly complex. You should be able to just hear what you're recording in Rosegarden.
An alternative would be to use MusE, but all of my course-ware (and experience) is with Rosegarden, and I would have to re-do (and re-gain) the expertise being imparted, if I had to use MusE.
In my view, there is only one crash (which can also manifest itself as a hang), which you worked on, and have a fix for.
I did run into another crash just recently, but I tested it on the new (development) version of Rosegarden, and found that version did not crash, so I am not particularly concerned about that crash.
That other crash does happen with the version of Rosegarden you get with Ubuntu 12.04, so if you want me to document that crash for information sake, I will be happy to do so.
On Tue, 2012-09-11 at 22:32 -0400, Ted Felix wrote:
On 09/11/2012 09:34 PM, Aere Greenway wrote:
> The case where input events get missed when recording is (of the
> problems not yet fixed) the highest priority, which I think the
> Beethoven piece is a part of.
Ok, there were two test cases where notes were dropped. One was very
serious in that rg would drop notes even with simple (non-virtuoso)
input. I fixed this and the fix is in rg 12.04.
The other test case is the Beethoven case. Essentially, given
virtuoso level input, rg fails miserably at MIDI recording.
I'm wondering if you can get away with the non-virtuoso level of
quality that we have now for your project. If so, you might want to
move the Beethoven dropped notes problem to lower priority. Your
choice. Try your easier test cases with the latest and you should find
that it works fine. Once you've checked it out, let me know if you want
to shuffle the priorities.
> The next highest priority (from my point of view) is the ability to hear
> the multiple instruments being recorded by way of the recording filter
> as they are being recorded, is the next highest priority, since my MIDI
> device sends on at least two MIDI channels, each of which are almost
> always a different instrument sound. There are ways of working around
> this, but they are needlessly complicated.
Right. I was hoping Tom could address this one since he's more
familiar with that area. He already addressed the issue of sending a
program change when switching track selection. It would be nice if it
would also send program changes on the armed tracks/channels when record
is started like it used to. It requires two MIDI sources to test. But
that's not a problem given vmpk. I think you can just run two
instances. Or one vmpk and one real MIDI keyboard. Tom, if you're
reading this, can you take a further look at this, or point me to the
right classes and I'll see what I can do?
> Certainly the crash (already fixed?) is probably the highest priority.
I'm hoping that was your crash from before. However, I'm not sure
whether you were recording something really long, then deleting a
segment. That's the key to the crash that I fixed. If you have another
crash procedure, I can have a look at it too.
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Rosegarden-devel mailing list
Rosegardenfirstname.lastname@example.org - use the link below to unsubscribe