Absolutely stunning tool that makes Renoise even better than it was. Many thanks.
As is, however some of the keyboard shortcuts (the ones regarding note length, for instance) won’t work on an AZERTY keyboard layout because the top row digits aren’t directly accessible, unlike QWERTY.
The only work-around I can think of is to change the keyboard layout in Windows IME.
Do you think you could add an option within the tool?
Thank you. When you enable the keyboard status bar in Preferences, which keys are the piano roll showing you, when you press just “1”-key or “2”-key without modifiers?
Edit: Shouldn’t be a problem to add an option to enable AZERTY-mode. AS far as i can see, it mainly affects the number keys. I would invert the shift key state for number key row to solve this.
Please try: testversion
Just drop it onto Renoise.
There is a new option, AZERTY mode. Enable this, and the number keys should work. But it works the same way, like in Renoise itself, where you can use CTRL+0 … 9 to change edit step. I tested it with french keyboard layout in Windows 10. When you found other non working keyboard shortcut, then please report them here.
For all intents and purposes, I just checked, the edit step values for the pattern editor are mapped to CTRL+the accented characters by default, it seems (I never changed them).
Thx for testing. Yeah could be possible that Renoise is using scan codes. In the tools api, i only have key name and character. I’ll add some info about AZERTY to the readme, so it will less confusing.
‘C:\Users\myusername\AppData\Roaming\Renoise\V3.2.1\Scripts\Tools\com.duftetools.SimplePianoroll.xrnx’ failed to execute in one of its menu entry functions.
Please contact the author (dufte (toimp)) for assistance…
main.lua:1251: unknown property or function ‘style’. can not assign new properties to an object of type ‘Text’
stack traceback:
[C]: in function ‘_error’
[string “do…”]:15: in function <[string “do…”]:9>
main.lua:1251: in function ‘fillTimeline’
main.lua:2509: in function ‘main_function’
main.lua:2550: in function main.lua:2549
I have a suggestion to you. It is very confusing for me that the window is not painted always in the specified H-Gridsize like defined in preferences.
For explaning my Gridsize is 108 horizontal. I maked a Song with 128 patternlenght and 108 is for me the most comfortable size. After work a few days with this, i reload an old project with only 64 'er patternlenght. And the windows was only half size big. This was so strange that i thought this where a bug in first moment. After some thinking i came on the patternlenght differs causing this. I tried different song with differenf patternlenght and the size of the windows is everytime different when the pattern lenght is under the configured H-Gridsize.
I would prefer if the windows always open with configured gridsize for better ergonimics and overview. if patternlenght is smaler as gridsize value leave the rest unpainted if maybe.
One of the best tools I’ve ever seen a Renoise User add. The fact I can copy, paste, delay, do so much with the editor to transpose as well, see ghost tracks. It’s a complete game changer.
Bless your kind soul for updating it so frequently. Thank you so much for making this, FOR FREE. It’s amazing!
The man is a genius!!!Keep up the good work this is a game changer for a lot of people and although i dont like piano rolls i like to have the option available.Thank you
I think i have found a Bug. If i resize patternlength he stretches last Note. Dont sure if this is expected behaviour.
After the patternlength change i get this
And i have a suggestion too. Can you mark then end of pattern with and blue “E” or something and draw the free windowarea like disabled range. Maybe outhatched or darker or with less saturation painted? This would not looks so empty at smal pattern sizes.
And a Qestion. right direct besides Pianoroll is a 2-3 pixes width viewrange where some half notes (black) will painted white if i set Notes in grid. what means this function?