search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.09k stars 1.01k forks source link

Cut, copy, paste multiple segments in the song editor #46

Closed xsleonard closed 10 years ago

xsleonard commented 10 years ago

To my knowledge, only one segment can be click-drag copied at a time. This is very tedious.

Selecting multiple segments and click-dragging any one of them should copy all of them to where the cursor is released. In lmms 0.4.15, performing that action ignores the selection and only copies the segment that was originally clicked.

I am not sure if it would be best to place the first segment from the selection onto the releasing cursor location, or copy the selection relative to the segment that was first clicked. The former is probably best since there is no UI indication of multiple stacked segments and the latter would cause frequent mistaken overlapping.

unfa commented 10 years ago

Thanks for filing this.

I think that the most natural thing would be to place a copy of the clip the user has used as a "handle" for the selected group directly where he releases the drag (under the cursor) and place all other clips relative to it's position.

Also making the duplicates 50& transparent until the drag is released would be a good thing. And for example pressing ESC should break the operation without doing any duplicates. This "break function" can be omitted if we have a rock-solid UNDO function. Also a tip should be displayed under the cursor while it's being Ctrl+Dragged: "Press ESC to cancel".

2014/1/17 Steve Leonard notifications@github.com

To my knowledge, only one segment can be click-drag copied at a time. This is very tedious.

Selecting multiple segments and click-dragging any one of them should copy all of them to where the cursor is released. In lmms 0.4.15, performing that action ignores the selection and only copies the segment that was originally clicked.

I am not sure if it would be best to place the first segment from the selection onto the releasing cursor location, or copy the selection relative to the segment that was first clicked. The former is probably best since there is no UI indication of multiple stacked segments and the latter would cause frequent mistaken overlapping.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46 .

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$ !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv b+>+++ DI>+ D+ G e h-->- !r y--() ------END GEEK CODE BLOCK------

xsleonard commented 10 years ago

One other reason for pasting the first selected segment where the cursor is released regardless of which segment was originally grabbed is that it minimizes the distance you must drag. Say I select 4x1 bar segments, click-drag from the last selected segment to the adjacent empty segment, and the entire selection is pasted on the next 4 bars. Otherwise the distance you must move the mouse is proportional to the length of the selection, which runs into further issues when the length is over half the width of your song editor panel.

Also, pasting segments on top of each other is rarely desired. If one really wanted to paste on top of each other, they could still release the cursor on top of another segment.

I agree with the transparent duplicates regardless of the rest of the feature's behaviour.

unfa commented 10 years ago

I think you're right. U guess the clips will not be shifted vertically. However the dragging behaves, the transparent ghost clips will let the users know where stuff will land, and event when'd they drop the duplicates, they can pick them all up easily as long as they're selected: On 17 Jan 2014 15:49, "Steve Leonard" notifications@github.com wrote:

One other reason for pasting the first selected segment where the cursor is released regardless of which segment was originally grabbed is that it minimizes the distance you must drag. Say I select 4x1 bar segments, click-drag from the last selected segment to the adjacent empty segment, and the entire selection is pasted on the next 4 bars. Otherwise the distance you must move the mouse is proportional to the length of the selection, which runs into further issues when the length is over half the width of your song editor panel.

Also, pasting segments on top of each other is rarely desired. If one really wanted to paste on top of each other, they could still release the cursor on top of another segment.

I agree with the transparent duplicates regardless of the rest of the feature's behaviour.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-32611466 .

Sti2nd commented 10 years ago

This so needs to be in a release soon. @Lukas-W @andrewrk @tobydox @greippi @softrabbit @tresf @diizy @everyone

eagles051387 commented 10 years ago

I agree, Question is how much is already in place for this for 1.0?

On Sat, Mar 8, 2014 at 5:58 PM, Stian Jørgensrud notifications@github.comwrote:

This so needs to be in a release soon. @Lukas-Whttps://github.com/Lukas-W @andrewrk https://github.com/andrewrk @tobydoxhttps://github.com/tobydox @greippi https://github.com/greippi @softrabbithttps://github.com/softrabbit @tresf https://github.com/tresf @diizy https://github.com/diizy @everyone https://github.com/everyone

Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-37102869 .

Jonathan Aquilina

diizy commented 10 years ago

Mmm, I don't see this happening for 1.0.0. I'll mark this for 1.1.0 for now.

tobydox commented 10 years ago

Do we have any initial implementation at all? Because if not, IMHO we should not mark it for 1.1.0 which could be released in April already.

diizy commented 10 years ago

On 03/08/2014 08:52 PM, Tobias Doerffel wrote:

Do we have any initial implementation at all? Because if not, IMHO we should not mark it for 1.1.0 which could be released in April already.

I've been marking some things as 1.1.0 because we don't have any later milestones, the idea being that we can just move ahead what we don't have time to finish...

I guess we could just add a 1.2.0 milestone already? Although it might be hard to know in advance, which ones should be pushed that far back.

rawthought commented 10 years ago

The shortcuts "ctrl+a", "ctrl+c", "ctrl+v" in the song-editor would be appreciate too, but I imagine it comes logicaly with the copy/paste option...

devinvenable commented 10 years ago

+1 This is the most important missing feature. People have been complaining about it since 2011.

eagles051387 commented 10 years ago

Would be a great 1.1 feature for sure. Vesa do you think this should be for the 1.1 milestone?

On Tue, Apr 15, 2014 at 12:26 PM, devinvenable notifications@github.comwrote:

+1 This is the most important missing feature. People have been complaining about it since 2011.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-40466713 .

Jonathan Aquilina

diizy commented 10 years ago

On 04/15/2014 03:13 PM, eagles051387 wrote:

Would be a great 1.1 feature for sure. Vesa do you think this should be for the 1.1 milestone?

If someone implements it during the next two weeks, sure. Otherwise no.

eagles051387 commented 10 years ago

What I am very curious to know is what it would entail to implement

On Tue, Apr 15, 2014 at 2:45 PM, Vesa V notifications@github.com wrote:

On 04/15/2014 03:13 PM, eagles051387 wrote:

Would be a great 1.1 feature for sure. Vesa do you think this should be for the 1.1 milestone?

If someone implements it during the next two weeks, sure. Otherwise no.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-40476648 .

Jonathan Aquilina

diizy commented 10 years ago

On 04/15/2014 03:46 PM, eagles051387 wrote:

What I am very curious to know is what it would entail to implement

Lots of coding in C++. Track.cpp and the songeditor would probably need some quite big changes to make this happen.

eagles051387 commented 10 years ago

Why not make this in its own file and call it from the respective files On 15 Apr 2014 14:49, "Vesa V" notifications@github.com wrote:

On 04/15/2014 03:46 PM, eagles051387 wrote:

What I am very curious to know is what it would entail to implement

Lots of coding in C++. Track.cpp and the songeditor would probably need some quite big changes to make this happen.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-40477010 .

devinvenable commented 10 years ago

Conceptually this operation doesn't seem difficult. We already have code to select multiple tracks in song mode via edit mode tool. (Though I'm not sure if this state is stored anywhere, or just reflects in the UI.)

We already have code that duplicates track cell elements via ctrl-drag. Why not just enable the copy and paste menu items, and do this: for each track ---for each cell in bounding box for track --------invoke existing copy operation for cell, but offset copy by number of cells in track --------(if 8 cells to copy, cell 1 gets copied to 9, 2 to 10, ...)

I'm oversimplifying, but also suggesting that we "should" be able to repurpose most of the exiting functions by wrapping them with a higher level controller class or function.

xsleonard commented 10 years ago

When I looked at the code 2 years ago, it seemed simple enough to implement this for the bare minimum functionality.

I may get to this myself, but depends on the compilation time. Last I checked it took 10-30 minutes. If I am not remembering wrong, anyone aware of a way to minimize recompilation time in this project? Ideally <10 seconds, but <60 would be workable.

diizy commented 10 years ago

On 04/15/2014 07:07 PM, Steve Leonard wrote:

When I looked at the code 2 years ago, it seemed simple enough to implement this for the bare minimum functionality.

I may get to this myself, but depends on the compilation time. Last I checked it took 10-30 minutes. If I am not remembering wrong, anyone aware of a way to minimize recompilation time in this project? Ideally <10 seconds, but <60 would be workable.

It only takes a longer time the first time you do it. Cmake caches the files and if you only make a small change, you only need to recompile the changed files - which cmake detects automatically.

Usually, for me, small recompiles take 10-15 seconds.

xsleonard commented 10 years ago

I should be good then, especially if I can use clang.

diizy commented 10 years ago

On 04/15/2014 08:12 PM, Steve Leonard wrote:

I should be good then, especially if I can use clang.

IIRC there's still some issues with clang compatibility... not sure about that though, you're welcome to try...

tresf commented 10 years ago

IIRC there's still some issues with clang compatibility... not sure about that though, you're welcome to try...

I'm sure this depends on the version of Clang being used, but LLVM 3.4 won't work with SWH, VST and OPL2 due to strictness in the compiler. It also will error out for warning scenarios. Note, it hasn't been tested against with STK yet either. From my tests, this is what's needed to get it to work:

To allow Clang to build with warnings:

To prevent Clang from compiling SWH & VST support:

To prevent OPL2 from compiling OPL2 plugin:

Also, the build instructions say to use make -j2, but from my experience, the -j2 switch won't work.

A detailed description of these work-arounds, which were discovered using OSX Mavericks can be found here: https://github.com/tresf/lmms/wiki/Compile-LMMS-for-OSX-Mavericks#download-and-compile-lmms

Most of these work-around have been committed to stable-1.0.0 using ifdefs, etc, however the ifdefs currently detect Apple OS rather than Clang compiler so if you aren't building on Apple, you would need to adjust these manually.

Also, not all of these have been committed to the unstable branches yet, so post here with errors and I'll chime in to let you know if there's a quick work-around.

unfa commented 10 years ago

I guess clang is not klang? As in Kernel Level Audio Next Generation? On 15 Apr 2014 20:48, "Tres Finocchiaro" notifications@github.com wrote:

IIRC there's still some issues with clang compatibility... not sure about that though, you're welcome to try...

I'm sure this depends on the version of Clang being used, but LLVM 3.4 won't work with SWH, VST and OPL2 due to strictness in the compiler. It also will error out for warning scenarios. Note, it hasn't been tested against with STK yet either.

To allow Clang to build with warnings:

  • CMakeLists.txt (Comment out -Werror flag)

    SET(WERROR_FLAGS "${WERROR_FLAGS} -Werror")

To prevent Clang from compiling SWH & VST support:

-

CMakeLists.txt (Turn off SWH and VST support)

OPTION(WANT_SWH "..." OFF) OPTION(WANT_VST "..." OFF)

To prevent OPL2 from compiling OPL2 plugin:

-

plugins/CMakeLists.txt (Comment out opl2 directory)

ADD_SUBDIRECTORY(opl2)

Also, the build instructions say to use make -j2, but from my experience, the -j2 switch won't work.

A detailed description of these work-arounds, which were discovered using OSX Mavericks can be found here: https://github.com/tresf/lmms/wiki/Compile-LMMS-for-OSX-Mavericks#download-and-compile-lmms

Most of these work-around have been committed to stable-1.0.0 using ifdefs, etc, however the ifdefs currently detect Apple OS rather than Clang compiler so if you aren't building on Apple, you would need to adjust these manually.

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-40519096 .

tresf commented 10 years ago

On Fri, Apr 18, 2014 at 7:13 PM, unfa notifications@github.com wrote:

I guess clang is not klang? As in Kernel Level Audio Next Generation?

No, clang is just a modern compiler which breaks a lot of older code when its used.

Its the default compiler on OSX, so I've been battling with it recently. :)

-Tres

eagles051387 commented 10 years ago

clang = compiler sadly unfa

On Sat, Apr 19, 2014 at 1:13 AM, unfa notifications@github.com wrote:

I guess clang is not klang? As in Kernel Level Audio Next Generation? On 15 Apr 2014 20:48, "Tres Finocchiaro" notifications@github.com wrote:

IIRC there's still some issues with clang compatibility... not sure about that though, you're welcome to try...

I'm sure this depends on the version of Clang being used, but LLVM 3.4 won't work with SWH, VST and OPL2 due to strictness in the compiler. It also will error out for warning scenarios. Note, it hasn't been tested against with STK yet either.

To allow Clang to build with warnings:

  • CMakeLists.txt (Comment out -Werror flag)

    SET(WERROR_FLAGS "${WERROR_FLAGS} -Werror")

To prevent Clang from compiling SWH & VST support:

CMakeLists.txt (Turn off SWH and VST support)

OPTION(WANT_SWH "..." OFF) OPTION(WANT_VST "..." OFF)

To prevent OPL2 from compiling OPL2 plugin:

plugins/CMakeLists.txt (Comment out opl2 directory)

ADD_SUBDIRECTORY(opl2)

Also, the build instructions say to use make -j2, but from my experience, the -j2 switch won't work.

A detailed description of these work-arounds, which were discovered using OSX Mavericks can be found here:

https://github.com/tresf/lmms/wiki/Compile-LMMS-for-OSX-Mavericks#download-and-compile-lmms

Most of these work-around have been committed to stable-1.0.0 using ifdefs, etc, however the ifdefs currently detect Apple OS rather than Clang compiler so if you aren't building on Apple, you would need to adjust these manually.

— Reply to this email directly or view it on GitHub< https://github.com/LMMS/lmms/issues/46#issuecomment-40519096> .

— Reply to this email directly or view it on GitHubhttps://github.com/LMMS/lmms/issues/46#issuecomment-40852445 .

Jonathan Aquilina

diizy commented 10 years ago

On 04/19/2014 09:37 AM, eagles051387 wrote:

clang = compiler sadly unfa

Not so sadly... better we're talking about Clang than Klang... nothing good can come from bringing up Klang ;)

xsleonard commented 10 years ago

I'm going to pass on clang since gcc is compiling it quickly enough but will look into adjusting the ifdefs to detect clang rather than apple where clang is intended.

Which branch should patches be developed against?

diizy commented 10 years ago

Master.

Also, you should preferably make the feature work with undo/redo, which is done by calling addJournalCheckPoint() just before changes are made to the track objects. I'm not sure where exactly this should be called for this group copy/paste functionality, maybe @tobydox could elaborate on that...

tresf commented 10 years ago

will look into adjusting the ifdefs to detect clang rather than apple where clang is intended.

Thanks for mentioning this. I have some candidates for this coming up. I plan to continue using LMMS_BUILD_APPLE for now but let me know when this happens and I can separate the compiler specific fixes from the OS specific fixes (at least the ones I've done). I'm working from stable-1.0 BTW.

tresf commented 10 years ago

I plan to continue using LMMS_BUILD_APPLE for now

Scratch that... this SWH stuff I'm working on prob shouldn't be adulterated with LMMS headers if they're not needed. #ifdef clang seems to do the trick, so that's what I'm switching clang specific code to.

tobydox commented 10 years ago

As long as you're only adding Clang-specific things inside these #ifdefs everything is fine. Please do not add OS X specific things as compilation would fail with Clang on Linux for example.

tresf commented 10 years ago

As long as you're only adding Clang-specific things inside these #ifdefs everything is fine. Please do not add OS X specific things as compilation would fail with Clang on Linux for example.

Will do.

xsleonard commented 10 years ago

Any idea why I can't drag wav samples from the file browser onto the song editor?

diizy commented 10 years ago

This was merged in master so I'm closing the issue as resolved. If there's issues with the implementation that need discussion, it can be continued in a new specific issue or on the mailing list.

farvardin commented 7 years ago

Hello,

In the last message, it says it was implemented in master, for milestone 1.2 and 1.1

I've tested it on LMMS 1.1.3 and latest LMMS 1.2.0-rc2, and it doesn't seem to be implemented. Have I missed something?

farvardin commented 7 years ago

Ok, I see now:

farvardin commented 7 years ago

I think this issue should be reopened because the way the song editor works is not very consistent with the rest of the copy/paste behavior (like in the piano roll):

Copying multiple segments with ctrl + drag is useful, but not in all occasions, like if you need to copy some segments which are located earlier in a very long song (you have to zoom out, if it's still possible)