Activity for Rosegarden
-
Philip Leishman posted a comment on ticket #1687
I can reproduce this. It seems the stored port is being ignored because it is in use (as an input device). Why are in use ports skipped ? Seems strange to me. Another consequence: create a second midi device and connect to the same port as the default device (surely not an unusual use case). Check the midi device dialog - both devices use the same port. Save this and load it again. One of the devices has lost the port connection !! Should we remove the portInUse check in AlsaDriver::setPlausibleConnection...
-
musewhirl posted a comment on ticket #1686
This probably supersedes my last post. I think I'm finally in a position to explain why I opened this bug, and what is causing the odd behavior I hinted at. I was reluctant to detail it because I could not figure out where to start. Main problem: Unwanted Program changes/controls being sent to my external keyboard causing it to be reconfigured in ways I didn't want. But not in every scenario, and that was the difficult part. Worse still, I could not find out what the messages were because of the...
-
Works perfectly now on the same old session that had this issue. I open that session with [d0760d] I get four submasters. Stopped that RG, and restarted with [b741a3] and I get eight submasters as per the fix.
-
RG will not start session with previously saved MIDI interface
-
I agree that the ease of use defaults should remain. Also we can disregard the --do-not-start-jack flag...in fact, removing JACK was to simplify this analysis i.e. have RG only connect up minimally on startup to see what's going on. JACK is not part of the problem. Also, the defaults only get in the way when something odd may be happening during startup, otherwise I wouldn't have mentioned them. This does sound odd given that the General MIDI device is no longer connected to the MIDI output going...
-
Ted Felix posted a comment on ticket #1686
Immediately MIDI messages are sent to the keyboard. Why for that one? Is that supposed to happen at that point? This does sound odd given that the General MIDI device is no longer connected to the MIDI output going to the keyboard. What kind of messages go out? How can you tell messages are going out? Now selecting the MIDI input port again, this time no messages are sent. Unless there is caching going on, why? There is buffering that ALSA does on MIDI input. If nothing is connected to an input and...
-
I also think you're saying that when JACK is installed there never has been a way to stop it being started on first launch. Is that correct? That is correct. The reason it does that is to help out new users who are not familiar with rosegarden and how to get sound in Linux. This is a huge issue and this is how we've decided to deal with it. If you want JACK started a certain way, start it before starting rg. If the JACK auto launch bothers you (drives me crazy), disable it via the preferences. Although...
-
So, JACK starting automatically is normal. So, I took that into account and got further, but a new seemingly inconsistent behavior appeared...it's actually closer to where I'm ultimately going, but I need to know if it too is normal. You will need an external MIDI device to match my case so you can tell if MIDI messages are sent to it. Or if not find some means of knowing whether RG has sent such messages and hope it doesn't change the results...for now what messages is probably unimportant, but...
-
Oh...so that explains it. To reproduce the bug, I wanted to use a fresh install in case using my configuration was causing the issue. Hence, no ~/.config/rosegardenmusic or ~/.local/share/rosegarden . As for first connecting my keyboard USB audio interface, RG on start up immediately contacts my keyboard which is what I don't really want in general...and not for this particular test...it's in fact possibly part of the problem I wanted to describe. I also think you're saying that when JACK is installed...
-
bug 1686 open device manager when bank editor closes
-
Minor window focus when creating MIDI Devices
-
Device manager focus fix merged as [b741a3]. Please test latest git. Switching this to feedback status. Let us know if there is something else that needs addressing.
-
Merge remote-tracking branch 'lman/bug-1686-device-dialog'
-
Number of submaster outs do not match number of JACK audio ports
-
Merged as [aa04de]. Please test latest git.
-
bug 1685 submaster jack ports
-
Merge remote-tracking branch 'lman/bug-1685-submasters'
-
OK - thanks for finding this bug. It turns out the problem is with the number of audio inputs. The bug (or its equivalent) can be seen quite easily in the latest version of rosegarden - just change the number of audio inputs - if there are more sugmasters than audio inputs the jack ports will breaks. I have a fix - please merge
-
Just pushed some cleanup related to this to master: [002a84]. Please test latest git. Only broken test case left is deleting all MIDI devices and then merging in a MusicXML file. This gives us the bogus device issue that was originally reported here. I suspect the best approach would be to fix this in the merge process. Make it fall back on the first softsynth in this case. The new Studio::getFirstMIDIInstrument() should be helpful for this. We should also look at all the other import and merge cases...
-
MusicXML: Cleanup
-
Use first MIDI instrument on MusicXML import
-
There seem to be multiple issues here. First some clarification: The Jack autostart flag is a configuration setting and has nothing to do with the autoload (default studio). On may system the configuration settings are stored in ~/.config/rosegardenmusic/Rosegarden.conf. The default studio is in ~/.local/share/rosegarden/autoload/autoload.rg The auto start setting for jack has (and always has had) true as the default. If you remove the Rosegarden.conf file and restart rosegarden the autostart will...
-
Before I could begin this scenario, I was tripped up by something I did mention in passing in another bug. The problem is caused by [d0760d] having the "Start JACK automatically" flag set to true by default. As far as I am aware, stable versions never had the "Start JACK automatically" box checked? So, RG does its normal search for any MIDI to attach its default Device to (that's an issue for another time) AND starts JACK if one is not started. For this scenario, I need RG to not contact my external...
-
I agree that none of the above need change, and I've seen the instrument parameter change behavior from the beginning. Change Devices is relatively new, to me at least, and while reproducing steps for Device deletion in a different bug, I saw (or should say heard) something unexpected from the external MIDI. Confirming that the two types of change are behaving correctly, helps when it comes to trying to reproduce that odd moment, which I could not investigate at the time. I will prepare those steps...
-
It is fairly straightforward to raise (or reopen) the device manager dialog on closing the bank editor - this makes sense - see merge request. On the second point: The selected program pan chorus etc. are instrument parameters. If two tracks use the same instrument these parameters MUST be identical. On the other hand if I select a new device for a track I am selecting a new instrument for that track. I think this should not affect other tracks ! So I think the behaviour when selecting a new device...
-
bug 1686 open device manager when bank editor closes
-
I should have added in my steps that when I changed to 4 submasters, I increased the number of inputs to 4. I probably would not have seen anything back then. But later I increased the submasters to 8 and that triggered the bug, although I only saw it by chance recently when looking at ports for different reasons. I'll have to be more thorough in my steps to reproduce. Well, I'm glad you can reproduce it now.
-
Number of submaster outs do not match number of JACK audio ports
-
OK - thanks for finding this bug. It turns out the problem is with the number of audio inputs. The bug (or its equivalent) can be seen quite easily in the latest version of rosegarden - just change the number of audio inputs - if there are more sugmasters than audio inputs the jack ports will breaks. I have a fix - please merge
-
bug 1685 submaster jack ports
-
Minor window focus when creating MIDI Devices
-
I too thought that perhaps there was something wrong with the rg file. Anyway, here is the attached rg along with the steps: I'm using sourceforge master: [d0760d] Start with a fresh install i.e. no autoload, no rosegardenmusic directories Start JACK audio Start RG Hit OK on the welcome splash screen Edit/Preferences/Audio I noticed that Start JACK automatically is checked. I never noticed that before. I thought the default was not to start JACK? Well it doesn't affect the test I unchecked that box...
-
The test MusicXML file.
-
Interesting. I'll detail the steps again as I go along in case I missed something, but I can reproduce it consistently. It does not feel like something that would occur only in my environment. I'm using sourceforge master: d0760d I start with a fresh install i.e. no autoload, no rosegardenmusic directories I hit OK on the welcome splash screen Select Edit/Preferences and check: "Use trackname for segments" Click Apply, then OK Select File/Merge/Merge MusicXML File(s)... Select the attached merge-musicxml-test.xml...
-
I cannot reproduce this. Using the latest master I get the expected behaviour - Tracks and segments use the part name. If there is no part name set in the MusicXML file the segment has no name and the track is labelled "untitled"
-
I cannot reproduce this. Note - with 8 submasters there are 16 jack ports - left and right for each submaster. I could compile 18.12 and I created a file with 8 submasters, When I load it in the latest version (master) of rosegarden I get all 16 jack ports. Can you upload a file which has this problem ?
-
I tested this in [d0760d], and it's fixed...a nice bug to see squashed :-)
-
In master [d0760d], I see an issue. I didn't provide any steps in this thread so: Steps to reproduce: 1. Ensure "Use track for new segments" is set in preferences 2. Open an existing MusicXML file: tracks are labeled based on part-name, but segments still have "MusicXML, id=1/" 3. Merge in the same MusicXML (or another): new tracks are labeled but segments have no label at all Since the new tracks created with the merge have track names based on part-name, I would expect those names to appear on...
-
I tested this in master [d0760d], and it works fine now.
-
Number of submaster outs do not match number of JACK audio ports
-
I didn't find any issues with Merge MusicXML. I merged starting with both less than and more than ten tracks. The results were the same. All tracks got the default MIDI Device and all tracks were defaulted to instrument #1.
-
As mentioned above, the deletion of MIDI playback devices is now resolved by the fix for this bug. Import MusicXML was mentioned "along the way", because it caused tracks with no MIdI Device to turn up which led to the same situation as deleting the device. I think that the additional default numbering fix of the instruments is tricky. First, we already have questions about instrument #10, which never turned up before, since all were defaulted to instrument #1. Here is another aspect of the problem...
-
We try very hard to keep master super-stable. But no guarantees. Some of our professional users do work in master. Thanks for taking some risk and providing feedback. It's a huge help. I should be back on this Tuesday.
-
By default, none of the Instrument Parameters' Bank entries are checked. I can see a disabled "General MIDI" in the corresponding drop down. I enabled the Bank dropdown menu on a track which revealed that "General MIDI" is the only entry in the dropdown anyway. I thought it odd that it was not selected, but moved on. Deletion bug resolved I created a new track 17 and changed it to the Custom Device. Next I attempted to delete a track using the General MIDI devices. The new dialog appears informing...
-
I've only been reporting against v23.12 because I have to (well...prefer to) use a stable version. In other words I cannot actually switch to git master for ongoing work. However, I have enough bugs in tracking to risk compiling the master into its own directory and checking them, including this one. Compiling there should be low risk to my environment, so long as I only open disposable copies of sessions. That's because there's generally no guarantee, in any application, that an older version will...
-
Chris Cannam committed [r16139] on Svn (old)
Make clear I mean last three listed above, not last three temporally!
-
Update from live wiki
-
Remove much outdated material
-
Formatting
-
Inconsistent default behavior for new tracks
-
I've pushed some more changes to master [d0760d]. Please test latest git... Ctrl+T will now fall back on the first SoftSynth when there are no MIDI devices. I think Ctrl+T is done. Please regression test. MusicXML import now uses available instruments (channels) on the first MIDI device or falls back on the first SoftSynth like Ctrl+T. It also is no longer confused by the devices in the previous document. @musewhirl: Do you have some interesting MusicXML files to test with? Give it a "whirl" (pardon...
-
MusicXML Import: Fix track instrument assignment
-
Pull out Studio::getAvailableMIDIInstrument()
-
Add Track: Use SoftSynth when no MIDI instruments
-
I have extended the connections dialog to allow routing of plugin audio outputs to different instruments. This allows for using plugins with multiple (more than 2) outputs. A simple test seems to work OK but there may be some additional bugs ! Please merge.
-
I've pushed some changes related to this to master [6171ab]. Please test latest git. You now cannot delete a Device if it is in use on a Track. Ctrl+T behaves better. It still can't handle no MIDI devices. That is next. I've only just started on this. Lots more to come. Especially in the area of import and merge.
-
Going with a different approach inspired by this.
-
bug 1670 inconsistency with delete midi device
-
Move getAvailableInstrument() to Device
-
RMW: Fix Track creation order
-
Use Composition::hasTrack()
-
addTrack: Use available instruments first
-
Renames
-
Cleanup
-
RMW: Fix new tracks using input for output
-
DMD: Do not delete a device being used by tracks
-
Audio time stretcher erases all audio data
-
Merged as [79d672]. Please test latest git.
-
Merged as [79d672].
-
bug 1680 AudioTimeStretcher in Release build
-
fix AudioTimeStretcher in release build
-
That #ifndef NDEBUG looks suspicious ! And indeed if I remove it everything works in release mode too Please merge
-
bug 1684 xml error in presets.xml
-
Merged as [cb1464].
-
Some categories of segment presets are no more obtainable.
-
Merged as [cb1464]. Please test latest git.
-
fix preset typos
-
crotale -> crotales
-
fix utf8 encoding for presets.xml
-
Yes - the xml parser was running into an error because of a wrong encoding. I have switched to using utf-8 - seems to work then. Please merge
-
Merged as [ab3a53].
-
bug 1679 pointer position on undo record
-
Undo command unexpectedly moves playback position
-
Merged as [ab3a53]. Please test latest git.
-
Cleanup
-
overwrite pointer position for undo of record commands
-
Undo command unexpectedly moves playback position
-
I have a fix for this. Please merge
-
Merged as [9bfedf].
-
bug 1673 MusicXML Segment labels
-
Import and Merge MusicXML does not use track names for segment labels
-
Pushed as [9bfedf]. Please test latest git.
-
Merge branch 'bug1673'
-
Cleanup
-
This was pulled in with the fr462 merge.
-
seperate midi channel and number of audio channels in Instrument
-
Yves Guillemot posted a comment on ticket #1680
Thank you, Philip. You got it. I confirm the stretcher works fine when the NDEBUG condition is removed.
-
That #ifndef NDEBUG looks suspicious ! And indeed if I remove it everything works in release mode too Please merge
-
bug 1680 AudioTimeStretcher in Release build
-
I noticed there were still some unrecognized clefs. Mostly typos. I have corrected these. There are two unrecognized clefs left: 1. "Pedal steel guitar" : tab 2. "Drum set": box Any suggestions what they should be ?