Activity for Philip Leishman
-
Philip Leishman committed [7c6d68] on Rosegarden - Code (git)
AudioManagerDialog save directory and yesToAll
-
OK I made those last two suggested changed. See my bug-1733-audio-selection branch.
-
fix comment
-
fix typo bug and add comment
-
They are indeed bugs - but relatively harmless. singleIdSelected has been replaced in the newest version by getSelectedIds I have added a comment for this. See newest version.
-
Do you have "Use native file dialogs" selected ? The standard file dialogs are used (no custom button names) so the system determines the button names. If you deselect "Use native file dialogs" the dialogs are consistent.
-
One last thing - I have improved the multi select export overwrite warning. It now has yes no and cancel. See my bug-1733-audio-selection branch.
-
AudioManagerDialog improve warning message
-
OK. I made some more changes. See branch bug-1733-audio-selection. Hopefully that is everything now. Feature freeze is approaching rapidly !!!
-
check for existing file in AudioManagerDialog
-
I renamed the unload action. Also fixed the Export Audio - Now for multi select. See my bug-1733-audio-selection branch.
-
AudioDialog extend multiselect
-
The selection behaviour you suggest seems reasonable. I have tried to implement it. I also updated preview and insert to work if several items are selected - but all selected items are for the same audio file. See my bug-1733-audio-selection branch.
-
AudioFileManager selection update
-
Just merged the newest master. See feature-254-midi-action branch.
-
Merge branch 'master' into feature-254-midi-action
-
Strange. AudioPluginOSCGUI is a long way from the lv2 plugins. Does geonkick have a DSSI version ? Check that the lv2 plugin is there with lv2ls
-
I disagree that this was not worthwhile. Having multi-select in the track editor but not in the audio manager was a real weakness. Implementing multi-select initially was the most work. The problems after that were just fine tuning (just a few lines of code). So now I deselect all top level items if there is a selection change in the track editor. See my bug-1733-audio-selection branch.
-
AudioManagerDialog deselect top level items on segment selection
-
The latest version is the latest on my bug-1733-audio-selection branch The hash should be ab6b89453
-
I have brought back the scrollToItem call. See branch bug-1733-audio-selection
-
AudioManagerDialog scroll to selected item
-
That seems reasonable. I have made a slight change so that parents of selected segments are expanded. See the latest version on my bug-1733-audio-selection branch
-
AudioManagerDialog auto expand items with selected segments
-
Odd behavior with segments drags and composition end
-
It seems Scenarios 1-3 were fairly trivial bugs. For Scenario 4 note the segment position is shown in the text accompanying the drag. I think auto expand is more for when recording. If you want to move a segment to bar x you are thinking about a composition which is at least this long. So just change the composition end first. See merge request.
-
bug 1744 segments beyond composition end
-
fix problems with segment beyond composition end
-
Not sure about the composition start and end as markers. But what should be possible is punch in/out as markers (or something similar). See https://en.wikipedia.org/wiki/Punch_in/out. If I record something and make a mistake somewhere it would be nice to set some markers at the start and end of the bad part, start punch in/out and play along but this time getting it right. I miss this feature in Rosegarden. I think the existing punch in out functionality is not very useful.
-
That's interesting about the 2 cursors. Yes maybe some of the current implementation is because of that. I know in the past the sequncer was a different process - but that is no longer the case so maybe we can simplify a little. The (RealTime) position pointer is passed from the sequencer to the gui using the SequenceDataBlock (that, I believe, used to be in shared memory) so I rather assumed that it would be protected with a mutex but - it seems not! There is even a comment in the code about it...
-
Jack does not support negative time (as I understand it). So This applies for a count-in which is before the start of the composition. If the start of the composition comes in the middle of the count-in the transport should start with the composition start.. Of course if the count-in starts after composition start the transport should start with the count-in.
-
Started on this. I soon ran into the question of the song (pointer) position. Of course RosegardenSequencer has one - but apparently only valid during playback. Then in "RosegardenMainWindow" there is slotUpdateUI which updates the gui from the sequencer song positon. So far so good - It seems to me the song position belongs in the sequencer and should always be valid even when not playing. Then there is RosegardenNwinWindow::slotSetPointerPosition which seems to be a mixture of gui update and actually...
-
I have had a go at this. See bug 1733
-
I have tried making the audio manager multi select. Also cleaned up and fixed bugs. See branch bug-1733-audio-selection
-
clean up unused functions in AudioManagerDialog
-
fix undo after remove in AudioManagerDialog
-
AudioManagerDialog multe select first version
-
Multi select in the audio manager should definitely be allowed. Looking into the code and testing I found some issues. There is that action "Distribute Audio on MIDI Segment" which appears to do .... absolutely nothing ! And I discovered a new bug (with git latest): 1. start Rosegarden and load a wav file in the audio manger. 2. drag from the audio manager to a n audio track. 3. Play and you hear the audio. 4. Stop playback 5. In the file manager select the top level audio item and press "Unload...
-
I have made a start at this. Testing the original version (git master latest) I ran into a problem: I have both qtractor and rosegarden each playing a midi track starting at bar 1. If I start playback (in either qtractor or rosegarden) the two tracks play synchronously. If I want to record a new track in rosegarden starting at bar1 the jack transport starts rolling immediately so qtractor starts playing although I am still in the "count in" in rosegarden ! So I end up with a 2 bar offset between...
-
I thought it might be useful for quickly finding linked segments. If the preference is for the item to be disabled that is no problem. Voting is open
-
I initially thought that a selected segment without any relatives should be deselected. But ... maybe not. I have changed this in the feature branch. Note that if nothing is selected "Select Related Segments" will show all segments that are related to any other segments. If you have a non linked segment it should not be selected.
-
maintain selection on select related segments
-
Add option: Select Related Linked Segments
-
I have had a go at this one. There is a new menu item "Select Related Segments" That means linked segments or audio segments with the same audio file. The Menu item is always active. If nothing is selected it will show all segments which are related to any other segment. Looking for similar segments and replacing them with links seems a bit more difficult. Also not sure that there is much user value. See merge request.
-
feature 534 related segments
-
add select related segments functionality
-
cppcheck updates
-
I had a look at ardour and qtractor. Always difficult looking at other people's code (Difficult enough looking at my own code). I believe they both have the same principle: 1. The gui triggers a jack_transport call 2. The jack transport changes cause the sequencer changes. I think this is the correct approach. I think the "add on" approach that Rosegarden uses at the moment is a fundamentally flawed design. So - a suggestion: Add a new class (TransportControl ?) with play, stop, jumpTo etc. commands...
-
cppcheck updates
-
Merge branch 'master' into bug-1632-cppcheck
-
cppcheck updates
-
Right click loop end can stretch outside composition length
-
I have a quick fix for this. See merge request
-
bug 1742 loop ruler limit
-
limit mouse position in LoopRuler
-
Yes it seems there is a mismatch between the lilypond version enumeration and the value used in the settings. I have a fix for this. See merge request. The notation warnings seems to be a different issue.
-
bug 1739 lilypond version mismatch
-
fix version problem in LilyPondExporter
-
cppcheck updates
-
cppcheck updates
-
clean up editor view document usage
-
OK
-
cppcheck updates
-
I think it makes sense to use the protected variable and replace all occurrences of RosegardenDocument::currentDocument() with m_document - also remove the document parameter from the editor constructors.
-
The cppcheck warning is in PitchTrackerView which has a member m_doc. This is the same name as the protected variable in EditViewBase. The matrix and notation editors use a variable m_document so cppcheck does not flag those. There is a comment in EditViewBase that it needs to store the document for detaching. Looking at NotationView it seems to use a mixture of the m_document variable and RosegardenDocument::currentDocument() - a bit of a mess !! Would we ever want an editor using something other...
-
I think the behaviour is correct. If you delete a track that does not delete the instrument. It is the instrument which uses the input not the track. I may have carefully configured an instrument with carefully setup plugins etc. Deleting all tracks using that instrument should not delete the instrument. If I add a track I can then select the pre-configured instrument for that track
-
cppcheck updates
-
Cppcheck has uncovered some problems with the editors. EditViewBase gets the RosegardenDocument from RosegardenDocument::currentDocument and stores it as a protected variable. However all the editors (Matrix, Notation...) get their own version of the document and ignore the protected variable. Two possibiliteis: 1. Remove the document parameter from the editors and always use the protected variable 2. Keep the document parameters and pass this to the EditViewBase constructor - and always use the...
-
cppcheck updates
-
Just tried the DSSI Hexter plugin. It seems to work well for me. Any error messages ?
-
cppcheck updates
-
cppcheck updates
-
Looks all good to me
-
I have made an attempt at this. Hopefully this will not cause any problems Note the application name "Rosegarden" was translated in the application. I have removed this (I checked the translation files and no one had translated this). A translation here would mean different languages would have different configurations!! See merge request.
-
bug 1737 setup lv2 environment
-
setup lv2 environment in main.cpp
-
As a test I added the following lines of code right at the start of main: QString st = QString(qgetenv("XDG_SESSION_TYPE")); if (st == "wayland") qputenv("XDG_SESSION_TYPE", "x11"); QString cd = QString(qgetenv("XDG_CURRENT_DESKTOP")); if (cd != "KDE") qputenv("QT_QPA_PLATFORMTHEME", "gtk2"); This works on my virtual machine - Fedora with Gnome and Wayland ! But is it correct ? It could be controlled with a preference - but for the requirement "out of the box working" the default would have to be...
-
I agree that this is a problem. Setting environment variables is really an "expert" workaround. Ideally Rosegarden should just work out of the box for all users. There are two environment variables which are important for the lv2 plugins: Under Wayland: XDG_SESSION_TYPE=x11 On Gnome: QT_QPA_PLATFORMTHEME=gtk2 Also the qt style plugins should be installed. Can we cover these points without resorting to request the user setting environment variables manually ? Do these Environment variables have any...
-
So I think I have to do the size scaling even for plugins without the scaleFactor option. I have a version which seems to do the right thing for me - tested with several plugins. The good new is that these changes are harmless if the scale factor is 1.0. If someone uses scaling (maybe Lorenzo) feedback would be good. See merge request.
-
use scaling to adjust window size for lv2 plugins
-
Another sleepless night thinking about window sizes* I discovered the QT_SCALE_FACTOR environment variable and setting it to 1.25 gives me scaled up Rosegarden windows. Is this the correct way to do this ? RosegardenMainWindow::self()->devicePixelRatio() didn't work - it always returned 1.0. But RosegardenMainWindow::self()->screen()->devicePixelRatio() seems to work! So now the plugin UI is drawn larger. Unfortunately the resize feature returns the scaled up window size - so if i set this size qt...
-
OK - that size issue won't let me go. It seems sfizz uses the lv2 scale_factor option for scaling the window size. This allows the host (Rosegarden) to scale the size of the window for high dpi displays. Unfortunately the default scale_factor was 0.0 and Rosegarden did not provide the option. I think sfizz would be better off using 1.0 as default. Anyway I implemented the scale_factor option in Rosegarden (just a few lines of code). This gives the correct window size for sfizz. I have just set the...
-
bug 1738 sfizz window size
-
support lv2 scale factor option
-
Hmmm... Never noticed that about the window size. Rosegarden supports the lv2 resize feature which allows the plugin to resize the window. Indeed this feature is called by the sfizz plugin but with zero width and height !!!! Rosegarden refuses a resize request with either width or height zero. So I think I might put the window size problem down as a bug in sfizz. If sfizz sent the correct window size Rosegarden would set it.
-
LV2 Geonkick - opening UI crashes rosegarden
-
LV2 Sfizz - UI not visible
-
So I noticed I updated my system and had to recompile geonkick. Then it worked fine. Also it works on my manjaro virtual machine after I set the environment variable: export XDG_SESSION_TYPE=x11
-
For Wayland I think you need to set the XDG_SESSION_TYPE environment variable export XDG_SESSION_TYPE=x11 I start Rosegarden from a script and I can set the variable in the script. This seems to work for me on my manjaro virtual machine.
-
The code for resetting the inputs and outputs was a little more complicated than I expected. I have a new version - see merge request.
-
reset inputs and submasters when reducing number
-
Merge branch 'master' into bug-1735-audio-mixer
-
I cannot reproduce this on my system. The UI looks good. I am using X11 - could be a wayland issue. I will try again on a virtual machine.
-
Yes I get a crash too. I will look into it
-
I was away from my computer for a few weeks - back now. Seems like a good suggestion to reset the instruments. I will look into it.
-
Logs flooded with thousands of WARNINGs for no connections
-
Yes -when reducing the number of inputs (submasters too) there should be a check for used inputs. I have a fix for this. See merge request.
-
bug 1735 audio mixer inputs and submasters
-
Merge branch 'master' into bug-1735-audio-mixer
-
check audio input and submaster usage
1 >