The first time I started it nothing happened when clicking the boxes. And the second time it only shows the keyboard legend. I have no idea what to do.
The first time I started it nothing happened when clicking the boxes. And the second time it only shows the keyboard legend. I have no idea what to do.
Press the OFF button (top left), it must be “ON” for the roll to show things. If you want to edit, you must have the pattern editor with Edit Mode enabled, press [ESC]. You must edit with a loaded instrument.There is an User Guide in English, if you want to continue testing.After a few minutes the tool will self-lock. If you want to continue using it. Uninstall and reinstall it.
Try something else. Load a new song already composed. Load the PRE, turn it ON and press the NC button, so that it switches to TR mode, it will show 4 + 4 tracks around the selected track. In preferences, you can increase it to “-16 TR +16” to show a greater range of tracks. Now play the song.
Edit: Go to User Guide: 2.1. On or off button: ON/OFF.
Button ON/OFF, in different states
2 Likes
Ah, thanks… now it’s working.
(It seems to be a step sequencer, rather. Similar to pianolol.)
Ah, thanks… now it’s working.
(It seems to be a step sequencer, rather. Similar to pianolol.)
Oh well, I’m glad it works for you.
I made an early prototype long ago that instead of moving the line in the progress of the song’s reproduction, it moved the whole roll. But then the data moves (the slots of the notes) and does not allow you to comfortably read the position of the notes while the song is played. For some reason I did not like the result, it involved moving too many things. In fact I would love Renoise to have an optional scrolling mode similar to PRE, where the song is played but the pattern editor parameters do not move, only the line of the reproduction position is moved.
You can disable pattern scrolling using one of the button below the button right next to the record button. Oh man , I always forget about that, so you can actually edit while playing continues.
You can disable pattern scrolling using
one of the button belowthe button right next to the record button. Oh man , I always forget about that, so you can actually edit while playing continues.
If you have the PRE window in the foreground, you can use your keyboard commands. Look in the following link of the User’s Guide: 7. Keyboard Commands. Navigation, control and editing.
Key commands. Go to the “Preferences” window of the PRE and click on the “Keyboard Commands” tab.
PRE has more than 40 keyboard commands of its own, many of them common with Renoise. For example, press [Scroll] to change the playback mode (follow the player’s position in the pattern).
Examine all keyboard commands well. You will see that there are some unpublished functions.
I made an early prototype long ago that instead of moving the line in the progress of the song’s reproduction, it moved the whole roll.
I’m pretty sure you need to build a canvas-like system to make a piano roll. And having it scroll in realtime isn’t that important. Typically, I think there’s only a playback line scrolling.
I’m pretty sure you need to build a canvas-like system to make a piano roll. And having it scroll in realtime isn’t that important. Typically, I think there’s only a playback line scrolling.
PRE works with the roll still, static, and following the playback line with a marker superimposed. Possibly the cleanest design graphically. So you can read much of the pattern (or the entire pattern) from the scroll without moving, following the playback.
Regarding moving the roll, it is only necessary to enclose it in a surrounding frame (a row or a column), and move it playing with the spacing value against another object (another row or column).
From what I’ve been able to experience, the graphic section of the viewbuilder is very fast graphically, as long as you have everything loaded into memory (edit: and not use textures). The only “problem” are the functions that access data: notes, parameters, etc. at the moment of wanting to update them massively almost “in real time”.PRE loads and updates data on a mesh of 120 x 512 buttons, without counting the rest of the objects.That’s 61440 buttons and the GUI works extraordinarily fast.If something works “a little slow”, it is because of the functions that access certain data.
By the way, I recently updated my graphics card. To give you an idea I had an ATI 6950 of 2GB. Now I have a secondhand Nvidia GTX 1070 8GB, much more powerful, and Renoise works almost the same. It is very clear that the CPU is a determinant in Renoise, and when creating these programs, the functions that update the data must be optimized to the maximum.It gives a bit of anger that so much GPU power is not used at all.
Even if it made the roll twice as big, with twice as many objects, it would not graphically resent, but it should handle twice as much data in each update. All this made me decide that PRE would work with the static roll and the playback line moving. It is easier to see the patterns still, it is only necessary to get used to the transition between patterns, or between sections of each pattern, according to the number of lines on the roll.
This is the effect of the automatic movement of the reproduction. The line follows the reproduction, the approach that I have always followed.
(although the capture of the GIF is very slow).
Not to be That Guy™ but distributing a demo version which is basically just a doublelly zipped folder of the source code doesn’t bode well for getting people to pay you for your work. Don’t get me wrong, I’m more than willing to pay for this for the great work you’ve done, and if you weren’t asking for money but instead had a donation button I’d be more than down, but given you’re distributing a plugin among dozens of other, some more complicated, plugins that I’m sure you use for free it sorta irks me that you’d ask the same community that you benefit freely from to pay you.
I’m studying Computer and Electrical engineering right now, so I know more than anyone that you deserve to be paid for this hard work but context matters, and in this case youre just repaying the community that you’ve benefited from before.
so please make it a donation button both by the download and on launch of the plugin. I’ll happily buy you a beer.
Just my oppinon though. This is truly great work and I hope you continue to improve it! It’s amazing you could pull this off in LUA at all.
Hello Vega again.
I did not have time before answering your opinion, since your " entire opinion" can confuse someone… First of all this is a “tool” or program based on LUA, in XRNX format. An XRNX is the same as a ZIP, a compressed container file, with folders with other files, generally in LUA, XML, TXT, images and so on. LUA is a dependent code, depends on a host (Renoise). It can not be an executable with an executable package, such as renoise.exe, for example. Its format is an XRNX (or ZIP) container. Do not expect any programmer to pack LUA into an executable for a Renoise tool. Therefore, your first comment does not make sense.If you want to learn how to make your tools, follow the instructions in the tools forum. You will need time to learn, but with your studies it will be very easy for you.
On your comment on the role of the Renoise community, it seems that in your second comment in these forums you speak on behalf of her. This is a bit strange. A person who has not contributed anything here, is telling another person how to do things, just another who has been contributing things here in these forums for a long time.Yes, I take advantage of the knowledge that I learn for myself and to share it, and I do more to share the knowledge than to share “tools”.You will find many comments of mine asking, discussing and sharing knowledge.
But one thing that differentiates me from you, is that I would never demand someone who does a job and wants some kind of support, that everything is free, much less adding a donation button. You speak of context. Look at the context. You have two options to choose from: A ) free, B )donation. Do you think that people are so sweet and born in a fantasy world and choose option B )?I would love it to be like that, but reality is not like that. Many people want it all for free, and they download it with all the geta in the world, without thanking, or even protesting because it is not fair what they wanted. The worrying thing is that you are studying topics related to computer science, and you must assert your work…It’s not that I care what you do, but it’s good to remember.
Hopefully in these forums there would be people willing to pay, to support, and to promote projects, but unfortunately for the community that you defend so muchit is not like that, everything is free and only “4” people make “tools”, the rest, to download for free. It is curious that those people who do not contribute anything, only download, you do not mention them.I wish there was more variety: free tools, and payment tools, since they are many very different. In any case, if you do not test the programs, or even if you do not want how to use them, you will not know how to value what you have in front of you.But do not worry, there will be hardly any payment tools. Nobody in their right mind loses their time in these things, since few people in the community are willing to support.I am aware of that.
On the other hand, you take for granted that I use the tools of others, as if you knew me or you will use my computer.But I ask you, why do I want others’ tools, if I make the ones I want? Why do you think I’ve learned to do it?
As I said before, I respect your opinion, but I do not share it. It’s all much simpler, if you want to support a developer, support it, otherwise, do not support it, but do not tell him what he has to do and do not tangle, how to do it and much less values his efforts by paying with a beer, as if you knew him and nor are you leading a faculty group of Computer.Maybe he does not like beer and this is not a cocktail bar, they are forums.
The people are free to do what they want with their time and work. If you do not like it, you know what to do.A good way to start is to do it yourself…
2 Likes
All the hard work Raul has put into this and all the people crying for a pianololl for several years. And now it’s here, yet no love from the crew (renoise and resident users in here). Seems wrong! I will try it as I love to bang out some drums one the keyboard and this seems just right for that. Thank you dear Raul.
Thanks Anthonio!
It is probably necessary that some time passes. This is a forum like many others, and there are many people here who still do not know of its existence. The information needs time to circulate, and here there is a lot of “hidden” information.Only with the guide can you get bored,and the PRE tool needs a bit of learning and adaptation, like any new thing…
Also some of us usually make the mistake of ignoring a lot of information provided and directly download the demo and try it, without knowing how to start or its potential. And just spent some time learning from the user guide and with practice, we got to learn to control the program in question.
On the other hand, keep in mind that the atmosphere in the forums is helpless. People want progress in Renoise and ask for things that never come. In the end people get tired.The Piano Roll issue is one of the oldest of these forums.Since I started with these forums, I have always had the illusion of building my own PR.
1 Like
Just registered to get a PRE license and show support. Awesome!
Just registered to get a PRE license and show support. Awesome!
Thank you very much for your support!
Enjoy it!
‘Not to be That Guy™ but distributing a demo version which is basically just a doublelly zipped folder of the source code doesn’t bode well for getting people to pay you for your work.’
It’s too bad that Renoise doesn’t use LuaJIT that is much faster and can be compiled to bytecode.
It’s too bad that Renoise doesn’t use LuaJIT that is much faster and can be compiled to bytecode.
From what I have seen so far when creating my tools, LUA and the Renoise API Viewbuilder are fast enough to satisfy practically everything we need. It would be necessary to expand some things for greater control and little else.
However, Renoise has been using version 5.1 of LUA, dated since 2006, when version 5.3 was recently released and version 5.4 has already been developed, which also improves the compilation. I would say that the problem is not the code itself, but rather how it is designed in C under the hood of Renoise to give us access to the data from its API.That is, make access to the data faster. For example, why is the line_notifier so aggressive? Does that depend on LUA?I guess this is not the place to discuss these things …
Raul, interpreted Lua is sure is fast enough for most tasks. For anything more serious, it’s not. On top of the speed issue, Renoise nags about script being busy every several seconds.
Maybe I just need to upgrade my several years old computer 
Maybe I just need to upgrade my several years old computer
I would like to know what you mean by “anything more serious” :lol:.If you have an old PC, I suggest you try to get a more powerful CPU. As far as I know, Renoise is very dependent on the CPU, and the graphic aspect is very fast. As I said before, I changed my graphics card to a more powerful one for other things, and with Renoise I do not notice any improvements at all. If you want Renoise to go smoothly, use a powerful CPU. Before complaining about LUA, maybe the issue to improve is elsewhere.If you want to use powerful or “large” programs, use hardware that is up to the task.That way you will stop worrying about these performance details.If Taktik has used LUA, it will be for something…
I have 6 core X5660 running at 2.79 ghz. More serious… any numerical analysis of even small datasets is a pain in ass due to Renoise deliberate interruptions (I’m no talking about overall slow Renose performance). This makes me want to switch to LuaJIT and communicate with Renoise through OSC.
More serious… any numerical analysis of even small datasets is a pain in ass due to Renoise deliberate interruptions…
What do you mean? Can you put some practical example in LUA?In general, if you program anything, it is good practice to avoid doing unnecessary operations. As far as I know, you have almost instant access to almost all the necessary data for your tools. You can have “delays” in some function if you need to access specific data, for example within the columns of notes of several tracks at once and things like that (iterating sharply). But you can create your own tables to access this data only when necessary. In the end, the problem is not the code, but rather how well constructed is it for the programmer. If there is something that you think does not measure up, better not use it and look for an alternative.
I do not think Taktik is willing to use LuaJIT, if he has not updated to LUA 5.3 yet. These forums are full of high quality tools that require such a change? If almost nobody creates tools and many old ones are abandoned.Where is Taktik? Do you see it here solving things?
In the end, we have to use what we have. There’s no choice. Either that, or go somewhere else.
1 Like
It’s too spread out over too many functions to post Lua example. I’m loading a few hundred phrases from disk and doing some processing and categorizing (note distribution, transpose and grouping based on scales and keys). That takes a minute or two and it’s interrupted by Renoise which assumes that the script hangs. I suppose Renoise is just not the right tool for this.
I’m loading a few hundred phrases from disk and doing some processing and categorizing (note distribution, transpose and grouping based on scales and keys). That takes a minute or two and it’s interrupted by Renoise which assumes that the script hangs. I suppose Renoise is just not the right tool for this.
Ah ok, but this does not depend on LUA, nor any tool, this depends on the executable of Renoise, its motherboard, CPU and RAM basically. It is passing data from the hard disk or SSD to the RAM memory through the CPU ordered by Renoise. If you have problems here, you will have to look at these factors. Another thing is that you are using a specific LUA tool that has to do with that, or that does not stop reading “things” when adding data in the pattern editor, for example. Before I mentioned an example, as the line_notifier. If you have a function in a tool using it constantly, you can have problems if you change the data of the pattern editor (delete patterns, lines, tracks, or add notes, parameters, things like that). But this is a very specific case, which does not depend on the LUA code, but on how the API is designed to access the data. In general, LUA goes very fast. I have no complaints here. Yes I have experienced strange things with the use of textures in the GUI, and other details.
By the way, if you use OSC Server, you can send messages in real time to shoot and stop notes. Generally, I only miss more things within the Viewbuilder, and some API improvements in general to access certain data. That Renoise resents processing other things, that’s another issue. For example, think about adding one more instrument to your song when you have dozens of them. Here you will notice “delays”. That depends on how it’s programmed under the hood, not the code itself. You can use the code right or wrong. That does not mean that LUA is the best. Everything is improvable. But for Renoise I consider LUA a good companion.
1 Like