Yeah, I think that may have been the issue (tried this a long time ago). Some of the core vi movement keys are also piano/note input keys.
1 Like
maybe it’s time to shill my long-dormant vi emulation tool:
https://bitbucket.org/cupcake99/vi-noise/src/master/README.md
so far it has the basic movement commands and some limited editing. it can take a count and then will repeat the command the requested number of times, as in vi/vim (eg. 12j, will jump 12 lines down the screen). been planning to add more commands but time and interest have been limited.
annoying thing is that the tool sub-window must be open to use the ‘vi’ commands, but it can be mapped to a key shortcut, so it’s not too bad. ‘i’ will enter ‘insert’ (aka edit) mode when the window is open, so it’s kind of a modal editor layer.
i’ll create a proper thread for it later. code is also a bit messy. but for now, if you know what to do, clone away.
4 Likes
one thing i got stuck on is how to define objects, such as: what does ‘w’ move to, is it per beat? per note? hard to choose. also definitions for search in composable commands like dt_ where _ is a search object that would just be a normal text character in vim. then how to define what range the commands operate on, is it limited to a single pattern, or per track over the whole song, per line on every track? lots of choice.
if anybody has any ideas for the way they would like to work with vim style commands please say so, maybe we can hash out a sensible system.
2 Likes
I forget how I did some of the movement keys like w, etc in HackeyTracky I’ll have to dig up my config. I tried using your extension and it loads OK, but I don’t see the window. Is there more I need to do other than dragging the .xrnx?
for now you have to open the window manually using a key command of your choice. it’s found under global:tool:vi-noise toggle in the preferences. i hardcoded option+command+v to do this, but i’m on a mac so that probably wont work if you have a different system. in fact it might not toggle properly at all (another thing to add to the list alongside a menu bar item etc).
Do have a look at the Command palette tool, it’s a nice alternative
Got it working, thanks. I was able to move between edit mode with ‘i’ and esc, and insert notes and move around with vi keys, pretty sweet! So much better than using the arrow keys.
The only issue I saw was that anything that required the shift modifier didn’t seem to work “$”, any numbers, ‘G’, etc.
hmm, not sure what the problem there could be. Perhaps system implementation differences? I haven’t accounted for any of that sort of thing yet as i just wanted to make it for myself first and i use a Mac. ‘G’ should take you to the last line, as ‘gg’ would do for the first line. Same with ‘$’ and ‘0’. All are working fine on my computer. I’ll try and have a look at it next week when i have a free moment. Glad you got it (sort of) working anyway!
1 Like
Hi. I just had a quick look back through the source code to remind myself how the tool handles the shift keys. I actually didn’t expressly use shift anywhere, but instead rely on the name or character of the key pressed. So when you do ‘shift-g’ it should get ‘G’ as the character to use in a command composition. Same for any of the characters that are on the shifted number row. Strange that you found a problem with this. The only things i can think is if you have ‘right-side modifiers’ set to assignable in the Renoise preferences it may not work, or possibly you are using a keyboard with non-standard character mappings? I don’t know. If there is a way to grab the scan code of the keys inside Renoise maybe i could add a line in the tool window to show them so we can see if you are getting a different number from me. Will look into it later in the week.
On your difficulty on defining upon “objects”, this is what I got to. There’s a serial/parallel type of distinction between objects in renoise versus objects in a text editor. A text editor is not required to (unless forced upon) handle with columns and rows. All objects in a text editor are in essence serial, IMO.
A renoise definition of a “movement” or an “object” or such would probably be that the two (serial/parallel) would be defined separately. There is a “siphon” of sorts in action in the lua framework which kind of forces sort of roughly serial-parallel-serial-parallel sort of definition, though.
So. A ‘word’ in parallel would be (maybe?) a column. A ‘word’ in serial would be (maybe?) a beat.
A ‘paragraph’ in parallel would be (maybe?) a track group? A ‘paragraph’ in serial would be (maybe?) a named sequence block?
I’m just throwing these in the air to illustrate my point, they’re not really thought through. Just making them up as I go. So maybe my point is that instead of just w and W, it could be that one needs maybe ctrl-w and ctrl-W also to make it to the two dimensions needed in renoise? Or other modifier key. Or a g-combo. (could gw be a good fit?)
In a distant past I had a dream that one could whip up these kind of ‘macros’ with these vim like commands/combos and bind them to shortcuts.
Haven’t tested the actual tool yet. Going to do so soon.
2 Likes
hi, thanks for your ideas. i like the way you’ve broken it down. yes i agree there should be some kind of command variety for a column, like in vim you can ‘visual’ edit by column with ctrl-v. Handling modifiers is not yet implemented in the tool, but i think it should be easy enough to add in a simple check routine to look for modifier flags when dispatching the command. also your idea to use the vim general extension prefix of ‘g’ is really good, as it would be easy to implement. i do want to add in a ‘visual’ mode at some point. and also more ‘ex’ style commands.
the way i have written the tool relies heavily on regex checking of the input command. in theory this could be split or chained into subcommands to make more complex actions, like running a command across x number of lines in tracks in the range y to z etc.
would love some feedback after you get a chance to try the tool out.
Edit: I’ve gotten a dm stating that my reply was a bit… fluffy. To clarify, I did not intend to make a super thought out response, but just to throw out the current jumble of ideas in my head. So, approach this post as such. I’ll try and make some effort to be more concise in the future.
Ok, had a quick check. If I load the demo song Daed - Bears and try a movement command, the tool fails. Checked that and seems to me like in actions.lua, line 52, you should reference song:pattern(_) instead of song:pattern(i). Also it seems that in parseLineCount, currentLineInSong there’s a similar kind of confusion of sequence index and pattern index, but that’s very fixable. 
(…also in G and $ it seems.)
As for some general comments on this idea:
If one would want to be comprehensive, the two dimensional approach I outlined in the previous post would not fully cut it, either. With this I mean that if one for whatever reason might want to perform some “ex” type command on patterns that are not present in the current sequence list, there’s no way to refer them.
If I correctly recall the venture I had into this, I ended up in a set of “objects” that was something like:
“pattern level objects”
B = a named sequence block
Q = pattern in sequence
P = general pattern, not necessarily sequenced
“track level objects”
G = track group
T = track
“line level objects”
L = a line in pattern
“column level objects”
C = general “column”
N = a column in track’s note columns
E = a column in track’s effect columns
“subcolumn level objects in N”
I = instrument number ‘column’
V = volume ‘column’
“subcolumn level objects in E”
F = effect number ‘column’
X = effect value ‘column’
So if a vim command takes the form of [count][command][motion], those “objects” would be used to define the “motion” part. A motion q for example would then mean ‘one sequenced pattern forward’ in the sequence list. I never got to an end result that I fully liked, though.
The big general problem I see is that instead of that ‘serial’ type of situation, where one needs to edit basically one type of data - ‘characters broken into lines’, there’s a more nuanced situation where one needs to edit a richly typed sort of data. I think the general word / paragraph type of motion would only cut it to describe one dimension, but if it could be prepended or appended with the context of that dimension, it could maybe work.
If I’m not completely misremembering this, a motion of t1 would have meant - to track 1. ‘q1’ would have meant into sequence position 1. ‘p1’ would be kind of ambivalent, though, because it would refer to a pattern that is not necessarily sequenced. I think I settled into the idea that p1 would either be a motion of ‘next sequenced instance of pattern 1’ or if pattern 1 is not sequenced, ‘this sequenced pattern and change it to pattern 1’.
In that vein, combined with the idea of words/paragraphs, and remembering that ‘word’ is a set of characters between whitespace/newlines, I think ‘tw’ (or ‘wt’?) could mean… umm, well. Is it… in the ‘direction’ of tracks, until next ‘non-empty’ track? And ‘lw’ (or ‘wl’?) would mean in the ‘direction’ of lines, until next non-empty line?
I don’t know. But I’m intrigued. I never got my ideas to be very concise or coherrent back in the day, and I’m definitely not a coder myself. But I do see some fun potential in this.
Edit: Adding that there could of course be some ‘default’ context/direction for word and paragraph type of motions. Maybe the line context would make most sense?
1 Like
nice catch, thanks. i’ll look into why this is happening. the movement commands work fine on an empty song, so you’re probably right about the confusion between seq index and pattern index.
as for the rest it’s a lot to take in! will read through again and parse the whole thing tomorrow. i do want to try and keep things as close to standard vim as possible though, so looking to try and re-use existing text object keys for renoisey bits, but mnemonic naming is also good. let’s see where it goes…
oh my goodness. I just started renoise this week. I used to use Jeskola back in the day.
I couldn’t be more excited about it. but… I actually suddenly can be more excited about it. I just made this account to follow up here. I went into my vim-bound terminal to activate this account using my vim-bound mail client, and now I’m typing from my vim-bound browser.
As a n00b with renoise, could I get some clarity on how easily implementable vim key-bindings could be, and what my methodology should be?
Thanks so much!!
Dot
okay now that I’ve been using renoise for a bunch of hours, I sat down and read this thread more carefully. I really hope we can get this functionality to be more robust at some point. I have limited mobility, and part of how I deal with is vim commands and custom keyboards which can’t do single presses of mod keys easily. I might just have to remap those, but vim functionality would be amazing
all of these weird keybindings could be easily replaced with the use of leader keys and a more robust multi-mode setup. what a dream! I’ve been dreaming of this for years, as it’s been tough to use conventional daws without the mouse. but I’ve never been so excited about it as I am about this, especially now that I’m getting some cool sounds in renoise!! <3
1 Like
Yes, I’ve had mobility issues for twenty years which affect my capacity to reliably use my hands. The solutions stated above are the solutions I have. I have used a trackball.
good idea. I tried one of those about 20 years ago when my problems started. It didn’t help. I’ve been using a vertical mouse when necessary which is a massive upgrade from anything else as far as pain/discomfort/numbness is concerned, but in the end I just have way more ability on my special custom keyboards. especially if things are vim keybound and I don’t have to use the mouse. <3
( Thread clean-up: Let’s try to be considerate and remain on-topic, ok? )
1 Like
g for top of pattern and GG to bottom of pattern would be cool. ( I see this already discussed )
and I would use 16yy, to yank 16 lines of my pattern to my clipboard, too 