From: Ted F. <te...@te...> - 2012-04-15 11:51:07
|
A feature appears to be missing in the current build of rg. Try this: 1. Given a MIDI keyboard that talks on channel 1. 2. Set track 2 to be flute. 3. Select track 10. (Click on the label.) 4. Press keys on the keyboard. You will hear piano. With 11.11.42 you will hear the drums. 5. Select track 2. 6. Press keys on the keyboard. You will hear piano. With 11.11.42 you will hear the flute. 7. Select track 1. 8. Press keys on the keyboard. You will hear piano. With 11.11.42 you will also hear piano. I'm not sure what this magic was in 11.11.42, but it is pretty important when one is recording tracks. With the new version, when I try to record a quick drum track, I hear piano. When I try to record a bass track, I hear piano. And when I try to record flute, well, you get the picture. Is there some way to get the old behavior back? Ted. |
From: Ted F. <te...@te...> - 2012-04-16 23:03:22
|
On 4/15/2012 4:46 PM, Tom Breton (Tehom) wrote: > Somewhat dirty, in that it assumes all instruments are fixed. I didn't > see a good way to deal with playing on a track with "auto" or audio > instruments. I tried it out and it works fine for tracks in "fixed" mode. Maybe when an auto mode track is recording (armed and the transport is in record) you can allocate a channel for "monitoring"? A channel should be available since the track that is being recorded doesn't need to allocate a channel since it isn't playing. Or... How about just treating the recording track like a playing track. Allocate a channel for it and send the appropriate program change. Then send the notes being recorded from input channel 1 to this allocated channel? Just some random thoughts (I have no idea what I'm talking about). Maybe there's a better solution? As it is, it works for me. But it might cause confusion for other users. I wonder how other sequencers deal with this. Ted. |
From: D. M. M. <mic...@ro...> - 2012-04-17 00:36:45
|
On Monday, April 16, 2012, Ted Felix wrote: > As it is, it works for me. But it might cause confusion for other > users. I wonder how other sequencers deal with this. As far as I know, no other sequencer does anything like this. Normally you just set a track to play through what MIDI output port and what channel you want, in kind of a bare metal way. Rosegarden has all these extra layers of abstraction that were supposed to make everything simple, but I've always found the opposite to be the case. Anyway, it has become pretty clear that I'm a damn fool if I just bundle this one up and shove it out the door. I've scrapped my release plans for the moment, and I'm going to find some way to carve out enough time to sit down and actually try to do stuff with Rosegarden, and give it more than token testing this time around. I'll report back with my findings. With luck, that might be within the next 12 hours, and if not, it's more likely within the next seven days. Work is really picking up, and I'm very busy right now. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-17 04:00:55
|
> On 4/15/2012 4:46 PM, Tom Breton (Tehom) wrote: >> Somewhat dirty, in that it assumes all instruments are fixed. I didn't >> see a good way to deal with playing on a track with "auto" or audio >> instruments. Since I wrote this, I made it cleaner: it no longer assumes, it checks and if it's non-midi or non-fixed, punts. > I tried it out and it works fine for tracks in "fixed" mode. > > Maybe when an auto mode track is recording (armed and the transport > is in record) you can allocate a channel for "monitoring"? A channel > should be available since the track that is being recorded doesn't need > to allocate a channel since it isn't playing. It is possible to record on a track that already has segments on it. > Or... How about just > treating the recording track like a playing track. Allocate a channel > for it and send the appropriate program change. Then send the notes > being recorded from input channel 1 to this allocated channel? That's a thought. It seems possible but potentially complex. I lean towards another approach: don't arm recording for auto instruments, and pop up an explanatory message. No functionality is lost, since that wasn't even possible before. Or make the instrument fixed if no segment plans to play on it. Tom Breton (Tehom) |
From: D. M. M. <mic...@ro...> - 2012-04-17 05:59:47
|
On Tuesday, April 17, 2012, Tom Breton (Tehom) wrote: > It is possible to record on a track that already has segments on it. Yes it is. > That's a thought. It seems possible but potentially complex. I lean > towards another approach: don't arm recording for auto instruments, and > pop up an explanatory message. No functionality is lost, since that > wasn't even possible before. Or make the instrument fixed if no segment > plans to play on it. If I understand you correctly, you're suggesting that the typical use experience should be: 1. Start new document with default factory autoload. All instruments default to auto. 2. Arm track 3 for recording. 3. Hit record. 4. Receive confusing error message. "I'm sorry, what you're trying to do used to be simple, but now it's complicated. Here are the hoops you must jump through in order to achieve something basic and fundamental." If my understanding is correct, then basically you're telling me all this fancy new channel-diddling gee-gah has broken Rosegarden in a spectacular and embarrassing way. There's no way that's going out the door as a release. Having an instrument switch to fixed before recording commences is also a bad solution. What's the point of auto at all if you have to switch to fixed to record? Most people will never switch it back to auto, so everything might as well just default to fixed in that scenario. The only solution I can see is to allocate a channel when a track is armed for recording. Have the act of toggling the LED trigger this, so it's in place and ready to go when the user hits record. Bear in mind I haven't actually tested any of this yet, and my understanding could be off base. I'm just trying to figure this out based on reading the comments in both directions. I'm really going to try to sit down with Rosegarden later tonight and see where I think things are. Really. No promises, but I'm trying to steal that much time. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2012-04-17 08:35:01
|
I finally found a moment to sit down with Rosegarden. Here's an acid test Rosegarden has to pass to be eligible for release: 1. Start Rosegarden from factory stock configuration 2. Make any necessary changes in the MIDI device manager to hook up the right synth and keyboard ports 3. Use the Instrument Parameters box (IPB) to set track 1 to be a harpsichord 4. Use the IPB to set track 2 to be a flute 5. Click on track 1 so the gray highlight bar shows on that track 6. Dink around on your keyboard. You should hear a harpsichord 7. Click on track 2 so the gray highlight bar shows on that track 8. Dink around on your keyboard. You should hear a flute Rosegarden 11.11.42 passes this test smoothly and easily. Rosegarden 12.04 fails miserably. No matter what you do, you always hear a piano everywhere. This is completely unacceptable, and Rosegarden cannot be released in this broken state. In my last message, I talked about setting up a channel or whatever when arming an instrument for recording, but my hands on testing has made it apparent that I expect to be able to hear whatever I have the program set to on whatever track whether its armed for recording or not. This implies even more triggers, like having the bank/program controls allocate channels, or else it implies something else entirely. Really, it implies something else, because if I set up default programs for this track and the other in my autoload, I expect to be able to start a new composition, highlight those tracks, and dink around without changing anything else. It seems one potential solution is to set all the tracks to "fixed" in the factory stock autoload.rg. That might work, but it seems to defeat the entire purpose of this whole floating channel allocation thing. If Rosegarden only works usefully with it turned off, then why have it? Tom said something about this state of affairs being acceptable, because Rosegarden never had the floating/fixed option before, and this is undiscovered country. That's true in a way, but in the scheme of things this floating channel thing may have been a huge and complicated little project, but in of itself the ability to move segments around and have the controllers play nice is very much a minor refinement compared with the basic meat and potatoes functionality that is presently broken. I hate to be so harsh, because I know this was incredibly complicated and difficult to achieve, but I'm looking out for Rosegarden more than I'm looking out for any developer's pet project. This pet needs much more taming before it's fit for public consumption. This is disastrous. I did an utterly miserable and useless job of testing this while it was in a branch, and never should have approved the merge. -- D. Michael McIntyre |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-17 16:05:38
|
> If I understand you correctly, you're suggesting that the typical use > experience should be: > > 1. Start new document with default factory autoload. All instruments > default > to auto. > > 2. Arm track 3 for recording. > > 3. Hit record. > > 4. Receive confusing error message. "I'm sorry, what you're trying to do > used > to be simple, but now it's complicated. Here are the hoops you must jump > through in order to achieve something basic and fundamental." You have a good point. > If my understanding is correct, then basically you're telling me all this > fancy new channel-diddling gee-gah has broken Rosegarden in a spectacular > and > embarrassing way. > > There's no way that's going out the door as a release. Agreed, certainly. > The only solution I can see is to allocate a channel when a track is armed > for > recording. Have the act of toggling the LED trigger this, so it's in > place > and ready to go when the user hits record. The thing is, having had time to reflect on my last comments, it isn't recording that's semi-broken but playthru. Recording was just part of the use case that showed the problem. You can (always could) still record on any track. This is about how MIDI plays thru. ISTM it needs to play thru correctly even when not recording. I think now that Ted had it right: have a dedicated channel for the selected track. I had hoped to avoid coding that, because it seems potentially complex and I feared introducing any more bugs, but you have persuaded me that something like this is needed. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-17 17:21:35
|
>> The only solution I can see is to allocate a channel when a track is >> armed >> for >> recording. Have the act of toggling the LED trigger this, so it's in >> place >> and ready to go when the user hits record. > > The thing is, having had time to reflect on my last comments, it isn't > recording that's semi-broken but playthru. Recording was just part of the > use case that showed the problem. You can (always could) still record on > any track. This is about how MIDI plays thru. > > ISTM it needs to play thru correctly even when not recording. I think now > that Ted had it right: have a dedicated channel for the selected track. I > had hoped to avoid coding that, because it seems potentially complex and I > feared introducing any more bugs, but you have persuaded me that something > like this is needed. Having looked over the affected code more carefully, it seems like it will have to be both. That is, even when recording, routeEvents can use either selected track or armed track, depending on getInstrumentForEvent. On the plus side, this looks doable and maybe not as complex as I feared. Tom Breton (Tehom) |
From: Aere G. <Aere@Dvorak-Keyboards.com> - 2012-04-17 18:02:54
|
Tom: Will this work when recording to multiple armed tracks simultaneously (which I occasionally do)? - Aere On Tue, 2012-04-17 at 13:21 -0400, Tom Breton (Tehom) wrote: > >> The only solution I can see is to allocate a channel when a track is > >> armed > >> for > >> recording. Have the act of toggling the LED trigger this, so it's in > >> place > >> and ready to go when the user hits record. > > > > The thing is, having had time to reflect on my last comments, it isn't > > recording that's semi-broken but playthru. Recording was just part of the > > use case that showed the problem. You can (always could) still record on > > any track. This is about how MIDI plays thru. > > > > ISTM it needs to play thru correctly even when not recording. I think now > > that Ted had it right: have a dedicated channel for the selected track. I > > had hoped to avoid coding that, because it seems potentially complex and I > > feared introducing any more bugs, but you have persuaded me that something > > like this is needed. > > Having looked over the affected code more carefully, it seems like it will > have to be both. That is, even when recording, routeEvents can use either > selected track or armed track, depending on getInstrumentForEvent. > > On the plus side, this looks doable and maybe not as complex as I feared. > > Tom Breton (Tehom) > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Sincerely, Aere |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-17 19:12:32
|
> Tom: > > Will this work when recording to multiple armed tracks simultaneously > (which I occasionally do)? > > - Aere That's the plan. What I've sketched would have a channel per armed track and a channel per MIDI device. More complex than I wanted but it seems doable. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-18 03:08:22
|
OK, I have some semblance of a treatment for auto thru channels. Right now it's still slightly buggy and not at all optimized, but it 90% works. It handles both recording and non-recording playthru. Changing instruments confuses it temporarily. I'll fix that and test it further. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-15 17:04:38
|
> I'm not sure what this magic was in 11.11.42, but it is pretty > important when one is recording tracks. With the new version, when I > try to record a quick drum track, I hear piano. When I try to record a > bass track, I hear piano. And when I try to record flute, well, you get > the picture. I think that is my fault. I will look into it and fix it. Tom Breton (Tehom) |
From: Tom B. (Tehom) <te...@pa...> - 2012-04-15 20:46:18
|
>> I'm not sure what this magic was in 11.11.42, but it is pretty >> important when one is recording tracks. With the new version, when I >> try to record a quick drum track, I hear piano. When I try to record a >> bass track, I hear piano. And when I try to record flute, well, you get >> the picture. > > I think that is my fault. I will look into it and fix it. > > Tom Breton (Tehom) I believe I have it. There were two things: * When an instrument was changed to fixed channels or its program was changed, I had delayed initializing the channel until we played it normally. Now for fixed instruments we initialize the channel immediately. * In RosegardenSequencer::routeEvents, the channel was never set, though the instrument was. Fixed. Somewhat dirty, in that it assumes all instruments are fixed. I didn't see a good way to deal with playing on a track with "auto" or audio instruments. I will finish testing it and push it this evening. Tom Breton (Tehom) |
From: Aere G. <Aere@Dvorak-Keyboards.com> - 2012-04-17 03:15:29
|
All: I do not have the latest development version of Rosegarden - only the version that came with Ubuntu 11.10. I have noticed it is easy to be confused about this sort of thing. I tend to use Qjackctl to make connections, and I have seen at least one instance where it was one of my manually-made connections going through, rather than the ones Rosegarden sets up, that was confusing me. With the version of Rosegarden I now have, I turned-off the MIDI-thru routing (controlled by the 'selected' track), and just used the track-select on my keyboard to control which track I send on. Though the Rosegarden documentation I last read says the MIDI recording filters work only while recording, I have wished they would be effective at other times. The way I use Rosegarden, I often play two keyboards at the same time, and wish (while monitoring or practicing) they could go to different MIDI channels (as they will during recording, controlled by the recording filters). It seems that the version of Rosegarden in Ubuntu 11.04 ("Betty Prior") responded reliably according to what track was selected, and I never considered turning-off the MIDI-thru routing. The behavior where I could control which track sounded by changing the transmit-channel on my keyboard seemed to happen with the Ubuntu 11.10 version (Don Juan). But again (as I said), it is easy to be confused on this, because of the Qjackctl 'patchbay' configuration I use. I hope I am not confusing the issue, or wasting your time, but am hoping this additional viewpoint may shed further light on the situation. - Aere On Mon, 2012-04-16 at 19:03 -0400, Ted Felix wrote: > On 4/15/2012 4:46 PM, Tom Breton (Tehom) wrote: > > Somewhat dirty, in that it assumes all instruments are fixed. I didn't > > see a good way to deal with playing on a track with "auto" or audio > > instruments. > > I tried it out and it works fine for tracks in "fixed" mode. > > Maybe when an auto mode track is recording (armed and the transport > is in record) you can allocate a channel for "monitoring"? A channel > should be available since the track that is being recorded doesn't need > to allocate a channel since it isn't playing. Or... How about just > treating the recording track like a playing track. Allocate a channel > for it and send the appropriate program change. Then send the notes > being recorded from input channel 1 to this allocated channel? Just > some random thoughts (I have no idea what I'm talking about). Maybe > there's a better solution? > > As it is, it works for me. But it might cause confusion for other > users. I wonder how other sequencers deal with this. > > Ted. > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel -- Sincerely, Aere |
From: Aere G. <Aere@Dvorak-Keyboards.com> - 2012-04-17 15:43:32
|
All: My first statement in the prior e-mail was right - it's easy to be confused by this stuff. In thinking about my e-mail below last night, I decided that the behavior I attributed to Rosgarden is not caused by Rosegarden. It is caused instead, by my use of a qjackctl patchbay (which is instantiated when qjackctl starts up). The connections it sets up allow me to play (in Rosegarden, or by itself) on two different tracks with the two keyboards, using qsynth. I turned off the MIDI-thru routing in Rosegarden because it was 'muddling up' what was happening - adding the currently-selected track into the mix (or even duplicating the signals to that track). I will say (in the category of wish-lists) that it would be good if the recording filters could be used when playing/practicing in Rosegarden, rather than just when recording. Then it would not be necessary to use qjackctl to allow playing simultaneously on two different tracks from two different MIDI keyboards (or from a split keyboard). Sorry for confusing the issue. - Aere On Mon, 2012-04-16 at 21:15 -0600, Aere Greenway wrote: > All: > > I do not have the latest development version of Rosegarden - only the > version that came with Ubuntu 11.10. > > I have noticed it is easy to be confused about this sort of thing. > > I tend to use Qjackctl to make connections, and I have seen at least > one instance where it was one of my manually-made connections going > through, rather than the ones Rosegarden sets up, that was confusing > me. > > With the version of Rosegarden I now have, I turned-off the MIDI-thru > routing (controlled by the 'selected' track), and just used the > track-select on my keyboard to control which track I send on. > > Though the Rosegarden documentation I last read says the MIDI > recording filters work only while recording, I have wished they would > be effective at other times. > > The way I use Rosegarden, I often play two keyboards at the same time, > and wish (while monitoring or practicing) they could go to different > MIDI channels (as they will during recording, controlled by the > recording filters). > > It seems that the version of Rosegarden in Ubuntu 11.04 ("Betty > Prior") responded reliably according to what track was selected, and I > never considered turning-off the MIDI-thru routing. > > The behavior where I could control which track sounded by changing the > transmit-channel on my keyboard seemed to happen with the Ubuntu 11.10 > version (Don Juan). > > But again (as I said), it is easy to be confused on this, because of > the Qjackctl 'patchbay' configuration I use. > > I hope I am not confusing the issue, or wasting your time, but am > hoping this additional viewpoint may shed further light on the > situation. > > - Aere > > > On Mon, 2012-04-16 at 19:03 -0400, Ted Felix wrote: > > > On 4/15/2012 4:46 PM, Tom Breton (Tehom) wrote: > > > Somewhat dirty, in that it assumes all instruments are fixed. I didn't > > > see a good way to deal with playing on a track with "auto" or audio > > > instruments. > > > > I tried it out and it works fine for tracks in "fixed" mode. > > > > Maybe when an auto mode track is recording (armed and the transport > > is in record) you can allocate a channel for "monitoring"? A channel > > should be available since the track that is being recorded doesn't need > > to allocate a channel since it isn't playing. Or... How about just > > treating the recording track like a playing track. Allocate a channel > > for it and send the appropriate program change. Then send the notes > > being recorded from input channel 1 to this allocated channel? Just > > some random thoughts (I have no idea what I'm talking about). Maybe > > there's a better solution? > > > > As it is, it works for me. But it might cause confusion for other > > users. I wonder how other sequencers deal with this. > > > > Ted. > > > > > > ------------------------------------------------------------------------------ > > For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > > Rosegarden-devel mailing list > > Ros...@li... - use the link below to unsubscribe > > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Rosegarden-devel mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > > > -- Sincerely, Aere |