New tool (3.1.1): Piano Roll Editor v3.0 build 136 (February 2019)


(Raul (ulneiz)) #22

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.


(olxsw) #23

Just registered to get a PRE license and show support. Awesome!


(Raul (ulneiz)) #24

Just registered to get a PRE license and show support. Awesome!

Thank you very much for your support!

Enjoy it!


(fiasko) #25

‘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.


(Raul (ulneiz)) #26

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 …


(fiasko) #27

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 :slight_smile:


(Raul (ulneiz)) #28

Maybe I just need to upgrade my several years old computer :slight_smile:

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…


(fiasko) #29

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.


(Raul (ulneiz)) #30

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.


(fiasko) #31

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.


(Raul (ulneiz)) #32

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.


#33

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.

Quickly point out look into Lua coroutines ( https://forum.renoise.com/t/example-slicing-up-a-processing-function-with-coroutines/30333 ) to at least help rid yourself with the ‘every 10 second interruption’ dialog.

Also just to clarify that Renoise standard Lua is executing Lua bytecode. LuaJIT takes it a step further and ‘JIT compiles’ the Lua function(s) bytecode down more into the processor native architecture for execution.

I suppose Renoise is just not the right tool for this.

That’s probably true sir.


(Raul (ulneiz)) #34

… That takes a minute or two and it’s interrupted by Renoise which assumes that the script hangs.

Since 4Tey has clarified some things, let’s punctuate until the end.The script does not hang at any time. Renoise interrupts it because the process lasts more than 10 seconds (Renoise is programmed like this, it could be 20 or 30). But if the script is well programmed, it does not hang, it is simply interrupted by Renoise. In fact, you can click with the mouse to the option to continue the process, and the script will end with the whole process, correctly. Every 10 seconds the warning window would appear again. I suppose this is a Renoise security method, to avoid “malicious tools” or “bad tools”.

If you are using a specific tool that can load multiple instruments with 126 phrases each, on a song that already has multiple instruments WITH hundreds of notes in multiple patterns, you will have performance problems, since you will have to update the indexes of each instrument inside the patterns. With the coroutines, you can make the script work for a long time without any interruption. I do not think that manipulating the phrases needs much process, since it only modifies xml files. They should be very complex phrases.

In any case, it seems that we are diverting the thread. I suggest to have a new one if you want to discuss the code or problems with Renoise…


(fiasko) #35

Quickly point out look into Lua coroutines ( https://forum.renoise.com/t/example-slicing-up-a-processing-function-with-coroutines/30333 ) to at least help rid yourself with the ‘every 10 second interruption’ dialog.

Thanks :slight_smile:


(Raul (ulneiz)) #36

New version 2.0 of Piano Roll Editor just published! Read the first comment for more information.

To update the tool to the latest version for all those users who have their Personalized Use license of Full Version, please follow this steps:

  1. Uninstall the old version of PRE.
  2. Install the latest version of PRE.
  3. Reinstall your Personalized Use License.

For the rest of users, they can try the free Demo Version.

Thanks for the support and Merry Christmas!


(QRQ) #37

This looks promising!

I think I ran into some bugs or some shortcomings;

I wasn’t able to get it to actually add notes to a pattern (although it was able to delete existing notes, and it would insert OFF events on some of the lines). It also doesn’t seem to support 256 line patterns which is a deal-breaker for me, since my workflow is to use 8LPB and make each pattern equal to one verse (256 lines). I think maybe you’d need to add a scrollbar for that to work correctly.

I would also suggest that you remove the nag screen, and allow the user to use the tool in demo mode for 1 hour before locking. With the nag screen popping up like that all the time, I can’t really tell if it would fit into my workflow. And with the small glitches I’ve seen so far, I feel like I need to really try it out before I trust it enough to purchase.

For 10 euros, I think people will buy it if they find it useful.

Good luck on your project!

I think you’ve done some very nice work so far.


(Raul (ulneiz)) #38

Hi QRQ!

Although this is a tool, it really is a fairly broad program. Actually, PRE can replace the pattern editor, although it is not designed for that, but to have another editor and note viewer. Therefore, given the complexity of the PRE, I was forced to make a user guide, which is highly recommended to read before or while using the PRE.Actually, to begin with, you only need to activate a couple of things and that’s it.

I wasn’t able to get it to actually add notes to a pattern (although it was able to delete existing notes, and it would insert OFF events on some of the lines).

This is not a bug. As indicated in the user guide, to start using the PRE, the composer must activate the Renoise OSC, read the guide to learn more. The guide is accessible from the tool itself: “Preferences” button / “About PRE” tab.OSC is responsible for editing the notes.Personally, I’m a little fed up with this situation. Any new user or one who knows little Renoise will download any tool that needs to activate OSC and will have the same problem. Unfortunately, the programmers who develop this kind of tools do not have a direct way of editing. It is necessary to use the OSC protocol.Once the OSC is configured correctly, you can add notes, edit them, delete them…

It also doesn’t seem to support 256 line patterns which is a deal-breaker for me, since my workflow is to use 8LPB and make each pattern equal to one verse (256 lines). I think maybe you’d need to add a scrollbar for that to work correctly.

This is not a bug either. PRE can show up to 64 lines, but it will automatically jump to the section that it should show. Therefore, you can see all the lines of the pattern, the 512, by sections of up to 64 lines. PRE does not have zoom. It is not possible to show 256 lines at the same time, nor 512, as it happens with the pattern editor.When I designed the PRE, I thought that Renoise users are “somewhat expert” using the most basic keyboard commands. PRE also has its own commands. Therefore, you can easily navigate within the pattern or between patterns with the keyboard commands. Most are the same as the natives used in Renoise. Obviously, you must have the PRE window selected.

None of the things you mentioned is a problem.However, I think I could study adding a vertical slide bar, to navigate between lines. This is quite complex. Actually, using the keyboard commands this is covered. So you can use the commands and the mouse at the same time.

I would also suggest that you remove the nag screen, and allow the user to use the tool in demo mode for 1 hour before locking. With the nag screen popping up like that all the time, I can’t really tell if it would fit into my workflow. And with the small glitches I’ve seen so far, I feel like I need to really try it out before I trust it enough to purchase.

I really can not do that.If you left the tool activated for an hour without any restrictions, the demo would no longer be a demo. If you consume the demo time, you can uninstall the tool and reinstall it to continue testing. The demo is a “full version”, only it has that annoying pop-up window. If with the currently available, you really can not appreciate the workflow, after reading something the user guide, is that this tool is not for you.

That said, the tool in this second published version works very thin. Believe me, if you believe that something is wrong, you have not configured something correctly (at least with Windows 10 of x64 and Renoise 3.1.1 x64).On Linux and MAC it should work exactly the same.

For 10 euros, I think people will buy it if they find it useful.

Good luck on your project!

I think you’ve done some very nice work so far.

Thank you! Really some people are not aware of the scope of this tool. It is necessary to give it a chance. Many are worried because Renoise is stuck without development. Meanwhile, tools of this caliber are published, which add a lot of capabilities that people ignore, and that undoubtedly add an incalculable value to the Renoise software. Buy a license from Renoise and you will also have these tools at your fingertips. You will not find anything better and cheaper in the market.


(stoiximan) #39

We need a video tutorial on this tool.I personaly dont understand why the developers dont do that for every tool they make for Renoise.Its 2019.Happy new year


(Raul (ulneiz)) #40

We need a video tutorial on this tool.I personaly dont understand why the developers dont do that for every tool they make for Renoise.Its 2019.Happy new year

Happy new year!!!

Because it costs a lot of work:

  1. First, make a great tool.That’s many hours of research and development.
  2. Then make a great user guide, and multi-language.Have you looked at the user guide?Every time I update the tool, I will surely have to update the user guide. And this guide is very broad.
  3. Then make a video tutorial, and in English, of course.Do you know what creating a video tutorial implies to explain the vast majority of capabilities?

Personally, I would like to have more time for this kind of multimedia content, but that is not the case.If there was much more interest and support in this tool… I have enough to maintain a user guide.


(stoiximan) #41

If there was much more interest and support in this tool…
[/quote]

I think that is what video tutorials are for, to explain and draw more attention.Anyway thanks for making it.