Submit bug reports and feature requests for the JJOS-XL and 2XL
By dtaa pla muk Wed Nov 16, 2011 7:07 pm
howdy. nym again.
CUT is a good function
however, it creates an issue when it replaces DELETE. this has been discussed on the forums.

old behavior:
1- a user COPIES recorded note data (data A)
2- a user DELETES other recorded note data (data B)
3- a user PASTES recorded note data (data A)

new behavior:
1- a user COPIES recorded note data (data A)
2- a user CUTS other recorded note data (data B)
3- a user PASTES recorded note data (data B)
issue: a user intended to paste data A.

in order to prevent the issue, a user must do the following:
1- CUT undesired note data (data A)
2- COPY desired note data (data B)
3- PASTE desired note data (data B).

it is a change in workflow. it is difficult to train ourselves to the new behavior.
it is a proposition for a change: DELETE returns, but when SHIFT is held, DELETE becomes CUT?
perhaps you know of a better solution to this issue.

thank you for your time.
sincerely
Nym
User avatar
By le rat Wed Nov 16, 2011 7:48 pm
Merging the cut button with the delete button was not a good idea.
Using the shift button is not a good solution either. Because you have to maintain the fkey to select an area.

I'd prefer a solution of customizing the fkey or a copy/cut shared fkey (like the LFO/SIMULT button)

I'd like to see the cut button in the main screen too and a solution for the lack of zoom in the grid.
By dtaa pla muk Wed Nov 16, 2011 9:00 pm
Because you have to maintain the fkey to select an area.


ah yeah. hopefully he'll see that and not add it.

shared fkey could be good. customized would be best. i never needed CUT anyway, was happy with copy/delete.
User avatar
By le rat Wed Nov 16, 2011 9:14 pm
By the way did you understand or could you clarify his answer?

Does he want people to cut, copy and then paste? Sounds confusing and quite counter-intuitive.
By dtaa pla muk Wed Nov 16, 2011 10:21 pm
haha yeah i've been working on my jjenglish since 2006.
Sounds confusing and quite counter-intuitive.

that's exactly right. shouldn't work that way. cut and delete should be 2 separate functions. preferably with delete on the same F key so i don't have to change my muscle memory.
User avatar
By bliprock Thu Nov 17, 2011 1:15 am
Nym wrote:haha yeah i've been working on my jjenglish since 2006.
Sounds confusing and quite counter-intuitive.

that's exactly right. shouldn't work that way. cut and delete should be 2 separate functions. preferably with delete on the same F key so i don't have to change my muscle memory.

Exactly what i think to, and have posted here above. Its the inability to easily keep what you have copied into the pasteboard. I have to do everything backwars now, as a work round as mentioned above.
User avatar
By le rat Thu Nov 17, 2011 8:05 am
Its the inability to easily keep what you have copied into the pasteboard.


I see. The pasteboard of CUT overrides the one for COPY.

To a lesser extent, there's the same kind of problem with CUT i.e. if you press the button twice accidentally the data will be erased. They should be kept in memory until you paste them in my opinion.

I'll send a message too and report the two issues. I hope he will find a good solution.
User avatar
By m:t:c Thu Nov 17, 2011 8:13 am
le rat wrote:To a lesser extent, there's the same kind of problem with CUT i.e. if you press the button twice accidentally the data will be erased. They should be kept in memory until you paste them in my opinion.


That's the same behavior with COPY. If you copy first something and copy again something else it gets overwritten. UNDO should handle this.

What happens if you CUT something and decide that you need to CUT something else without PASTING first? I think this wont be fixed.
User avatar
By le rat Thu Nov 17, 2011 8:35 am
UNDO should handle this


I agree

What happens if you CUT something and decide that you need to CUT something else without PASTING first?


Yeah but since cut is kinda merged with delete it's even worse. it's confusing.
I think we need the three functions available independently and a better management of the UNDO button.
User avatar
By le rat Thu Nov 17, 2011 11:19 am
So it seems that DELETE will come back in the next version, CUT will be removed and JJ will think about a new way to implement it.
By evil A Sulli Thu Nov 17, 2011 3:15 pm
le rat wrote:So it seems that DELETE will come back in the next version, CUT will be removed and JJ will think about a new way to implement it.

In most programs that use "cut", they always have paste ready with the data you just cut. So "cut" and "paste" go hand in hand.

Delete does not load data into paste and undo usually gets the deleted data back. Copy,Delete,Paste is three steps in which copy holds the paste data. Cut and Paste is two Steps in which cut holds the paste data.

I think the settings in 3.08 is needed with "F3" having "Cut" that will switch to "Paste"("F3" now says" Paste") if "Copy"("F2") or "Cut" ("F3") is pressed.

This way "Paste" will hold the data of the last button pressed--either "Copy" or "Cut".
By dtaa pla muk Thu Nov 17, 2011 4:06 pm
I think the settings in 3.08 is needed with "F3" having "Cut" that will switch to "Paste"("F3" now says" Paste") if "Copy"("F2") or "Cut" ("F3") is pressed.


i liked that idea, til i realized what if you copy something, and then realize you copied the wrong part and need to do it over again? you'd have to paste your data first, and then delete it, and then recopy it.

we're getting closer to a good idea, but we're not there yet.
User avatar
By bliprock Thu Nov 17, 2011 4:33 pm
Yeah i dont know if i need cut that badly. I mean with copy/paste and delete im sorted. So i guess give people the option of copy or cut on one funtion key and it toggles/swaps to other function when we hit say mode + F5 [shift button is no good as it is full]. Hows that idea? that way we have both and can swap the function when we want
User avatar
By le rat Thu Nov 17, 2011 7:18 pm
Personally, I'd be happy with multiple shift. I don't need to cut and paste entire bars. I'd be enough for shifting a group of notes like he's showing in the video. For that purpose the "tick" limitation of the shift function is not a real problem I think.