I spend at least as much time navigating and editing tracks as I do inserting notes. I think it would be nice to be able to use the computer keyboard keys (A-Z) in a command mode, as in VIM. For example:
ESC switch to command mode
NAVIGATION
----------
#(NAV) repeat navigation # times
hjkl navigation keys
w jump to next note
b jump to prev note
m(ABC) set mark to (ABC)
'(ABC) jump to mark (ABC) '
gg goto top
G goto bottom
#g goto line #
EDITING
-------
i,a switch to record mode
q switch to play mode (play keyboard without editing)
x delete under cursor
r replace under cursor
y(NAV) copy in direction (NAV)
yy copy line
p paste
d(NAV) delete in direction (NAV)
dd delete line
u undo
Even if not all of these are implementable, I think just the ability to make your own custom keybindings using A-Z keys could still be very powerful. I wonder, would this be possible to do with LUA scripting? I know that Marks has already implemented pattern jumping, but I havenāt found anything else.
I like the idea. Was thinking about this myself already
Not sure if this is possible with the API, though. You might want to look this up in the documentation.
As a webdeveloper I use something called Emmet to help ease the pain of writing CSS/HTML, there you have Abbreviations where you write a short line of code and enter tab, then it translates that line into plain CSS/HTML like this example:
#page>div.logo+ul#navigation>li*5>a{Item $}
is transformed into:
- Item 1
- Item 2
- Item 3
- Item 4
- Item 5
So you could write a chord with volume, panning and other commands on one line, then tab and it translates that.
I know a tracker is almost already like that, but it could be speed up a bit with something like this as you donāt have to expand fx columns for example or add more columns.
Binding ānormalā (non-modifier, keyboard-piano) keys is doable now, but requires that the keys are catched into a separate GUI. So one should bring up a GUI, focus it - after which all keypresses go through the tool. The downside is that all renoise native keybinds except the ones under āGlobalā context are ignored. So pattern editor navigation for example would not be āactiveā.
Yes, this is an awesome idea, +INF, and totally doable. Especially then having for one beat down, 4 beats down (1 bar), everything in betweenā¦ might be nice!
can I add
v start selection
V start pattern or groupwide selection
and of course the tool would maybe make available new key commands for transpose, but, a toolās kb callback function can also āreturnā a key to renoise. The biggest problem would be the rt playback of notes.
You can create Lua scripts that respond to keyboard shortcuts that you also can add to the large list of keyboard shortcuts in Renoise, though the more advanced functions are not really possible without a pop-up dialog and an input field to fill in if you want to have something like y(NAV) executed.
Btw:ājump to next/previous noteā have existing shortcuts: ctrl/cmd+shift +pgUp/Prior and pgDown/Next
This is a cool idea too, sounds even trickier to implement though! Something for another tool?
Great ideas! It might be good to assign some keys to 25% pattern length, 50% pattern length, lpb, and/or edit step and use those as navigation keys as well. Iād have to think more about that. Of course, in theory the keys would be completely user-modifiable anyway, with the basic framework allowing you to assign custom keybindings. As for start selection, since the start selection key already exists in Renoise, I think that would be no problem!
Interesting. So could you keep the focus on the GUI but keep the GUI hidden? Would it be possible to ācopyā all the Pattern Editor keybinds? Sounds like it could really interrupt your workflow when switching constantly between pattern editor, sample editor, etc. Hmm.
Yeah, things like y(NAV) would be for a future versionā¦the main thing would be to first get a basic framework going that allows you to use keyboard-piano keys as shortcuts.
So apparently this is currently only doable with a GUI?
No, things like y(NAV) are only doable with a gui. All other direct shortcut options can be controlled with a script.
Inspect Paketti for a closer idea of what i was aiming at:
BUT you canāt bind the other direct shortcut options into non-modifier keys that are reserved for computer keyboard-piano. Without a tool gui I mean.
Well, if you donāt want to work with GUI interfaces, you would need to set up timer functions and attach functions to multiple key presses (morse decoder: ctrl+q two times within one second is function x, ctrl+q once is function y, this way you can assign multiple functions to the same key-combo)
I simulated alt-/shift- and ctrl-click for certain buttons the same way (using timers) in epic arpeggiator 3.0, only now you use it for key shortcuts only.
Iām here to bump this bad boy. Was working on a tool that did this via a small dialog window, but Iād still love to have this sort of thing available without the window.
I use vi keybindings in hackeytracky and wish I could in renoise. If I remember correctly, some keybindings are ābaked intoā renoise, and canāt be remapped. This was a long time ago so things could be different.
+1 For command mode - edit mode difference to be able to use keyboard keys directly as shortcuts. Whether it will be Vim shortcuts or some remapping - double mapping of existing key bindings, that Iām not sure. But this looks like a very good idea.
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.
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.