Update CHANGELOG
matrix: Remember velocity for each segment
Add Kawai ES110 device file
BankEditorDialog: Add Help button
The documentation looks good to me. I have also managed to test bank switching with the Matrix-1000 with bankselecttype="2" in the rgd file and it works great. Thanks again. In the coming weeks or so I will send you via the mailing list a whole bunch of .rgd files that I've been working on (on and off for the past few weeks) as soon as they are complete.
Sounds great. Thanks for testing. I just updated the documentation for the bank editor dialog. Please review: https://www.rosegardenmusic.com/wiki/doc:bankeditordialog-en Also, if you can send final versions of your generic .rgd files (TG77 and Matrix-1000) for inclusion in the next release of rg, I would appreciate it. Any others that aren't already shipped with rg would be appreciated as well.
BankEditorDialog: Add tooltip to bank select type
Many thanks, I built the latest git master and tested the TG77 rgd file and can confirm that bank switching now works fine with the TG77. I didn't have the time to test the Matrix-1000 yet, but should be able to do that within a day or so, I will report back again after doing that.
Support Alternative Bank Select Methods
Just pushed [50fc74]. Please test latest git. These changes provide the UI for bank select type in the lower right corner "Options" group box in the "Manage MIDI Banks and Programs" bank editor. Studio > Import Studio from File... now handles bank select type properly. I might look into some sort of indication as to what MSB and LSB mean in these new modes. But this is pretty much done. Let me know if anything isn't working as expected.
ModifyDeviceCommand: Cleanup
ModifyDeviceCommand: Cleanup
ModifyDeviceCommand: Cleanup
BankEditorDialog: Add bank select type
slotImportStudioFromFile(): Include bank select type
slotImportStudioFromFile(): Cleanup
Just pushed a fix [5120de]. Please test latest git. The problem was that importing the banks from the rgd file was not copying the bankselecttype from the .rgd to the .rg file. Try importing the banks again. Make sure you select "Overwrite banks" when importing. (It will not copy if it is in "Merge banks" mode and that is on purpose. It will make sense when the UI is finished.) Thanks for the quick testing.
rgd: Fix bankselecttype import
Here is the complete TG77 RGD file I used for testing:
Thanks a lot for implementing this so quickly, that's a pleasant surprise, I really didn't expect that! But I must be doing something wrong as Rosegarden is still sending Bankselect MSB+LSB (CC0+CC32) despite having specified bankselecttype="1". I used the link here on SF to download the latest git snapshot, built it according to the instructions in the README and then imported the rgd file I created for the TG77 with bankselecttype="1" and connected it to the MIDI out device to which the TG77 is...
Thanks a lot for working on this so quickly, I really didn't expect that! But I must be doing something wrong as Rosegarden is still sending Bankselect MSB+LSB (CC0+CC32) despite having specified bankselecttype="1". I used the link here on SF to download the latest git snapshot, built it according to the instructions in the README and then imported the rgd file I created for the TG77 with bankselecttype="1" and connected it to the MIDI out device to which the TG77 is connected. Then I assigned the...
Tested playback with aseqdump and standard midi file export. All look good. MIDI file seems to have duplicate program changes, but shouldn't hurt anything. UI is next.
Just pushed some support for this as [1e0bb1]. Please test latest git. There is no support in the bank editor UI yet. You can only get to it via the .rgd file. I've added a new bankselecttype attribute to the device tag: <device id="0" name="GM" direction="play" variation="" connection="" bankselecttype="0" type="midi"> Possible values for bankselecttype: Value Meaning "0" Normal bank selects are sent out. "1" PC100+ mode for TG77 "2" CC31 mode for matrix-1000 For PC100+ mode, bank LSBs 100-127 are...
doc: Add I/O support for BankSelectType
Renames
ChannelManager: Add alternative bank selects
Support Alternative Bank Select Methods
Error in AudioManagerDialog
Pushed as [8626e2] along with some renames and #include cleanup work [8fa0f9]. Please test latest git.
bug 1766 audio manager bug
AMD: Cleanup
See merge request for fix.
Error in AudioManagerDialog
Error in AudioManagerDialog
See merge request for fix.
bug 1766 audio manager bug
Error in AudioManagerDialog
That looks reasonable to me with one correction: the Matrix-1000 can use either the ModWheel (CC01) or CC31 to switch banks, but from a sequencer program it's best to use CC31, and not the ModWheel, as changing the ModWheel value could interfere with the sound being played, while CC31 isn't used for anything else. So I would suggest calling the third mode 'CC31' and also implement it using CC31 like in the amidi examples in my previous post.
Thanks for all of that. So BankSelMethod=3 really is specifically PC100+ treated as bank select. That makes it a lot easier to implement since it is so specific. Sounds like we need to offer two new bank select modes. One where PC100+ are treated as bank selects and a Matrix-1000 mode. How about we call them: Normal PC100+ (Yamaha SY77, etc...) Mod Wheel (Matrix-1000) Does this look reasonable?
Just for confirmation I tested the bank switch method of the Oberheim Matrix-1000 with amidi: The following MIDI string (all in hex) will switch to Bank 4 Patch 31 =1F(hex): amidi -p "hw:2,0,1" -S "B01F7F C004 B01F00 C01F" And the following will switch to Bank 7 Patch 64=40(hex): amidi -p "hw:2,0,1" -S "B01F7F C007 B01F00 C040" Basically switching banks is done using a program change preceded by CC31 with any value in the range 40-7F(hex) and followed again by CC31 with any value below 40(hex) (I...
Just for confirmation I tested the bank switch method of the Oberheim Matrix-1000 with amidi: The following MIDI string (all in hex) will switch to Bank 4 Patch 31 =1F(hex): amidi -p "hw:2,0,1" -S "B01F7F C004 B01F00 C01F" And the following will switch to Bank 7 Patch 64=40(hex): amidi -p "hw:2,0,1" -S "B01F7F C007 B01F00 C040" Basically switching banks is done using a program change preceded by CC31 with any value in the range 40-7F(hex) and followed again by CC31 with any value below 40(hex) (I...
The following article from the famous 'Sound on Sound' magazine (Sept. 1993) might be helpful too, it also describes this bank select method used by the SY77/TG77 (and other synths): https://www.muzines.co.uk/articles/bank-managing/10718 I also own a Matrix 1000 which also uses an uncommon bank select method that is also described in the article linked above. If the bank select method of the Matrix 1000 could be implemented in Rosegarden and in the rgd files too that would be absolutely great, not...
Hi, I'm the one who inquired about this on the mailing list. Cakewalk BankSelMethod=3 is described better here: https://legacy.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Instrument_Defs.07.html quote: Patch 100...127 Instruments that let you change banks by sending patch changes between 100 and 127 This is exactly what the TG77 (and its brother the SY77) uses, this method is used by quite a few synths from the 80s to early 90s. I tried this from a terminal, by sending the following...
Hi, I'm the one who inquired about this on the mailing list. Cakewalk BankSelMethod=3 is described better here: https://legacy.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Instrument_Defs.07.html quote: Patch 100...127 Instruments that let you change banks by sending patch changes between 100 and 127 This is exactly what the TG77 (and its brother the SY77) uses, this method is used by quite a few synths from the 80s to early 90s. I tried this from a terminal, by sending the following...
According to this site: https://tse3.sourceforge.net/doc/InsFiles.html The BankSelMethod values are as follows: Value Meaning 0 Normal - bank select MSB and LSB matter 1 Only the MSB is used and defined 2 Only the LSB is used and defined 3 Only program changes are used and defined We support 0, 1, and 2 directly by simply defining bank selects where they are needed. We support 3 as described above through use of the checkboxes on the MIPP. E.g. for the DX7 you absolutely have to turn off BSs or it...
According to this site: https://tse3.sourceforge.net/doc/InsFiles.html Value Meaning 0 Normal - bank select MSB and LSB matter 1 Only the MSB is used and defined 2 Only the LSB is used and defined 3 Only program changes are used and defined We support 0, 1, and 2 directly by simply defining bank selects where they are needed. We support 3 as described above through use of the checkboxes on the MIPP. E.g. for the DX7 you absolutely have to turn off BSs or it will crash. 3 as described above doesn't...
Support Alternative Bank Select Methods
Requested by Arne. See this message on the user list.
Support Alternative Bank Select Methods
MMW, AMW2: Reduce layout scope
Move to Studio::getMidiOutputDevices()
Device: Cleanup
MMW: Preserve selected tab across refresh
MMW: Refresh on controller changes
MMW: Fix garbage in meters
MMW: Handle changes to the number of devices
AudioPluginDialog: Improve Editor button behavior
bug 1764 drag tie preview
bug 1721 composition position
feature 541 gtk integration with dynamic library
I got it working. It was the other step you mentioned. Installing qt5-style-plugins fixed it. We need a Calf/gtk2 guide on the wiki.
Fix potential endless loop
For this particular bug, it is only step (7) where I've seen a problem so far. Everything else i.e. start/stop in RG or ardour as well as manual transport movement in RG works as expected. In other words, there is some disconnect in receiving a transport new position which does not involve play. Otherwise, design flaw or not, it seems to work perfectly as far as I can tell. Without more high level information about the current main classes, it might be difficult to comment on a new design, although...
Tested in [725417]: Audio now works for tie notes. This bug is now resolved.
The only reason I noticed the large movement erratic behavior is because I was doing full range testing due to the crash bug. Normally, I only need to zoom by small amounts and in that range the zoom is both finer and smooth already. So, there is no pressing need for change, except if you do draw people's attention to perpendicular movement, then it has to behave normally over the full range. That would probably be a new feature? In any case, for me you can close this bug bearing in mind I never...
I assume it's because the code is getting what it wants with horizontal movement. Good substantial changes in X. Not substantial changes in Y combined with unpredictable changes in X. I was thinking more deeply on this and I think we could provide a "fine tuning" feature inspired by your use case. For perpendicular motion make fine adjustments. For parallel motion make coarse adjustments. Things would, of course, be weird on the diagonals as it flips between the two. A fun project.
Theme parsing error: Not using units is deprecated
You're right. I should not even have opened this bug. The missing px was in a gtk.css which I created ages ago to change some font sizes. I didn't see the warning appear anywhere else, and just assumed it was something to do with RG. I guess they just turned on the deprecation warnings out of the blue. You can close this bug.
Tested in [725417], the sole Profile point headings are now no longer appearing in the logs. This bug can be closed.
Tested in [725417], the Audio Generator Peaks are now no longer appearing in the logs. This bug can be closed.
Then my only remaining question is why is it that I do not see the erratic behavior or accordion affect when moving horizontally? Surely I would be prone to the same slight offline movements? For horizontal movement, everything is smooth and in one direction.
Everything looks good. It's ignoring vertical motion and only zooming based on horizontal motion. If you move up, it will pick up the slightest movement to the left or right and turn that into a change in zoom. As an example, left click, move up, then move left and right. When the mouse is directly over the wheel you will see the same zoom behavior you see when moving horizontally on top of the wheel (without the vertical motion). This is working as designed.
I could not follow the "what I'm expected to see" information you provided, so I just dumped the whole logs so you have the details. I had a bit of a fight to get the match what you see for zoom...both directions fighting the zoom I chose, presumably because I chose it. Either side was fine...but then the stupid touchpad accidentally (on purpose) messed up my results by overshooting what I wanted whether I zoomed in or out :-) Anyway, I got my way. On screen, the three measure zoom was started just...
No audio for MatrixEditor drag across tie notes
Fix pushed as [725417]. Please test latest git.
Merge branch 'bug1764-ted'
fix preview play for tied notes
I copied the tie logic from previewSelection. But setExtraPreviewEvents requires different handling. See merge request.
Confirmed. Example attached. I only tied the first pair. Depending on where the drag is started, sometimes the notes sound. Sometimes not. It seems to be consistent in that it does not sound notes that are tied back, unless they are in the current segment. I'll have a look at Philip's fix.
I've pushed a little bit more logging to the twmouse branch if you want to do some more testing. https://sourceforge.net/p/rosegarden/git/ci/twmouse/tree/ Here's some example output: 276559 [Thumbwheel] mouseMoveEvent() 276559 [Thumbwheel] m_clickPos: QPoint(29,5) 276559 [Thumbwheel] event pos: QPoint(31,-288) 276559 [Thumbwheel] distance: 2 276559 [MatrixWidget] slotHorizontalThumbwheelMoved(): value = 2 276559 [MatrixWidget] setHorizontalZoomFactor(): factor = 1.21 First four lines are as before....
hzoom: More logging
Merge branch 'master' into twmouse
Well, at least the simpler rewrite works exactly the same as the past version right down to the current problem. Although I noticed all of this for the horizontal wheel, it's all the wheels which allow zoom when the mouse is moved perpendicular to them. And even then, the only problem is that the perpendicular movement is erratic, accordions occasionally and sometimes gets stuck unless you release and try again or do a Zoom Reset. And of course, you're not seeing any of this is odd too. Otherwise...
Thumbwheel: Simplify math
I wanted to do better than just dumping the final zooms. However, there's a lot of code in Thumbwheel that doesn't make sense and I couldn't figure out where to put any logging that would be helpful. So I decided to dig in and sure enough, there's some really confusing stuff going on here. Mouse move events are handled in a very weird way. And that might be the problem. I've pushed a newly rewritten and much simpler version of Thumbwheel to a new thumbwheel branch: https://sourceforge.net/p/rosegarden/git/ci/thumbwheel/tree/...
ThumbWheel: Cleanup
ThumbWheel: Cleanup
ThumbWheel: Cleanup
ThumbWheel: Cleanup
ThumbWheel: Cleanup
From a logging point of view, all you need (assuming it's easy) is to add the current zoom values (vertical and horizontal) as the mouse is moved. In your case, you should see no zoom change at all in the logs because you see no zoom change in the view. In my case...well...I certainly see a zoom change in the view, but have no idea what will show up in the logs, but it should be interesting.
Actually, ThumbWheel appears to be more complicated than it needs to be. This might be what the problem is. I'm going to review it and see if it needs a rewrite.
More than expected number of AudioPeaksGenerator entries in log
Debug logging turned off in [b4815b]. Please test latest git.
audio: Turn off audio peaks debug logging
Now the AudioPeaksGenerator entries ran from 1 thru 58 which appears to make sense 2 x 29. But audio segments are links, not copies, so the peaks must be linked too? I'm guessing this is done because if an audio file appears on two different audio tracks connected to two different audio channels, each might have a different appearance based on the channel gain. It might be possible to optimize this better, but then the code gets more complicated and bug-prone. why all the apparent processing of peaks...
That all looks perfect. So the input side is working as designed. No driver issues. I'll see about some more logging.
I don't think this is a problem. The logs from exit are just from the destructors - no processing. I believe the previews come ultimately from the AudioFile so there should be no unnecessary duplicate processing. These logs should probably be disabled with RG_NO_DEBUG_PRINT
I copied the tie logic from previewSelection. But setExtraPreviewEvents requires different handling. See merge request.
bug 1764 drag tie preview