And i would not give my opinion to things, i dont know anything about it!.. I Asked the Projectowner for help to setup a development environment and Tools for that. (Refactoring and Debugging Code) He give me no answer about this. So i help on that what i can do… give hints and testing!!!
This is a major timesaver, as well as Acid Sequencer, amazing ways to create patterns.
Dream come true when Taktik provides new API features. Without that it is just bending API to get Pianoroll plugin to work and still some functions are not possible to realize…
BlockquoteDream come true when Taktik provides new API features.
Blockquote
I have ho hope for this. Before 3 Years, i suggest the upbreak the linked Colorclasses for different Controls to give better Themesupport. Estimated effort in Developer Working Hours 0,5 h max. !!! Nothing happened.
This is very nice and fun. thank you for doing the impossible
So tested this out and jotted some things down:
- Velocity entries going higher than 0x80h. Maybe intentional if there’s intentions for backwards, delay, or cut commands. But for 0xA0h to 0xAFh and 0xF0h to 0xFFh the velocity field has no use for those values.
- Same thing with panning.
Yoooooooooooooooooooo
I must say @toimp, if I knew you personally; I would give you a hug for making this tool. Other users have made some super complicated versions of Piano Roll for Renoise and they charged for it. You have provided this incredible tool that people have been requesting for years. Again, I would hug you if I could … or buy you a beer … or something
Awesome tool ! very practical to visualize chords. The missing drag and drop is not such a big deal !
I have tested the last version and have to say it is nice and useful. If I can suggest, provide please edit/select mode to allow one mouse click for note insert/delete (instead of double click). Unfortunately API doesn´t allow you to play inserted notes but using OSC you can offer that option.
In every case, good job, @toimp!
Thank you for your feedback.
Yep it was intentional for effect commands i want to use with the piano roll (mainly cut commands, extremely useful for VSTi) I’m thinking that is not a big problem when the value goes up to 0xFE. Maybe the Renoise team will add more effect commands in future, so it’ll be already supported, too.
@Lemi OSC is supported, but currently hard coded. Just enable it in the Renoise preferences, set port to default 8000 and udp mode. It should work. Mode buttons are on my todo list. You can use the ALT key as workaround. Holding it, allow you to add notes with just one click. (Its a known shortcut from Reason i was using in the past)
Great! Thank you for your reply. If you replace the grid and keyboard buttons with the images you can implement a renoise hidden xy pad under your grid to support dragging and a renoise slider under the keyboard for scrolling. Buttons don’t allow you to do that I think.
This is looking cool!! I can’t wait to download and give it a try!
If you want to implement drag/drop with a background xyPad, this is a good thread to research for that; there are a couple of demo tools included (using negative spacing in the ViewBuilder rack to position stuff over the xyPad, and using snapback to detect mouse click/release. You can put an inactive button on top, or a bitmap with no notifiers attached. @joule also mentioned something about quickly hiding + showing a button allowing the xyPad behind to catch the mouse click)
I also thought of two things that could reduce scrolling lag; you keep two render buffers, and you scroll by increments of 2 note rows instead of by 1.
Each update of the view grid, you copy buffer1 to buffer2, then you write your new render data into buffer1. You then compare buffer1 to buffer2, and for anything that hasn’t changed since last view update, you don’t need to do anything. But for anything that has changed, you push the data from buffer1 to those buttons/bitmaps. This way you avoid the lag of updating your whole grid when only a few things change. Once this is implemented, if you scroll by 2 rows at a time, “white key” rows and “black key” rows will be mostly unchanged from scrolling each frame, as most of them should line up with the row that was 2 rows above/below them the previous frame.
The viewbuilder lag comes from updating bitmaps (I don’t know why), so doing whatever you can on Lua’s side, to avoid asking Renoise to update any more bitmaps than it has to, will give a substantial speedup.
Hopefully some of this info could be useful
Uploaded a new version with some smaller new features and fixes. It seems the tool updater doesn’t work. I’m not sure why. Maybe anyone have a tip for me?
@toimp I recently had some problems with the tool updater but ended up fixing them, maybe you might find a solution in this thread?
i can confirm this. Updater not shows up new version 0.7.
Your uploaded tool’s ApiVersion
is 6, but the current API version is 6.1, and the updater only looks for tools for “actual” API versions.
Probably it shouldn’t, but uploading a new version of your tool with API version is 6.1 should fix that.
Ok, thx good to know. Maybe this can be changed in future? I’ll change the needed api version for the next update.
Amazing tool, thank you.
Would it be possible to show only keys in selected instrument scale?
this would be great…
- what about function to specify number of microsteps in every note like 1x, 2x, 3x, 4x, 6x, 8x… so it will be easy to create hi-hat rolls (with Rxxx effect maybe) etc ?
Should be possible to show only keys fort the selected scale. Maybe highlight them differently would be easier to implement. I’ll add this to the todo list.
About microsteps, you can use the Rx effect as column effect in the volume and pan field as workaround.
I believe that one way to increase the usage of this tool immensly would be to add tuplet grids (3, 5, 7, 9, maybe 11). It would become the ideal and best tool for “step sequencing” groovy drum patterns!
Maybe even make it better than traditional piano rolls by allowing you to ‘shift’ the grid right and left. I haven’t seen that in other software, but can imagine it encouraging a lot of rhythm experimentation. Add a swing valuebox while you’re at it (S1 only has 10/20/40/60% which kind of bugs me)
(The grid is just an ‘input filter’ which assigns the appropriate position and delay values, right, so it shouldn’t be too complex to implement?)
Edit: Quantize ability is always a big bonus. Maybe even with % if you wanna be ambitious.
Edit 2: Unpopular opinion: refactor the code using OOP and classes before it’s getting too big. It will simplify development, especially later on.