Activity for Rosegarden
-
musewhirl posted a comment on ticket #1777
Field selection on opening now works. Inserting an event causes that new event to be selected when the popup is closed. The latest fix says for insert, but just in case, when editing an event, nothing is selected on closing the popup, so you don't know which one was edited. Perhaps you're already working on it. The next two would likely be different bugs, but it was uncovered during this bug. I'll mention them here and if they are separate bugs, let me know and I'll open them. Set Event Velocities...
-
The exception no longer turns up on master, so this bug can be closed.
-
Works just great. I'm one for noticing new log entries though: [PasteEventsCommand] pasting when not possible I'm not sure what that can mean since obviously it was possible :-) It worked! Anyway, and the log entry is harmless, although misleading.
-
Ted Felix posted a comment on ticket #1774
Just pushed a fix for the Home/End/PgUp/PgDn keys not following: [82561e], Please test latest git.
-
Rename
-
Fix Home/End/PgDn/PgUp not scrolling
-
Event List Editor "select new event after insert" fix pushed as [5131ab]. Please test latest git.
-
ELE: Select new event after insert
-
Event List Editor initial focus fix pushed as [c527a2]. Please test latest git.
-
ELE: Set initial focus to the table
-
Use the up and down arrow keys, and the selection does not move to the other events This is because keyboard focus is on the "Note" checkbox in the left column. Press Shift+Tab and the list will have focus, and the up/down arrow keys will work. Some things that probably should be addressed for keyboard users: Give the event list keyboard focus on launch. Fix the practically invisible keyboard focus indication for the checkboxes. Black on dark gray is not a good color scheme. Go with something brighter....
-
Pushed new Event List Editor Paste At... feature as [b3682e]. Please test latest git.
-
ELE: Add Edit > Paste At...
-
I should mention that even before the change, if the PPP was at the start of the composition and the start was not in view, then hitting Home did not change the view i.e. follow to Home. That's because the PPP was already there, even though I could not see it. In that case, I've always used an extra PageDown/PageUp combo to move to the start without having to reach for the mouse and scroll. I never bothered to mention it as a problem, but thought you should know since that is how it was originally....
-
Wouldn't the test work by sending and recording just midi in some way and avoiding audio? The test would be to record the output from the synth to a WAV file, then bring that WAV file into Audacity (or whatever) and measure the time for each note. That will show timing errors from choosing, say, a 250Hz clock. You should see up to 4ms of error in that case. Of course, you will need an "interesting" tempo like 121bpm for there to be any error. With 120bpm, there will likely be no error since the math...
-
MIDI audio recording delay from wave file start
-
It's the [254f98] fix that changed that. Need to fix this so that PPP movements with the keys cause a scroll. Seems like it should do that in all cases, even with scroll-to-follow off. But just with scroll-to-follow on should be ok.
-
In [91a1a7] PageUp/PageDown & Home/End no longer follow to scroll, when they used to. It feels like the problem would have been introduced very recently and this bug is probably when, although I didn't verify. Steps to reproduce: Ensure Follow to Scroll is enabled Ensure the composition start is off screen Place Playback Position Pointer in view Hit Home and the PPP disappears of screen (presumably Home), but the view does not follow Same for all the navigation keys: Home, End, PageUp and PageDown...
-
There's still a minor problem with the selection. Open the EventEditor on a segment with multiple notes, where the playhead is at the start of a note Use the up and down arrow keys, and the selection does not move to the other events In other words, the event is not properly selected Now mouse click the event The up and down arrow keys now move the selection i.e. properly selected Why use the word properly? Because E to edit opens the Edit Event window on that event, andI to insert opens a window...
-
I rarely use menu options, but even now when I look at these, it's still confusing...not the half vs halve part though. But the expected outcome. Under Rescale there is: Half Double Stretch or Squash... These involve two separate actions: resize the note move it somewhere else The movement is not noticed for a single note selection which does stay put. But the unexpected movement action shows up for a multiple selection. How the wording is going to clearly convey that is a mystery to me. On the other...
-
Just one more thought about experiments with timers and an observable effect. There is a debian package called rt-tests which is used for latency testing of real time kernels. It has a program called cyclictest with homepage: https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start I've dabbled with it before when checking into real time kernels, but never tried it with RG in our current hrtimer scenario, and it's a non-realtime kernel too. But since we can now easily...
-
But the PasteAt feature is excellent. I didn't mean to ask for a whole new feature for something so minor, but if it's simple to implement, it solves the problem completely. Should be very easy. (But then I've said that before and spent days on something that just got more and more complicated. 🤣) Do you want me to create a new feature request around this or should we just let it absorb into the event editor in this bug along with the selection changes? It's fine here. I've got it in my email, so...
-
In my case: $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm Actually, what you have is the same result I get on a computer with an intel i7-8750H based on the Coffee Lake architecture. The chipset actually does have an hpet, but the Linux developers arranged it so that the kernel did not reveal it...they deemed it untrustworthy. I should have mentioned the source (or one of them): https://www.phoronix.com/news/Linux-Disabling-HPET-CoffeeLake My other computers...
-
Funny enough, the method I used made the event editor behave as though it had a PPP. That's why I visited a segment first using the MatrixEditor AND selected the note BEFORE returning and opening the event editor. The PPP was then just before that note. A bit cumbersome, but it worked. But since the timeline itself is created in the event editor as events appear, points in between don't really exist...that's why I said I was amazed pastes worked at all...but it uses relative time from a known point...
-
Ahh...so it rectifies itself for the sessions used in the code change window. That's great. So, nothing to worry about, and I can pull master in to test this bug and the others I have outstanding. I'll leave the misplaced paste here since sessions used for testing this bug may be affected anyway. It was just that at the time of the post I was updating to test bug #1777 and that's when I saw the popup. I'll be testing this bug shortly.
-
Actually, in the audit log I am seeing this with "HR Timer": AlsaDriver::setCurrentTimer("HR timer") Current timer set to "HR timer" at 1000000000Hz And that matches the .001us in /proc/asound/timers.
-
Insufficient logging details for timer resolution too low
-
Was this for a computer with CONFIG_HZ=1000 and/or a real time kernel? 1000Hz and preempt. What was the available_clocksource under /proc? $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc acpi_pm $ cat /proc/asound/timers G0: system timer : 1000.000us (10000000 ticks) G3: HR timer : 0.001us (1000000000 ticks) Client sequencer queue 0 : stopped P0-0-0: PCM Playback 0-0-0 : 21333.333us (1 ticks) SLAVE P0-0-1: PCM Capture 0-0-1 : SLAVE P0-2-1: PCM Capture 0-2-1 : SLAVE P0-3-0:...
-
Note that I have not tested the latest fix yet, since I await feedback about the compatibility popup window in master. In the meantime... First off, I'm amazed that pasting events in the EventEditor works. It looks deceptively simple, but is not. But I can see one small problem, and it's related to selections. Scenario: Here are some made up events as seen in the EventEditor: 73920 noteA 73921 pitchbend 74040 pitchbend 74060 pitchbend 74080 pitchbend Now, say I want to copy the pitchbends (not the...
-
The event list editor doesn't have a playback position pointer like matrix and notation. With them, you can set the PPP anywhere you want and paste. How about a "Paste At..." feature? Ctrl+V (Paste) would put it down at the currently selected event like it does now. A new Ctrl+Shift+V (Paste At...) would pop up a time dialog primed with the currently selected event time and paste at the time the user selects. You can always remap using the shortcut editor if you find yourself needing the time dialog...
-
the "old elements being deprecated" dialog which popped up That's my fault and completely harmless. Just load/resave any files that trigger it and you are good. It's related to forward compatibility and the matrix <velocity> tag. This stores the last used velocity in the matrix for each segment. I had no idea that older versions of rg would abort loading a file if they found a velocity tag in an unexpected location. So I switched to using a velocity attribute instead. Still, the "old elements" dialog...
-
Note that I have not tested the latest fix yet, since I await feedback about the compatibility popup window in master. In the meantime... First off, I'm amazed that pasting events in the EventEditor works. It looks deceptively simple, but is not. But I can see one small problem, and it's related to selections. Scenario: Here are some made up events as seen in the EventEditor: 73920 noteA 73921 pitchbend 74040 pitchbend 74060 pitchbend 74080 pitchbend Now, say I want to copy the pitchbends (not the...
-
The previous post was supposed to be for Bug #1777 (not this one). That was the one I was going to test before I found the other changes on master. I have no idea how to fix a misplaced post though.
-
Since I'm not actually upgrading to an official Rosegarden release for this test, I have some questions about the "old elements being deprecated" dialog which popped up when I built [90742d]. It seems innocent enough but it does want me to overwrite my autobuild (default studio) that I've had a long time. I immediately aborted in order to get some clarification. I'm sure appropriate documentation will surface when this hits the official release...or let me know if that documentation is somewhere...
-
Just pushed [91a1a7] which renames the notation and matrix Adjust > Rescale menu items to "Half" and "Double" instead of "Halve Durations" and "Double Durations". Please test latest git. This seems less misleading to me. More emphasis on "Rescale". Actually "Half" should probably be "Halve" to stick with the verb theme. Halve/Double. Half/Two.
-
Editors: Remove "Durations" from rescale items
-
Tabbing to change focus in Main Window is not working?
-
More than expected number of AudioPeaksGenerator entries in log
-
Compile error
-
Merge remote-tracking branch 'dfaure/work/dfaure/gcc_warning'
-
David Faure committed [e6951b] on Code (git)
Fix spurious -Wstringop-overflow warning in ColourMap constructor
-
Merge branch 'bug1632'
-
Just pushed [9d3dca] which selects the text in the time field when the Edit Event dialog is launched. Please test latest git. I think this one is finished.
-
EditEvent: Select text in time field on launch
-
perhaps the Absolute time field should be selected on opening. This is EditEvent::m_timeSpinBox. Selecting the text within would be consistent with tabbing through the dialog. I'll have a look.
-
Merged Philip's change as [1a171a]. Please test latest git. I put back the setCurrentItem() call to make sure the keyboard works correctly if the user tabs into the table and wants to navigate that way.
-
Event editor selection highlighted, but item not selected
-
Merged Philip's change as [1a171a]. Please test latest git. Also put back the setCurrentItem() call to make sure the keyboard works correctly if the user tabs into the table and wants to navigate that way.
-
Merge branch 'bug1777'
-
ELE: Restore setCurrentItem() so keyboard works
-
Beaming together a triplet of 16th and an 8th loses the triplet
-
David and Philip's changes pushed as [545738]. Please test latest git.
-
Merge branch 'bug1773'
-
OK. See merge request.
-
bug 1774 scroll to follow playback
-
Update CHANGELOG
-
Disabling Scroll to Follow Playback (pause) behaves oddly
-
Philip's fix pushed as [bbc0a4]. Please test latest git.
-
Merge branch 'bug1774'
-
Yes agreed. See merge request.
-
Philip Leishman modified ticket #1777
Event editor selection highlighted, but item not selected
-
Yes - the initial selection is not done properly. See merge request.
-
bug 1777 event editor initial selection
-
OK. See merge request.
-
bug 1773 tuplet beam
-
[MusicXMLXMLHandler] "Note type \"sixteenth\" not supported, replaced by a quarter note."
-
Uncertain of whether logging is working correctly
-
Note that master is missing one commit from Philip: [de410d].
-
Note that master is missing one commit from Philip: [de410d]. [de410d]
-
Note that master is missing one commit from Philip: [de410d].
-
Note that master is missing one commit from Philip: [de410d].
-
Philip's latest fix merged as [706c47]. Please test latest git.
-
Merge branch 'bug1772'
-
Merge remote-tracking branch 'dfaure/wip/dfaure/memory-leak-early-return'
-
NotationView: fix memory leak in case of early return
-
Merge remote-tracking branch 'dfaure/work/dfaure/paste-crash-fix'
-
Fix use of uninitialized member in PasteEventsCommand constructor
-
I've pushed a new bug1773 branch which includes @dfaure_kde's change: https://sourceforge.net/p/rosegarden/git/ci/bug1773/tree/ @lman, please apply your changes to that branch and push a new branch for me to review/test/merge.
-
Fix beaming a selection that contains a tuplet losing the tuplet
-
Event editor selection highlighted, but item not selected
-
Merge remote-tracking branch 'dfaure/work/dfaure/avoid-overflow'
-
Avoid overflow when subtracting INT_MAX-INT_MIN in AllocateChannels
-
Yes - my code is very similar !
-
You're right...it's not the note, but the string sixteenth which has never been valid MusicXML, so the general "not supported" makes sense. However, I didn't interpret the sixteenth in the logs as a string found in the file, even though it had quotes around it in the log. And there in the file right next to it the string eighth which was fine. I just interpreted the whole thing as the general human meaning i.e. a note of duration 1/16, sixteenth or semiquaver. It kind of looked like RG didn't support...well...sixteenths...
-
As far as I can tell "sixteenth" is not a valid note type in MusicXML - it should be "16th" The warning from the Rosegarden import seems quite adequate - the invalid string is given and this can be searched for in the xml file. I guess somehow in the import process the note is then transformed into a semiquaver - maybe over the duration. So: I think giving the invalid string is good enough to find the problem. This is a WARNING. The "not supported" means Rosegarden thinks this is invalid MusicXML...
-
OK, yours looks better (with the bracket above the 3). I'll remove mine. If you're curious you can read it at http://www.davidfaure.fr/2026/0001-Fix-tuplet-bracket-lost-when-beaming-across-a-tuplet.patch
-
OK, yours looks better (with the bracket above the 3). I'll remove mine. If you're curious you can read it at http://www.davidfaure.fr/2026/0001-Fix-beaming-a-selection-that-contains-a-tuplet-losin.patch
-
Oh... meanwhile I pushed a fix for that too, in https://github.com/tedfelix/rosegarden-official/pull/42
-
And after
-
Here before beaming,
-
With my change the quaver + semiquaver triplet seems to work too !
-
I believe I have a fix for the positioning of the tuplet text. I have also added the tuple line in this case - as lilypond does. When David's change is in master I will add this fix.
-
examples: Make all channels fixed
-
scripts: Add rg-fixed-channels and rgd modifiers
-
README: Update ASAN cmake line
-
[MusicXMLXMLHandler] "Note type \"sixteenth\" not supported, replaced by a quarter note."
-
When I opened the bug, I wasn't thinking that log levels was a development activity, but a developer way to help users provide more information when something goes wrong. Hence the idea of command-line --log-level (as per lilypond) and --verbose (as per jackd). And I've seen many such command-line options in applications over time, especially on linux. However, I don't see it in ardour either, so maybe the lack of it is just a DAW thing? In any case, if the user has already built RG, then they can...
-
My first impression is that this will do no harm - the change is very specific to this particular case. I think the problem of the tuplet text positioning can be fixed. There are still some issues - I discovered that the case where a quaver is followed by a semiquaver triplet still does not work ! Maybe David can look into that one too. The change is unconventional - a group which contains different beam types - but this is probably the only way to achieve what is wanted. It's possible other tuplet...
-
Merge branch 'PR44'
-
Warn about too-short durations that will lead to lilypond errors
