Cut, copy, paste multiple segments in the song editor

[xsleonard]

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]

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//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]

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]

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//issues/46#issuecomment-32611466
.

[Sti2nd]

This so needs to be in a release soon. @lukas-w @andrewrk @tobydox @Greippi @softrabbit @tresf @diizy @everyone

[eagles051387]

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//issues/46#issuecomment-37102869
.

Jonathan Aquilina

[diizy]

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

[tobydox]

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]

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]

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]

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

[eagles051387]

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//issues/46#issuecomment-40466713
.

Jonathan Aquilina

[diizy]

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]

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//issues/46#issuecomment-40476648
.

Jonathan Aquilina

[diizy]

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]

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//issues/46#issuecomment-40477010
.

[devinvenable]

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]

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]

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]

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

[diizy]

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]

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:

• 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.

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]

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//issues/46#issuecomment-40519096
.

[tresf]

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]

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//issues/46#issuecomment-40852445
.

Jonathan Aquilina

[diizy]

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]

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]

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]

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]

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]

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]

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]

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

[diizy]

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]

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]

Ok, I see now:

• It works in 1.2.0-rc2 if I select some parts, then CTRL+clic (and not shift+clic like said in No group operations in song editor #2302 (comment))
• It doesn't work with left clic menu (copy a group + paste doesn't past the group, only the first selected element) (it would be intuitive to have this as well)
• It doesn't seem to delete the selected elements (either with the delete key or the menu)
• It dosn't work at all in 1.1.3 (but I've read this comment No group operations in song editor #2302 (comment))

[farvardin]

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):

• select several items, and delete them with the "delete" key
• copy items with ctrl-C, clic on a position, paste items with ctrl+V.

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)